What Lies Beyond a Microservice Architecture? — Architectural Bad Smells

In the first part, “Software is Alive”, we discussed how software is constantly evolving, adapting, and responding to changing requirements and conditions, much like a living organism. We highlighted how bad smells’ emerge over time, and suggested the usage of a Big-O Complexity Chart for analysis. However, software is not only about code, it has a lot of other factors that complement it, which is why architecture plays a crucial role in the world of software!

In this article, we will take a look at Monolithic and Microservices architectures, highlighting common bad smells, and build their respective Big-O Complexity Chart for analysis, a concept that might be used as a basis for an architectural change.

Monolithic

Monolithic architecture is often the initial choice for teams or companies starting their architecture journey. It’s like a simple Lego box, where each Lego piece represents a software feature. However, all features reside in a single location, interlinked, and sometimes to move one piece requires shifting others. The connections between pieces aren’t always clear, and acquiring a new unique piece means obtaining an entirely new box. This is an easy way to explain Monolithic architecture.

In the very beginning, adopting this architecture seems like the best choice. You know what the features and domains are, and you might not need to scale it for higher throughput. However, your product team may not yet have a clear vision of the new features for the next 6 months. The first deployment is a success! You have a firm grasp of the features and domains of your application, but as time goes on, new requirements and features begin to emerge.

That’s when things start to get out of control:

The team begins to expand, and it’s not just 5 developers coding on the same code base anymore, it’s 20,30, or even 50! Developing a new feature starts to be hell, and merge requests turn into day-long endeavors due to frequent merge conflicts. How about Version Control? It becomes a challenge as different features in the same codebase depend on varying versions. The number of domains and responsibilities multiplies! As a result, complexity and code quality issues “bad smells” start to be felt!

After a while, as you start to feel the increasing complexity and bad smells, your team might begin to ponder “Is it the right Architecture?”. Have you ever thought about this question in your career? I’m familiar with that feeling: it’s a mix of uncertainty and apprehension. One fact is that making significant architectural changes based solely on feelings is challenging. This is why we collect metrics on our architecture, but it’s not always straightforward, and it often comes with substantial infrastructure costs and takes time. So, what could be a more straightforward approach to provide guidance for an architectural change in this situation?

Before diving deeper, let’s explore another architecture: Microservices!

Microservices

Microservices have gained popularity in technology architectures due to their potential benefits, such as scalability, flexibility, and the ability to break down complex applications into smaller, more manageable services. However, it’s not that easy.

Many companies have started adopting microservices using the Decomposition Pattern in their Monolithic, well-known by Chirs Richardson in his book “Microservices Patterns: With Examples in Java”. This pattern enhances the approach of gradually replacing or decomposing the monolithic application by creating microservices that handle specific functionalities. Over time, these new services “strangle” the monolith by taking over its functionality, piece by piece, until the monolith is no longer in use. After this transformation, the architecture may be seen as a bunch of Lego pieces on a table!

That’s when your team/company begins to feel some bad smells in this architecture approach. Deploying all the services becomes challenging, the infrastructure costs are out of control, and you don't know why. Duplicating data across multiple microservices results in data consistency problems and increased storage requirements. Failing to version APIs breaks client applications when changes are made to microservices… and many other bad smells.

Then, your team begins to ponder that magic question “Is it the right Architecture?” and you start to feel a mix of uncertainty and apprehension. We all know that making an architecture change based solely on feelings isn't the best approach, consequently, your team starts to collect metrics and reevaluate the architecture.

Doesn't it seem like the same situation in both Architectures? So, what would be an easy approach to facilitate an architectural change? If you read the previous article, you know that whenever I see a graph like the one before, I am reminded of the Big-O Complexity Chart… Why not utilize it to measure the architecture’s complexity?

Architecture Change

Making a decision for an architectural change isn't a simple task; it typically requires a solid foundation to do so, and building one is not always straightforward or inexpensive. But what if we use some software concepts to do that? How about utilizing the Big-O Complexity Chart?

Let’s take a look at the growth of a Monolithic and how it can be likened to a Big-O Complexity Chart.

Examining this graph that compares the number of Domains X to the problems your monolithic solves will help you to determine which zone it falls into.

If it’s in the Red Zone, similar to what happens with an algorithm, it is a dangerous zone and it’s not the ideal scenario to be in! When your monolithic is in this zone, that's when your team starts to feel the Architecture Bad Smells. To address this situation, you can consider following some approaches:

• Build a Modular Monolothic: it will provide you some breathing room for a while.
• Apply the Decomposition Pattern: this will guide you in breaking down your monolithic, possibly into 2 major parts, or even in smaller parts following the adoption of a serverless or microservice architecture.
• Live with the situation: nothing changes, and your team accepts the way that it’s going.

So, if you are uncomfortable in the red zone, it’s time to make a change!

The orange and yellow zones are much more like a “warning”. So, keep an eye on them and pay attention to any bad smells that might start to appear!

And how about Microservices… what would lie beyond it? As we have seen, even when following the best practices and patterns, it’s still possible to achieve a higher complexity and be in The Red Zone in this architecture. In the next article, you will learn what lies beyond a microservice architecture and how to move forward with this architectural decision, enabling your company to grow, develop new products, and build new teams!