Microservices vs Monoliths explained – Scopify

If you’re a dev you’ve no doubt, come across people talking about monolith and microservice application architecture. Perhaps you are involved in designing a new system and have been asked to consider both architectures.  The conversations are often regarding how microservices are the successor to monolith architecture, but today I’m going to try and layout why it’s not as simple as one being better than the other.

Let’s have a look at what monoliths and microservices are in detail and in which scenarios you might want to use one over the other.

Monoliths

A monolith is the “traditional” method of application development. It’s an application built upon a single codebase comprised of a varying number of modules depending on the complexity of the application. The whole application is compiled into a single binary and it and any dependencies are hosted on a single system. Monoliths are best thought of as a non-distributed system.

It can be common to hear people refer to monolith systems as “legacy systems” however this isn’t always the case. If a monolith system is built well with the future in mind, suits the business’s needs, and is maintainable then it’s fit for purpose.

If we were to use a real-world example, let’s imagine we run a website for a clothes shop. In our monolithic system, all our modules are contained in the same system

And all these services are underpinned by the same hardware resources, with the codebase being one giant blob of complex (and probably highly coupled) fun for new and old to try and decipher.

Microservices

Microservices were originally designed to address various issues that are common with non-distributed systems such as, 

• No granular component scalability 
• Issues with multiple developers working on the same source code simultaneously
• Monoliths being a single point of failure 
• Cost
• A single unhandled error can lock up or crash the entire application

to name a few. 

A collection of microservices is an example of a distributed system, where each individual service is a self-contained piece of business functionality with clear interfaces that typically use technology agnostic protocols like HTTP/JSON/XML to communicate with other services.

To go back to our real-world example of a clothes shop, the microservice version would look something more like this

Where all the services have their own independent resources assigned to them which can be scaled up or down depending on demand, or completely swapped out if required. 

While in a microservices environment, everything is broken into component parts, the end-user experience will be no different than if they were using a monolith system. 

When to use a Monolith

Most businesses start off with a monolith application, big players such as Netflix, Spotify, Twitter, Amazon, and Linkedin started their business based on monolith architecture, only switching to a microservice model when they began to offer more services, traffic increased and the need for rapid development became a factor.

Starting with a monolith gives you direct control over every aspect of your service, you can jump in and change whatever you want whenever you want. This should simplify development early on as the only thing that needs to be coded and developed is the singular relationship between the components of the service and their external interface.

Code deployment on a monolith can also be very simple and straightforward if the application is simple and the deliverable is small.

Long-running monoliths tend to be found in places where data high security is a top priority and distributed microservices are too complex or too broad an exposure. Alternatively, where application speed is critical. The cost of communicating components is near zero when the code is in the same application stack. Meaning, developers do not need to think about, or code around, things like networks and availability

The disadvantages of Monoliths

Unfortunately, as monoliths grow in size (and they almost always do) the complexity involved with deploying code changes to them increases. There is more chance that a change is going to have some inadvertent impact on another part of the codebase because the dev was unable to foresee the interactions of the components they were working on.

Deployments in any system tend to get larger as customer requests and bug fixes increase. This causes deployments to get larger which in turn means longer downtime during the release maintenance windows. Larger releases also take longer to test and require gatekeepers to have comprehensive knowledge of the entire system. If you are using automated testing, the number of tests will grow as new functionality is introduced, and the test suite can end up becoming slow.

The only way to scale a monolith is to scale horizontally or vertically, preferably both in conjunction with a load balancer. This means increasing the available computational resource (vertical) and distributing the workload over many resources(horizontal) if possible. Vertical scaling on a monolith has diminishing returns & hardware bound limitations, whereas horizontal scaling requires the application to be loosely coupled therefore won’t work in every scenario.

Maintaining monoliths can be increasingly challenging. When a bug affects a single aspect of a monolithic codebase, it affects everything. Where a single microservice being unavailable may only affect one or two applications, with a monolith it could mean a period of unplanned downtime, not good. Small bugs reach a disproportionately large volume of coupled code and testing to guard against these bugs becomes a burden.

When to use Microservices

Microservice architecture is perfect for a company that needs to be able to quickly implement new changes and scale features of their systems granularly. Costs for deployment and development are also significantly reduced over time. 

Microservices offer inherent bug protection. Since the services are segmented, bugs will only affect a single part of the overall system. This means bugs are easier to locate, troubleshoot and fix due to their smaller (than a mid-size plus monolith) codebase. 

While overall system complexity is increased due to having many independent parts, the complexity of learning, coding, and maintaining a singular service is generally reduced, allowing a company to have service specialists who can be responsible for just one or a small handful of services.

Another major benefit of microservice architecture is improved extensibility. Where monoliths are normally stuck with a single technology framework, it’s usual for microservices to host a broad array of technologies and languages within a system. Individual components can be swapped out on the fly allowing for keeping up to date with trends in the market, innovation, rapid prototyping, and making sure your system is complying with the latest security features.

The disadvantages of Microservices

With all those advantages why use a monolith? Well, microservices are not best suited for every use case and carry their own fair share of disadvantages to consider. 

Microservices add significant network complexity. With monoliths, all the communication between modules is done on the same box in memory, but with microservices, you must identify how each service links to the others in the overall system. Adopting the microservice model becomes a trade-off between gaining simpler individual unit development in return for greater overall system complexity. The difference in overall system complexity when moving from monolith to microservices will of course depend on your current system requirements. For example, if you are developing a single-use application or something similar with a limited scope it wouldn’t make much sense in using a microservice model for your architecture due to the unnecessary complexity involved, these use cases are what monoliths are perfect for.

Security is another factor to consider, with a monolith almost all communication will be conducted in memory whereas microservices are typically sending a lot of data between each service over the network, this opens many more attack vectors for a bad actor to exploit your system.

Managing the provisioning of computing, memory, and storage resources for each service can also become a job, especially as the application scales up. Mismanagement or poor planning can also lead to huge cloud service bills due to the increase in data stemming from unoptimised intra-service calls and the increase in resource requests.

If you’re migrating from a monolith or starting fresh with microservices it’s likely, you’ll need a multi-discipline team, this could mean significant training/delays and the need to adopt an agile DevOps culture within the company.

So, is the Monolith dead?

It’s not unusual that people think of monolithic architecture as a precursor of microservices, however, it’s my hope that I’ve given a good explanation of why this isn’t the case and there are scenarios where one approach would be practical when building systems over the other.

After all, monoliths were (and still are) popular for a good reason, generally starting small and containing easily understood requirements together with fantastic performance make them ideal for a lot of situations. There are a lot of stigma around tightly coupled systems but when you’re speaking of a single-use application a high degree of coupling is just a fact of life, trying to decouple these systems with microservices would be adding unnecessary complexity for no benefit.

So no, I don’t believe the monolith is dead.

Conclusion

Microservice architecture provides a scalable way to manage growing data sets, leverage cloud storage, and automation, and deploy solutions fast, microservices are usually preferable to monoliths. However, they might not always be the best choice for an organization if their goals are relatively simple. Before deciding on microservices, a good understanding of the scope of the project and your company’s capacity to support a microservice environment is critical.