The Good, the Bad, and the Ugly: Modernize your legacy with microservices
Once you start modernizing your Application Portfolio, you will realize that simplifying a monolithic application is not the Wild West, but it can also be inhospitable and challenging.
Microservices are a suitable approach for simplification, but business-critical applications impose a high level of functional and technical complexity. The characteristics associated with monoliths make me think of Sergio Leone‘s “The Good, the Bad and the Ugly”:
- The good news is monoliths are not so monolithic
- Rather bad is that domains are not reflected at database level
- Things get ugly when the advantages of monoliths must be preserved.
Reduced time-to-market through microservices?
Shortening the time to market is often the main goal of a modernization. In contrast to a greenfield development, productive applications must be architecturally modified. The microservices architecture pattern promises high development speed, adaptability, and horizontal scaling. It offers independence in terms of teams and technologies.
“The Good”: monoliths are composed out of components
The good news is that monoliths are often not so monolithic: Domain-driven design and bounded context have been around for years. Many monoliths are divided into components. In a first step, they are candidates for future microservices.
“The Bad”: Database without “Bounded contexts”
However — and this is the bad news — a strict separation into components is often missing on the database level. Instead, it’s an integrated database with the following characteristics:
- Consistent management of all data (no separation in domains and bounded contexts)
- Referential integrity via foreign keys
- Read accesses in queries across domains
- One transaction across components
- Triggers and procedures that change data across domains.
It’s the task of the architect to adapt the database design fitting to a microservice architecture while preserving the functionality. Practice shows that this is not as easy as shown in the figure. The straight forward separation into several databases doesn’t work because of the mentioned characteristics.
“And the Ugly”: Safeguarding the advantages of monoliths
Let’s get to the “ugly” part: Monoliths have features that are dear and familiar to users. They are consistent in themselves. The ACID properties (atomic, consistent, isolated, and permanent) do not apply in a system with microservices. Instead, “Eventual Consistency” arises, including functional consequences. The foundation for this is the CAP Theorem and the change from ACID to BASE (basic availability, soft state, and eventual consistency). The microservice architecture must ensure that the functional requirements for consistency are also met! Cooperation with the business experts during the creation of the new architecture is crucial for success.
A service call can be processed fastest by a monolith. Scalability does not necessarily mean performance. The latter is negatively affected because microservice architectures convert internal interfaces to external ones. In order to still get a result quickly, command query responsibility segregation (CQRS) can be used to separate read and write operations as the basis for microservice-level caching. Alternatively, data replication is a measure for database queries within a microservice.
Finally, the resilience must be explicitly designed. Asynchronous and unavailable services always require changes to business processes. On the technical side, patterns such as retry, circuit breaker, and bulkhead must be implemented to ensure an antifragile architecture (use existing open source libraries).
Conclusion
Modernization by means of a microservice architecture is not purely a technical task, but also a business-driven one. When introducing microservices, business processes and transactions should therefore be questioned and, if necessary, adapted. Unlike in the Western world, the “law of the jungle” does not apply here. Instead, a forward-looking and cooperative concept wins, in that architects take a holistic view of the challenges (business and technical).
