This is the third blog in a series explaining how MuleSoft’s Anypoint Platform can provide agile connectivity across monolith, SOA, and microservices architectures.
In my last blog, I reviewed the different types of architectures that have evolved over the last decade and how that has now led to the commonly used microservices architecture approach. This post will discuss whether this is the ultimate answer to architecture development,
The simple answer is NO! Obviously, microservices are a clear evolution and the most modern architecture pattern around. However, there is also a range of use cases where a microservice-based architecture is simply not applicable or the best choice. Here a few of those cases:
- Being highly distributed, microservices architectures typically suffer from challenges around consistency / Distributed Transaction Management. The use of XA-based Transaction Monitors doesn’t work with the structure and the availability concepts of microservices. The CAP Theorem requires a developer to choose between availability and ACID style consistency (ACID = Atomicity, Consistency, Isolation, Durability). As availability is usually the dimension with the highest priority, consistency falls short for greater clusters. Over the last few years, a few patterns have emerged that address this problem to a certain extent (e.g. Event Sourcing or CQRS). With that being said, these solutions are complex when it comes to implementation and management, and they introduce a level of risk that people accustomed to the transactional integrity of something like a relational database are often not willing to take.
- Most customers do not start from a “Green Field.” Not all applications and use cases can be transformed. Other transformations would require a level of effort and associated risks that wouldn’t match the expected benefits. Integrating existing and new solutions and/or providing smooth migrations (e.g. Strangler Approach) becomes the recommended strategy for classic enterprises.
- Existing culture and engrained practices cannot adapt so easily to agile DevOps patterns on a wider scale and access to skilled Netflix-level developers is limited. Microservices complexity, if not addressed correctly can bring down productivity significantly. Martin Fowler addresses this in a blog and discusses when to use microservices and when to stay with a monolithic approach (source: MartinFowler.com):
“So my primary guideline would be don’t even consider microservices unless you have a system that’s too complex to manage as a monolith … Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.”
“But unless you’re faced with that complexity, remember that the microservices approach brings a high premium, one that can slow down your development considerably. So if you can keep your system simple enough to avoid the need for microservices: do.”
Obviously this statement is a few years old, and of course, there have been many advancements and patterns that promote productivity introduced since. But, in essence, the statement still holds true. Transforming application use cases towards a microservices model is complex and you should weigh the benefits against the associated efforts and risks before starting the journey along this path.
So what is the best approach for flexibility and agility?
The answer is not that simple. As outlined above, there’s no architecture pattern that is the ultimate weapon for all use cases, digital enablement, or system landscape modernization scenarios.
Different architectures have different strengths and weaknesses. If you analyze the different architecture styles along application core attributes like scalability, consistency, life cycle frequency, and life span, the differences become quite visible. While monolithic applications excel in categories like consistency, they show massive weaknesses when it comes to scalability and autonomy. Microservices are exactly the other way around. SOA sits somewhere in between: easier to achieve consistency, but not the same level of autonomy. Nevertheless, if you are looking to “strike a happy medium” SOA might be worth looking into.
Bringing SOA back in the picture
But wait, SOA was bad and outdated, right? Obviously, there is still a problem around governance with SOA-style projects. But is this still a legitimate as it was a couple of years ago? Can SOA-style architecture be a valid component in a composite architecture setup once again, even for new application and service initiatives? Let’s discuss this point in more detail.
If you map the requirements of your specific applications to the above graphs, you derive the architecture model that might be best to implement, or in the case of monolith, stay with. Since the new breed of application types are composites of multiple applications, it is likely that we will end up with more than one architecture pattern that needs to be addressed via our target architecture.
Complementing Monolithic, SOA, and Microservices Architectures
For instance, if you try to make a rough mapping of the different architecture approaches to the Gartner 3 Pace Layered Application Strategy, it becomes obvious that there is some natural mapping between them. Monolith, given its legacy nature and in a lot of cases its maturity when it comes to consistency, are typically a natural fit to the “systems of records layer.” The “innovation layer” – as the name implies – requires fast life cycles and autonomy as the most needed capability. Looking at the graphs above, this makes them the perfect candidates for a microservices-based implementation. And last but not least, there is the “system of differentiation” layer. While this layer typically hosts applications and services that are driven by a highly evolutionary process, the life cycle is significantly lower than for the innovation layer. The services in this layer often act as mediators, service composites or service aggregators that extend system-of-record-based standard processes by enterprise- or LoB-specific processes and functionalities. Given the close relationship to the systems of record layer and the process-driven nature of an enterprise, this layer is typically a good candidate for an SOA-like architecture approach, which nicely supports orchestration and distributed Transaction Management.
Given the observation we just made, it becomes even more obvious, that the key to agility lies in providing ultimate flexibility. Regardless of the architecture pattern a certain application or service follows, which infrastructure it requires (cloud or on-premise) or which transformation approach it subscribes to (The 5 R’s of Cloud Migration) – the solution you are looking for needs to adapt to all of them. It should provide you with an abstraction and management platform that gives you the flexibility and agility to integrate different architectures, systems, and services to drive innovation at the same time.
In my next blog post, I’ll discuss how MuleSoft’s Anypoint Platform provides exactly such a capability.
For more information on architecture, check out MuleSoft for architects.
