Monolith vs Microservices Architecture: A Detailed Comparison

Take a deep dive into two of the most common software architecture patterns.

Startups are guilty of building software products without a formal architecture in place. Developers, too often, go for the traditional layered architecture pattern. What’s the problem with this? Well, it creates implicit layers by separating source-code modules into packages.

And, what’s the result?

Spaghetti code jungle.

This is often the result of an unstructured system or architecture in place. It lacks a clear direction, is difficult to change & maintain, and is brittle.

Read more about the big ball of mud on Wikipedia.​

Points to be covered in this article -

• What is software architecture?
• What are microservices?
• Benefits and problems of using micro-services
• What is monolith architecture?
• Advantages & challenges of going the monolith way
• What to consider when you plan to migrate?
• When using micro-services is a brilliant idea?
• When to steer away from micro-services?
• Tell-tale signs of micro-services becoming a pain
• Solutions to these problems
• Ending notes

Hence, it's super-important to pay attention to the architecture of any product/software you intend to build.

Some experts might refer to software architecture as a blueprint of a product. Others might want to call it a roadmap for developing software.

No matter how you want to define software architecture as it encompasses the following -

• The core structure of the system
• The characteristics/abilities the system must support
• The rules for how the system must be constructed
• A proper set of guidelines/design principles

There are various architecture patterns available to help define the basic characteristics and behavior of an application. For instance, some architecture patterns naturally gravitate towards making highly scalable applications, whereas other architecture patterns are inclined towards highly agile applications.

Hence it is very essential to understand the pros and cons of each architecture pattern.

Some common architecture patterns include -

• The layered architecture/n-tier architecture pattern
• Micro-kernel architecture
• Event-driven architecture
• Micro-services architecture
• Space-based architecture
• Monolith pattern

As a product owner, you must understand these patterns and make sure to have solid reasons for a pattern you intend to choose.

Many owners/tech founders face issues when it comes to choosing an architecture pattern. Try out the golden circle method by Simon Sinek to choose the right pattern.

This article discussed the key difference between microservices architecture and the monolith pattern. Let’s get started.

What are microservices?

Biggies across the globe including Amazon, Netflix, Etsy and Uber have witnessed immense business gains going the microservices way. So much so that, microservices, now, is the default architecture of countless companies worldwide.

But what exactly is it?

Let me begin by describing an interesting fact about Sweden.

If you have been to Sweden or stay there, you will come across variations of the same road markings, road signs, and traffic signals that are used everywhere else in the developed world.

So, how come this country has one of the lowest road accident rates. Could it be better drivers, the ways roads are designed, or stringent traffic laws? Well, these factors certainly do play a role, but as it turns out the credit goes to the Vision Zero program.

Source

I know you must be wondering what has road safety got to do with software architecture or microservices?

Hold on a minute. You will know.

Vision Zero is all about reducing road accident-related deaths to zero. It aims to achieve this by designing road systems that prioritize safety above all other factors, while still recognizing the importance of keeping traffic moving. In other words, a road system that is designed first and foremost with safety in mind.

The core belief is — that the safety of pedestrians and drivers is more valuable than the need to move from place to place as quickly as possible.

Traffic designers apply speed limits, road signs, and traffic movement patterns in a way that benefits the overall safety of the system. For example, while it is necessary to ensure the movement of cars on the road, speed is limited to a level that the human body could withstand in a collision given the technical standards of the vehicles and roads that exist.

While speed limits may impact drivers’ ability to get to their destination as quickly as possible, the design decision is always driven by the requirement to protect human life.

Instead of solely relying on skilled drivers who know how to avoid common mistakes, Vision Zero designers create roads that account for the errors and miscalculations that many human drivers inevitably make. While it is the driver’s responsibility to adhere to the rules of the road, the system designers must do their best to protect humans even in situations where drivers do not conform.

(Source: Microservices Architecture Book, O’Reilly)

Similar to traffic systems, software products grow complex as these scale in the form of scope, volume, and user interactions. So, just like road designers, software architects must know to strike the balance between speed and safety.

Companies use the microservice architecture for faster delivery while at the same time paying attention to safety.

As a variant of the service-oriented architecture structural style, microservices arrange an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight.

Source

Benefits of using microservices

• Independent in nature —Microservices improve the scale and robustness of software systems. You can mix and match technology using it. Bring in more developers to solve problems without any one of them interrupting each other.
• Focus — Helps developers focus on just one part at a time, they are responsible for.
• Varied technology choices — Since microservices work in isolation, you can form your own right mix of technology depending on business needs. Mix and match programming languages, stypes, deployment platforms, and databases.
• Flexibility — Perhaps the biggest advantage ever of using microservices. You have lots of options when it comes to solving problems.
• Replaceability — The idea of replacing components rather than maintaining existing ones is at the very heart of this approach.
• Real-time production deployments — Microservices have the capability to do real-time production deployments thereby significantly reducing the need for the traditional monthly or weekend “big bang” production deployments. Since change is generally isolated to specific service components, only the service components that change need to be deployed.

Problems of using microservices

• Networks & Latency issues —We need to factor in latencies because communication between computers over networks is not instantaneous. Latencies that far outstrip the latencies we see with local, in-process operations. System behavior can be unpredictable when latencies vary. Networks fail, cables get disconnected and packets get lost.
• Complex debugging & integration testing — When you have multiple services running you have multiple logs, meaning, difficult & time-consuming to go to the source of the problem. Moreover, distributed components mean a system can’t be entirely tested via a single machine.
• APIs — Every microservice uses its own API. You can independently work on a microservice without impacting the entire system. But if you make changes in an API, every microservice using that API will be impacted (if changes are not backward compatible).
• Costly — For microservices-based software systems to run efficiently one needs to invest substantially in infrastructure and experience engineers to do the necessary tech & maintenance work (because of multiple programming languages & frameworks). This is specifically true when a company migrates from monolith-based systems.

What is monolith architecture? What are its advantages & challenges?

Functionalities deployed together in a single unit are considered a monolith. There are 3 types of monolith structures — the single-process system, the distributed monolith, and third-party black-box systems.

Simpler deployment — Monoliths result in much simpler developer workflows. Hence, monitoring, troubleshooting, and activities like end-to-end testing become easier & simpler.

Code Reuse —Ever wanted to reuse code within a distributed system? You know what I am talking about. You might have to wonder about breaking out libraries, copying code, pushing shared functionality within a service. With a monolith architecture, the code is just there to use it.

No major re-architecting — It’s way easier to fix monolith-based systems since they have a simpler, singular deployment. Shopify, one of the well-known e-commerce store builders, was deployed using a monolith architecture in its initial days. It is based on Ruby on Rails. However, they have now shifted to a microservices architecture based on their ever-growing engineering needs.

Easy Maintenance — Maintaining an entire codebase in a single base definitely has its advantages. No complexities whatsoever. Just maintain one repository and you are done. Only one test and deployment pipeline needs to be taken care of.

No API worry — With monoliths, developers can call into different components directly instead of using APIs. So, you don’t need to maintain those versions and worry about backward compatibility.

Here’s an interesting conversation that includes why monoliths are the future.

The challenges

Taking the example of Shopify further, its monolith-based architecture was no longer serving its purpose in 2016 when both the platform and team grew.

Kirsten Westeinde, Developer at Shopify, explains in detail as -

The application was extremely fragile with the new code having unexpected repercussions. Making a seemingly innocuous change could trigger a cascade of unrelated test failures.

For example, if the code that calculates our shipping rate called into the code that calculates tax rates, then making changes to how we calculate tax rates could affect the outcome of shipping rate calculations, but it might not be obvious why. This was a result of high coupling and a lack of boundaries, which also resulted in tests that were difficult to write, and very slow to run on CI.

Developing in Shopify required a lot of context to make seemingly simple changes. For example, a new developer who joined the shipping team should only need to understand the implementation of the shipping business logic before they can start building.

However, the reality was that they would also need to understand how orders are created, how we process payments, and much more since everything was so intertwined. That’s too much knowledge for an individual to have to hold in their head just to ship their first feature. Complex monolithic applications result in steep learning curves.

What to consider when you are migrating from monolith to microservices architecture?

Sam Newman, a renowned, independent microservices consultant tells one should answer the following questions before going the microservices way.

1. What are you hoping to achieve?

This should be a set of outcomes that are aligned to what the business is trying to achieve, and can be articulated in a way that describes the benefit to the end-users of the system.

2. Have you considered alternatives to using microservices?

There are often many other ways to achieve some of the same benefits that microservices bring. Have you looked at these things? If not, why not? Quite often you can get what you need by using a much easier, more boring technique.

3. How will you know if the transition is working?

If you decide to embark on this transition, how will you know if you’re going in the right direction?

When to use microservices architecture?

• Autonomous teams — Some companies thrive when run by autonomous teams. If you are looking to bifurcate roles, want to allow small teams to work closely & create such a culture, this architecture might be just what you need (of course there has to be a tech/business logic to go for it). Companies try and give ownership to parts of the codebase to people having expertise in a particular area. For instance, John might know how ads are displayed the best so he has ownership of that. Julia might know better about query performance, so that might be her part. When you improve autonomy and adopt a self-service approach, you do away with the need for central operations teams to have to field tickets for day-to-day activities.
• Adopting new technology — Monoliths hamper technology choices because of the single deployment pattern. When you want to enjoy the flexibility to try a new stack safely, microservices might be an option for you. This might give you a competitive advantage by allowing you to ship better features/functionalities to your users. Your development team might also be able to up their ante when it comes to technical skills.
• Reduce the time-to-market — With microservices, you can deploy changes and scale individual services. Release functionalities/features quickly to gain more customers/users.
• Cost-effectiveness — Microservices allow you to make your operations cost-effective, as you will scale the parts that are facing constraints. You can even scale down when the need be. Microservices can be even turned off when not required. Many SaaS companies adopt this approach because it brings down operational costs.
• Robustness — When you don’t want your entire system to collapse because of issues in one area, microservices come to your rescue. This is especially true in multi-tenant SaaS applications. You don’t want your users to face outages because of minor issues. With microservices, you have a more robust architecture in place. It also gives you more control over parts that are mission-critical.

When to steer clear away from microservices architecture?

• Just starting out a new business — Startups need to think twice before going the microservices way. The idea should be to establish a product-market fit initially. Microservices are better suited for startups focused on scaling up after they have validated their idea. With a limited budget and the need to roll out a product quickly, don’t focus much on these aspects. Using microservices architecture will not save a bad idea.
• Customers need to install your product — When you create a product that users need to download and install, you want it to be simple and effective. You don’t want to push a lot of complexities for them. You can’t expect your customers to learn to manage microservices architecture.
• No clear vision/goals — If you are clueless about the industry/domain you will operate in. If you have no idea about the product vision or the course it will take in the future. If you have no clear expectations or goals to be achieved using microservices architecture, it is better to stay away from it. Usually, when it comes to deploying this pattern, companies know the problems they are facing and how microservices will help eliminate them.
• Domain knowledge/grasp — You need to know the in and out of the industry you operate in. Prematurely moving from a monolith architecture and dividing it into different components can prove to be costly. You don’t take decisions on something like — ‘If it works out for Uber, it will do wonders for us.’ You need to understand how microservices will help eliminate your industry problems. If this isn’t clear, don’t dive into it.

Tell-tale signs of micro-services becoming a pain & their solutions

• Code ownership — When working with a microservices architecture, there are different models to code ownership. It might be strong, weak, or collective. When teams are small (less than 20 people), a collective code ownership might be great wherein everyone is allowed to change code and make changes as required. However, when teams scale, it can be a disaster to follow the collective model. The end result will be everyone trying to make changes leading to a colander bowl (used for straining pasta). You don’t want to be in that situation. A solution is to have a strong code ownership which requires people to submit code change requests to owners who then decide what’s allowed and what’s not.
• Monitoring & Troubleshooting — With monolith architecture, either the system is in full swing or completely down. You will know to pick the problems easily. But with microservices, especially in an environment, wherein hundreds of processes are running simultaneously, you will need to pay extra attention & investment. One fine morning, you will realize there are issues in production but the system is functional. It becomes trickier and harder to tell ‘is everything going fine? You can rely on a log aggression system to deal with this. Another thing to do is use an open-source tracing tool like Jaeger to capture information for distributed traces and analyze the performance of individual calls.
• Developer experience starts taking a hit — When you run more services, you will need bigger machines. There is a limit to the # of services you can run on a single machine. What are the repercussions? Development takes more time. Getting bigger machines will only be a short-term fix. So, what do you do? Telepresence is a tool that makes hybrid local/remote developer workflow easier for Kubernetes users. Developers can build services locally, but Telepresence can proxy calls to other services to a remote cluster. Same with Azure’s cloud functions. These can be run locally too, but connected to remote cloud resources, allowing developers to create services made out of functions with a fast local developer workflow, while still having them run against a potentially extensive cloud environment.

Ending notes

Both monolith and microservices architecture are suited in specific circumstances based on what business you operate & at which stage is it. When doing microservices, make sure you are crystal clear about the goals you are trying to achieve. Those can’t be vague or else it might be a nightmare for your business. What’s your experience like with monolith and microservices? Did you migrate? Feel free to share your experience and outcomes with these software architecture patterns.

Adios!