The evolution of technologies has changed the way we build the architecture of applications. Docker, Cloud services, and Container Orchestration services brought us ability to develop distributed, more scalable, and reliable solutions. In this article, we will compare microservices and monolith architecture, discuss what teams and projects should use what type of architecture, and explore their advantages and disadvantages.
At a glance, the difference between those types can be illustrated like this
It is not strictly true that monolith apps are always simple, but microservices are often 10 times larger and almost always requires more resources.
Let’s discuss the pros and cons of each, point by point.
Deployment
Monolith apps allow you to set your deployment once and then simply adjust it based on ongoing changes. At the same time, however, there is also only a single point of failure during deployment and, if everything goes wrong, you could break your entire project.
Microservices require much more work; you will need to deploy each microservice independently, worry about orchestration tools, and try to unify the format of your ci/cd pipelines to reduce the a amount of time required for doing it for each new microservice. There is a bright side, however; if something goes wrong, you will only break one small microservice, which is less problematic than the entire project. It’s also much easier to rollback one small microservices than and entire monolith app.
Maintenance
If you plan to use a microservices architecture, get a DevOps for your team and prepare yourself. Not every developer will be familiar with Docker or orchestration tools, such as Kubernetes, Docker Swarm, Mesosphere, or any similar tool that could help you to manage infrastructure with a lot of moving parts. Someone has to monitor and maintain the functioning state of your CI configuration for each microservice and the whole infrastructure.
Reliability
Microservices architecture is the obvious winner here. Breaking one microservice affects only one part and causes issues for the clients that use it, but no one else. If, for example, you’re building a banking app and the microservice responsible for money withdrawal is down, this is definitely less serious than the whole app being forced to stop.
Scalability
For scalability, microservices are again better suited. Monolith apps are hard to scale because, even if you run more workers, every worker will be on the single, whole project, an inefficient way of using resources. Worse, you may write your code in the way that would render it impossible to scale it horizontally, leaving only vertical scaling possible for your monolith app. With microservices, this is much easier. Resources can be used more carefully and allow you to scale only that parts that require more resources.
Cost
Cost is tricky to calculate because monolith architecture is cheaper in some scenarios, but not in others. For example, with the better scalability of microservices, you could set up an auto-scale and only pay for that when the volume of users really requires more resources. At the same time, to keep that infrastructure up and running you need a devops that needs to be paid. With a small monolith app, you could run on a $5-$20 host and turn on the snapshot. With a larger monolith app, you may host a very expensive instance because you can’t share it over multiple small, cheap hosts.
Development
In one of our projects, we have 16 microservices and I could tell you from experience that this can be tricky to deal with it. The best way to deal with microservices is to build your docker-compose file from the beginning and develop through Docker. This helps you reduce the time spent onboarding new people; simply run the system from scratch and launch all microservices as needed. Opening 10+ terminal windows and executing commands to start each individual service is a pain.
On the other hand. when you develop one microservice, you may have a case in which you don’t need to run other parts of the application at all. This results in fewer problems with git conflicts due to the better process of breaking down tasks and the ability to isolate developers across microservices.
Doing code review and QA is simpler with microservices; you may even be able to write microservices in different languages.
Releasing
Microservices that are smaller and with a proper architecture of microservices communication allow you to release new features faster by reducing QA time, build time, and tests execution time. Monolith apps have a lot of internal dependencies that could not be broken up. There is also a higher risk that something you are committed to could depend on unfinished changes from your team members, which could potentially postpone releases.
What’s architecture better to you?
Use monolith architecture if you:
- have a small team.
- build the MVP version of a new product.
- did not get millions in investments to hire DevOps or spend extra time on complex architecture.
- have experience of development on solid frameworks, such as Ruby on Rails, Laravel, etc.
- don’t see performance bottlenecks for some key functionality.
- think that microservices are cool and it’s a trend.
Keep in mind that if you find out that there is need of microservices in your project, monolith architecture always carries the risk of break down as a result of these small microservices.
Use microservices architecture if you:
- don’t have a tight deadline; microservices require you to research and architecture planning to ensure it works.
- have a team with knowledge of different languages.
- worry a lot about the scalability and reliability of your product.
- potentially have a few development departments(maybe even in different countries/time zones).
- have an existing monolith app and see problems with parts of your application that could be split across multiple microservices.
Top comments (14)
Thanks for this great writeup!
I would like to add two points, which is are not mentioned - at least not explicitely:
a) Developer skillset
It requires different skillsets to run one or the other. If you have a team with sharp skills developing microservices, it would be reasonable to think of doing microservices for upcoming projects.
b) Although monoliths aren't always simple, agreed. But are in terms of complexity easy to reason about. In the world of microservices a simple function call turns into a distributed systems problem. With a bit of humor:
twitter.com/tenderlove/status/1027...
But anyways a good thread.
P.S:
You could - of course - do microservices with a team, knowing only one language ;)
Great article on giving an overview, but i must strongly disagree on the bullets against microservices.
have a small team.
build the MVP version of a new product.
did not get millions in investments to hire DevOps or spend extra time on complex architecture
have experience of development on solid frameworks, such as Ruby on Rails, Laravel, etc.
don’t see performance bottlenecks for some key functionality.
think that microservices are cool and it’s a trend.
agree, let me say that there always be exceptions. some team would be fine with doing microservices and maintaining them even with 1-2 people. Some team will be suffer with devops and 10 devs.
achievable definitely yes, but it could take weeks of work without knowledge of how to do so and what does it even mean. With Kubernetes developer without a proper background will have pain on each step because he will need to configure cert manager, he will need to learn yaml syntax required for Kubernetes configuration, terminology, architecture of Kubernetes, then the simple tasks he get used become a problem as well such as - ssl certificates renewal, persistent storage, self hosted or cloud docker registry, configuration of ci/cd services. From perspective of project delivery, it's definitely not the best time thing to spend time on.
Microservices suppose to have a small as possible isolated parts of your application. I can't imagine that any real product even on the MVP stage could just have 2 microservice. It will be mostly Monolith + maybe 1 microservices, but definitely not a microservices architecture.
Microservices on laravel? I don't think someone will be build microservices on laravel framework, there are a lot of alternatives for PHP to make microservices smaller and better than grab all stuff laravel could get to you
that's advice could be addressed for everything development related. Don't go ahead with technology for production usage if you the only one reason you chose it is "it's cool"
Someone has to do the hosting even of your monolith and it comes down to either a developer or a devops. and i think we can agree that is way more pain hosting a LAMP or whatever sytem and maintaining it than to have docke swarms or kubernetes clusters. especially when you start a new project.
Instagram clone, one services handeling accounts one service distributing images without extracting the database handling logic out of it. Yes you can split it further by one for rendering images and so on. But here you have the point. You start with a small microservice layout. and as soon as you se it gets to complex you split a service again. this is the point of having an evolving microservice architecture. You cannot possible all the services that you will end up with.
Laravel even have a microservice addition: lumen.laravel.com/ :D
There is no this now not a microservice, for example you have an onlineshop and you are using laraval for model creation in each of the services.
An important point is: "There is nothing inherently “micro” about microservices per se. While they tend to be smaller than the average monolith, they do not have to be tiny. Some are, but size is relative and there’s no standard of unit of measure across organizations."
No it's not. If you plan to develop your app using microservices then you need a really good architecture, otherwise it will become a monolith application with set of packages. The main goal is creating different domain knowledges on different developers, so that the developers won't need to know the whole system to develop anything. But then it comes with a challenge of "communication", which requires a good architecture, devops and planning.
Nobody would like to invest millions and wait years and years to make profit, when its not really clear that project will be a success nowadays. So the rapid application development is always the best choice for startups.
Get the MVP fast, see the success, make profit, see the future requirements. You can always rewrite the app at some point since the app is already success.
This is a interesting blog for comparing Microservices and Monolith. And also lots of interesting reply’s.
What I feel is micro service is not always good and Monolith is not always evil. Both has pros and cons. And in real case those 2 minds should be used hybrid. It depends on what is your product, what is the expected scale and complexity and lots of factors.
Decouple a project is like cutting a cake, the key is not how small you can cut but how to cut it in to the right size.😀
In my view. microservices recently became much simpler to manage and deploy. I wouldn't stay they are reserved only for big and complex applications. Especially now that you can use different serverless approaches to architect your services.
I recently wrote a blog post on this topic, curious to hear what you think: blog.webiny.com/the-serverless-sup...
Hi Alex :) How are you?
That's an interesting perspective! A colleague recently wrote an article on microservices as well, based on his experience as a software developer. In the article he shares positive and negative aspects of working with microservices, maybe it can interest you: uruit.com/blog/microservices-archi...
Nice post.
I miss the paragraph about debugging. I'm interested to know your thoughts about debugging the Monoltyh and Microservice Architecture solutions.
Just published the article with guide for Docker/Node.js debugging. You could take a look on it, if that's a technology stack you use.
dev.to/alex_barashkov/how-to-debug...
Thanks for the info. I've just marked this post, and I'm going to read it in my free time.
Cheers!
Hi Rafal,
Good point, I think I missed it because from our tech stack there always no difference. We use mostly Node.js, so in order to debug it you just need to expose extra port and allow access to debug from any address. Probably, I will write a mini article about it during this week.
So unfortunately can't say how debug goes with other languages.
You have explained it very clearly. I am very new to it but got a very clear concept of what to do and what not.