Event-Hidden Architecture

Summary

Event-Hidden Architectures​ How did we get here?​ One of the most powerful and consistent trends in software for the past decade has been the move from single stack to cloud native applications. Cloud native applications are inherently distributed and have become popular as developers are drawn to the convenience of containers and platform-as-a-service infrastructure. The API-ification of important subsystems means today hardly anyone would consider implementing their own payments, shipping, SMS, chat, billing or shopping cart functionality. Instead they’ll lean on Stripe, Twilio, Shopify, Shippo, etc; accelerating time-to-value and further distributing the functions of the application. In the last few years developers have moved quickly to incorporate more and diverse AI features into their applications, but AI models and application logic compute requirements are quite different from one another and therefore seldom run in the same stack, further distributing the application. Some have called for a “back to basics” approach of a single stack or modular monolith, but given the list of external demands on modern application development, distributed is unlikely to go away. Instead it’s becoming a more common approach for application architectures, not less, especially for “successful” applications that need to modularize to support more customers, users and features. 10 years of bad advice​ One can sympathize with the desire for a “back to basics” approach to cloud-native applications. There are many “pros” to writing cloud-native, distributed applications but living with them has been miserable for developers and operators alike. “Cloud native” is effectively synonymous with “distributed,” and “distributed” is another way to say a network is parked in the middle of the application. This changes engineering and operations in many big and subtle ways. The most common and questionable advice to tackle these challenges has been “event-driven.” Events are the biggest rea...