The problem with monolith application
You have been working on a monolith application for a long time. As time goes, a lot of feature request made the initially perfect design not that perfect anymore. No matter how much effort you put to keep the module separated and layered, there will always be more and more coupling, and it will become more and more expensive to envolve. You hope you will get a chance to start over.
The problem with monolith application is not the code quality. It’s the wrong engineering approach. As long as it’s a monolith, the complexity will grow over time and become unmanageable at the end.
Microservice give you the chances to start over
In monolith application, the static and tight coupling is the root cause of most complexity. We need those coupling to make the system works as a whole. But then we want the coupling to be dynamic and loose so that we can evolve each component separately, or alternatively, we can start over many many times.
One general principle about any engineering approach is that we should make the right thing easy and wrong thing difficult. With containerized microservices, each component can be developed and deployed independently. It won’t be easy to create a tight coupling between services.
Why event-driven microservices?
Now we know we need microservices, what’s the coupling should look like between them? It could be synchronous HTTP request/response, or just asynchronous events. Both approaches have valid use cases. But most of the time, we should model the business process through asynchronous events.
The truth is that we live our lives operating on out-of-date information. There is no such thing as synchronous. Event-driven is inherently asynchronous. From this point of view, events are much more powerful modeling tool than synchronous calls. We can simulate synchronousness with blocking event.
So we can define our business process event streams. The coupling between components is done through pub/sub pattern. It removes the rigidity created by central control, injects real-time context into the business process. This kind of dynamic coupling is what we want to take advantage of through microservices.
Composability is the motivation
Most monolith application is designed with only anticipated use cases in mind. They assume they would be the only system need that information and thus don’t expose key events for easy data access. In many cases, we have to resort to database trigger to expose those events.
With event-driven microservices, each service just publishes whatever they did meaningful to the event bus. As more and more of an enterprise’s applications connect to the event bus, make their functionality available through events, the event bus becomes a centralized point of one-stop-shopping for functionality in the enterprise. A lot of new use cases can be implemented by the composition of existing events.
The chance to re-purpose and compose existing events is the real power of event-driven microservice. It’s the motivation that we want to publish more events to the event bus.
Real-time event processing bring agility
The value of any events system is not only about how many events it can process. It’s also about how faster each event gets processed. For a lot of activity, the shorter the feedback loop, the better it can iterate and evolve. With event-driven microservices, the response time for any events could be much shorter. In turn, this could be an increasingly important competitive advantage for high-performing teams.
Conclusion
The ultimate goal of the event-driven microservices is not about a better IT system, although it definitely helps. It’s about improving business performance.
Events are the key enabler for agile organizations. Microservice is the most ideal thing for now to implement such an event-driven system. We are still in the process to transform the business process into event-driven one. A lot of new use cases could be implemented as more and more events are exposed and available for the whole organization. But before we get those benefits, we must understand the initial investment for the event-driven system could be much higher. The dedication from top management is needed for any successful migration to the event-driven system.
