2022_12
The microservices industry has evolved a lot since its architectural concept was introduced in 2014. Microservices architecture pattern was used to describe lightweight application service with single responsibility, clear domain demarcation and data encapsulation, often consumed with REST APIs.
This architectural pattern addresses the inherent limitations of monolithic legacy applications. There are many attempts to modernize legacy application with software layering techniques like model-view-controller and inversion of controls. However, legacy applications grow in complexity and size because it is a single application. It assumes reliable infrastructure, vertical scaling and active-passive designs that are no longer relevant in modern cloud deployment.
Classic microservices architecture is used to decompose a monolithic legacy application into smaller pieces of microservices that can be deployed in a cloud native manner.
However, classic microservices architecture has some limitations. It is facing substantial application design and deployment issues because inter-service communication is not defined. In many real-world applications, a transaction may require the services from multiple application modules.
A typical remediation is to connect the microservices applications with an event stream system.
An event stream system is usually used for inter-domain communication. For example, for integration between legacy system and newly developed microservices that extend the legacy functionality.
Using an event stream system as a conduit for communication among microservices is the second level of digital decoupling.
Application instances are loosely connected with each other by events instead of HTTP.
This evolution opens a new chapter in microservices that leads to "event-driven microservices" architecture.
Event-driven microservices architecture allows us to directly map Domain Driven Design (DDD) into concrete implementation.
This assumes events are at the center of the modern enterprise. Application module has single responsibility. There are clear domain demarcation. Data in different domains and subdomains can be encapsulated in different services. Business logic is detached from platform and infrastructure. User facing channels are decoupled from services. Event-driven microservices are cloud native. They assume platform, infrastructure and applications can fail and recover gracefully with minimal service interruptions.
If we extend this decoupling concept further, we can visualize that we can use "events" for inter-function communication.
This is the concept of an in-memory event bus (aka "event loop") that is part of modern programming languages like JavaScript, Node.js and Python.
Java, the most popular programming language for the enterprises, does not have a built-in event loop system. However, there are open sources packages that provide this functionality. e.g. The Akka actor framework in 2009 and the Eclipse Vertx framework in 2013.
These three levels of digital decoupling, when used together, lay the ground for a powerful event-driven microservices architecture that would address the most demanding business use cases.
To summarize:
- Level 1 - inter-domain communication
- Level 2 - inter-service communication
- Level 3 - inter-function communication within a service
An ideal event-driven microservices framework should permit flexible application design without forcing designers and developers to go one extreme or the other. It should be adaptive so that it can evolve with the industry without much technical debts. Agile methodology means we can constantly adjust to changing business requirements.
Much like legacy backend systems, single page UI applications can grow into monolithic scale.
We advocate a micro-frontend architectural pattern where a single UI application can be broken into smaller UI modules that run in different memory spaces in the browser and work together as a single UI application.
It may leverage the "broadcast channel" API in modern browsers (Edge, Chrome and Firefox) as the inter-UI communication channel.