Why Migrate?

Beyond the single-tiered monolith, a common architectural pattern is the 3-Tier Architecture which traditionally consists of presentation, business and data tiers. However, complexity is hardly ever proportional among those tiers. In some cases, we find business logic in the presentation tier or in stored procedures within the data tier. Yet, in other cases, we find the application tier divided into as many services as there are functions in the system. Some may even call this Microservices, but without the appropriate isolation, it is merely a distributed monolith.

Figure 1: Comparison of some architectural styles.

RELATED SPONSORED CONTENT

From Docker to Kubernetes: Container Networking 101 (By O’Reilly)

Demystifying Microservices for Jakarta EE & Java EE Developers

Radically Collaborative Patterns for Software Makers

[Checklist] Is Your CI/CD Solution Made for the Enterprise?

The Business Bottleneck – Download the eBook (By O’Reilly)

RELATED SPONSOR

**NGINX Plus is the complete application delivery platform for the modern web. **Start your 30 day free trial.

These of course are not all bad architectural styles but each have risks. The common threshold for migrating to a new architecture is when the risk associated with changes is great enough or cannot be mitigated. It is just as important to recognize the reasons for making an architectural switch as it is to validate them prior to jumping in.

EDAs are All About Events

Event-driven architectures (EDAs) are not new but we may find that the practices we use in implementing them often distract from the core principles consequently causing us to overlook that EDAs are really about the events’ primary role of being units of change within the system. Practices often used in EDAs such as messaging and asynchrony may introduce such noise. You can build an event-driven system inside a monolith just as much as you can with a distributed system; simply look no further than most operating system kernels such as Windows or Linux.

But events do not simply be. We don’t just end up with a PantsStainedEvent; a SpillCoffee action must have been invoked, albeit, inadvertently. An event must be caused by something because it is naturally a historical element and, similarly to stained pants, immutable. In a system, the creation of an event will be caused by actors such as users or time and usually communicated through a message such as an API call or a queue message.

#microservices #event driven architecture #cqrs #cloud #architecture & design #development #article