No, You Don’t Need a New Microservices Architecture

If you feel like the AI generated article-image actually captures your company’s system architecture quite nicely, then this article is for you.

There is no doubt that breaking down complex tasks into smaller, manageable subtasks is helpful for any kind of problem solving. This is also true for IT systems that digitalize our business processes. Architects therefore followed the tried and tested path of „divide and conquer" in IT and divided our systems into smaller applications/services that fulfil specific tasks for different business areas.

With the growing complexity of our enterprise, the system of interconnected applications/services representing the digitalized business processes also grew overly complex. So we’re constantly trying to keep order and structure so that the whole mess doesn’t implode and stop working altogether – that’s actually Enterprise Architecture, if you ever wondered what those guys in the ivory tower are trying to achieve with their architecture component diagrams.

Architecture for the enterprise

Much has been written about the right architecture to tame or prevent chaos when the overall task of digitalizing the company is spread across the entire enterprise.

You can find comprehensive frameworks like The Open Group Architecture Framework (TOGAF), that explain everything that could be relevant to effectively model your enterprise architecture. There are also extensive descriptions available for the right design patterns to be followed when architecting your applications. Enterprise Application Integration (EAI) has defined Enterprise Integration Patterns that help to re-integrate spread information caused by isolated applications. And Domain-Driven Design (DDD) even taught us how to prevent the isolation to occur in the first place.

The specialized discipline of enterprise Data Architecture also emerged, offering an ever-increasing number of styles and approaches to tame the data chaos in the company. I won’t go into detail here, but James Serra has made an incredible effort to decipher data architectures found in the enterprise today.

Despite this multitude of frameworks, development patterns, best practices and lots of advice from both application and data experts, we still struggle to create and maintain a well-organized enterprise architecture. I now have the impression that the sheer volume of good advice on doing the right thing tends to contribute to further confusion.

So we are always on the lookout for the next improved, even more comprehensive and hopefully definitive piece of advice on how we can best organize our IT systems.

Microservices architecture for the enterprise?

The latest (or should I say modern) approach is the microservices architecture, which can also seamlessly extend to the cloud. Allowing a hybrid use of cloud services is definitely also on the long list of challenges that enterprise architects have to solve.

So let’s just tackle this modern style as quickly as possible, shall we?

Well, even for such a modern application architecture, we have already found anti-patterns and pitfalls to avoid – Mark Richards for example, a renowned architecture veteran, has collected good advice on this.

This is not surprising, as all the rich advice we already have for our enterprise architecture is equally valid for a microservices architecture. I would even state that most larger companies already have a kind of microservices architecture in place, although they might not explicitly be aware of it or call it that.

What do I mean with this statement?

All the different applications, services and platforms interconnected by the corporate network can actually be seen as a microservices architecture. However, with all its fragile and inefficient component interplay, scaling problems and maintenance issues it’s a rather weak and somewhat chaotic implementation of it.

Let’s distill the essence of microservices architecture by focusing on its core principles to help us recognize the validity of my statement.

• Independent deployabilityTo ensure independent deployability, we need applications/services to be as loosely coupled as possible to allow changes in one application/service without affecting others. This is certainly also a main target in our enterprise in general. After all, that was the key driver for the decision to spread the development of applications across the entire enterprise.

• Everything modeled around a business domainFrameworks like DDD teach us to structure code and components to better align with the needs of business domains. This is general advice also applicable outside microservices architecture. It has been accepted as the best way to allow the decoupling of applications/services needed to enable independent deployments. Traditional layered architectures are no longer the advised way of structuring an enterprise architecture.

• No shared stateThe realization that a single shared database cannot be scaled to the enterprise is also not new or specific to microservices architectures. It is equally important for applications on enterprise level to decide which data is shared and which is hidden or private. This also allows to reduce unwanted coupling and fosters independent deployability.

• Small size of services "How small should a microservice be?" is certainly one of the most common questions asked around microservices architecture. However, even evangelists of microservices architecture agree that the actual size of the service is the least significant aspect. Some even argue, that only the size of the interface and not the size of the service itself is relevant. But apart from this question, everyone agrees that size is relative and the ‘right’ size of a service rather needs to be developed over time. It cannot be defined in advance in lines of code or other complexity measures. There may still exist big monolith applications in the company, but from the global perspective of the enterprise even such a monolithic application can have the right size to fulfil the other core concepts described for microservices architecture.

• Flexibility for change and evolutionThis is the most essential ingredient for maintaining a sucessful enterprise architecture. Evolving software architectures allow to constantly integrate each new innovation into the overall software ecosystem. It’s flexible enough to maintain the right balance in the system with every change implemented. Again, you can find rich advice from renowned software architecture veterans in Building Evolutionary Architectures. It’s valid advice for the enterprise and in no way specific to microservices architecture.

Consequently, the key question is not if a microservices architecture is the right architecture for our organization. There is no right or wrong architecture on the enterprise level, but instead just many trade-offs to be made.

The core concepts of microservices architecture are practically in line with everything we have already learned to maintain a clean architecture on enterprise level. There’s nothing truly new in the microservices approach. Even the emergence of platforms trying to standardize the implementation – Kubernetes is the most prominent one – will not revolutionize our enterprise architecture. It’s just another platform promoted by one of the influntial vendors on the market. One more new product that vendors intend to sell us to solve all our architecture challenges.

The typical approach to ‘integrate’ such allegedly revolutionary platforms into the enterprise architecture are lighthouse projects. These projects are big and expensive but very seldom comprehensive enough to replace substantial parts of the current ecosystem. Instead they just contribute to further complicate matters by creating new islands of technology.

I’ve written about the unfortunate practice for larger companies trying to buy data platforms and assemble them like Lego bricks, hoping for the next big leap forward.

This doesn’t work for either data platforms or application platforms!

The evolution of architectural principles over time should make us realize that there is no simple, one-size-fits-all approach. While today’s view suggests microservices as a promising architectural approach at the enterprise level, it will expose further weaknesses and trigger just another set of pitfalls and anti-patterns to avoid.

The key takeaway is that no single product, platform or new architecture style can ever replace our enterprise ecosystem of interconnected applications that are fit for our purpose. We can change and evolve the enterprise system following sound architecture principles, but we cannot just buy a new enterprise architecture, nor can we completely replace it with a single, new approach. So you don’t need a new microservices architecture but instead evolve your current enterprise architecture to better support the core concepts listed.

See also the articles on Universal Data Supply for my advice on how to seamlessly (re)integrate application architecture with data architecture.