Microservices vs. Monolithic Architecture

The evolution of technology has changed the way we design application architecture. Docker, cloud services, and container orchestration platforms let us build distributed solutions that are more scalable and reliable. In this article we compare microservices architecture with monolithic architecture, look at which teams and projects should choose each one, and break down their advantages and disadvantages.

At a glance, the difference between the two can be illustrated like this

It's not entirely true that monolithic applications are always simple, but microservices tend to be ten times larger and almost always require more resources.

Let's go point by point through the pros and cons of each.

Deployment

With a monolithic application, you set up the deployment once and then just tweak it as changes come in. That said, there's also a single point of failure during deployment, and if something goes wrong, you can break the entire project.

Microservices demand a lot more work: you have to deploy each microservice separately, handle orchestration tooling, and try to standardize the format of your CI/CD pipelines to cut down the setup time for each new microservice. But there's an upside too: if something fails, you only break one small microservice, which is far less serious than taking down the whole project. It's also much easier to roll back a small microservice than an entire monolithic application.

Maintenance

If you're going to use a microservices architecture, bring a DevOps profile onto the team and brace yourself. Not every developer knows Docker or orchestration tools like Kubernetes, Docker Swarm, Mesosphere, or anything else that helps you manage an infrastructure with so many moving parts. Someone has to monitor and maintain the CI setup for each microservice and for the infrastructure as a whole.

Reliability

This is where microservices architecture wins hands down. If a microservice fails, only one part is affected, and only the customers using it run into problems, no one else. For example, if you're building a banking app and the microservice handling withdrawals goes down, that's clearly less serious than having to shut down the whole application.

Scalability

When it comes to scalability, microservices are once again the better option. Monolithic applications are hard to scale because, even if you add more workers, each one runs the entire project, which is an inefficient use of resources. Worse still, the code might be written in a way that makes horizontal scaling impossible, leaving vertical scaling as your only option. With microservices it's much easier: you can fine-tune resource usage and scale only the parts that actually need it.

Cost

Cost is hard to pin down, because monolithic architecture comes out cheaper in some cases and not in others. For example, thanks to the better scalability of microservices, you can set up autoscaling and pay more only when user volume genuinely calls for it. But at the same time, keeping that infrastructure running requires a DevOps profile, and that has to be paid for. A small monolithic application can run on $5-20 hosting with snapshots enabled. With a large monolithic application, on the other hand, you might have to pay for a very expensive instance, since you can't split it across several small, cheap servers.

Development

On a project with 16 microservices, experience shows it can get complicated to manage. The best way to work with microservices is to build your docker-compose file from the start and develop with Docker. That way you cut down onboarding time for new people: they just need to spin up the system from scratch and start whichever microservices they need. Opening more than 10 terminal windows and running commands to start each service separately is a nightmare.

On the other hand, when you're developing a microservice, you may not need to run the rest of the application at all. And there are fewer git conflicts, since tasks are divided better and developers can work in isolation on different microservices.

Code review and QA are simpler with microservices; you can even write each microservice in a different language.

Releases

Smaller microservices, with a solid communication architecture between them, let you ship new features faster by cutting down QA, build, and test execution time. Monolithic applications have plenty of internal dependencies that can't be separated. There's also a higher risk that what you push depends on your teammates' unfinished changes, which can delay releases.

Which architecture is right for you?

Use a monolithic architecture if:

• you have a small team.
• you're building the MVP of a new product.
• you haven't raised millions in funding to hire DevOps profiles or spend extra time on a complex architecture.
• you have experience developing with solid frameworks, like Ruby on Rails, Laravel, etc.
• you don't see performance bottlenecks in key features.
• microservices only appeal to you because they're trendy.

Keep in mind that if you find down the road that your project needs microservices, you can always break up the monolithic architecture into smaller microservices later.

Use a microservices architecture if:

• you don't have a tight deadline; microservices require researching and planning the architecture so everything works.
• your team is comfortable with multiple languages.
• you care a lot about the scalability and reliability of your product.
• you might end up with several development departments (possibly even in different countries or time zones).
• you already have a monolithic application and see problems in parts that could be split into several microservices.