Monolith
A monolithic architecture refers to the fact that your entire application is one large project or codebase. Let’s say you were building an online store. This single codebase must be responsible for every concern of the application from login, to account management, to the product listings, to the shopping cart, payment processing, etc. This is despite the fact that a catalog of products has very little to do with the processes which handle login or track shipments.
That sounds immediately critical, but there are advantages to a monolithic architecture. For example, while a monolithic application gets complicated at scale, when it’s codebase grows, for smaller applications, the overhead of building microservices is simply unnecessary. Monoliths are also generally easier to test, as all of their components are in one place for end-to-end access. They are also easy to deploy and scale horizontally as a single package that you can place on multiple server instances.
There are also several drawbacks to the monolithic approach, however. As stated above, when you get to an enterprise-level application, a single codebase becomes large and hard to handle. Every change in any feature requires a redeployment of the entire application. They also pose a barrier to updating and adopting new technologies, as that would require an entire application rewrite.
Microservices
A microservice architecture aims to break down a large application in several more manageable chunks. Using the example of an online store above, you could have a microservice, or even a micro application, dedicated to login. Another dedicated to your product catalog. Yet a third to handle payments and/or shipping. So on and so forth. Essentially, each concern of the application is broken into a separate project or service. While in many cases, especially at scale, this is a great approach, this is a double-edged sword, just like the monolith.
One disadvantage of the microservice architecture is that they add a lot of increased complexity upfront. As stated before, if you are making a small scale application, the overhead from making several independent services can be a large hurdle just to get off the ground. Microservices also add a lot of complexity in terms of end-to-end testing and integration. They need to be well coordinated to make sure communication doesn’t break down. They are also generally harder to deploy as they may need a variety of different runtime architectures. There are many advantages to a microservice approach as well though.
For one, each problem can be handled and managed independently. It makes the codebases more easily managed and the project can be broken up into more easily managed chunks and handled by specialized teams. New technologies can be adopted more easily, as you can update the services one by one, rather than all at once. And finally, changes and enhancements to the application don’t require the entire application to be deployed.
So Monolith or Microservice?
There is no one-size-fits-all answer. Generally, enterprise applications will benefit from a microservice architecture where money, expertise, and infrastructure are easier to come by. Also, the applications tend to be larger, so breaking them down to smaller pieces is a huge plus. On the other hand, smaller applications should stick to a monolithic approach. Despite the word “monolith” it is still a better approach for small teams or small problem sets where the infrastructure may not be available and the overhead simply is not worth the time and money.
Helpful link: https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59?gi=83e097231d0b
Top comments (2)
Good that you pointed out disadvantages with microservices. It's important for beginners to know that microservices is a not solution for everything. There's a question "Why should I probably not adopt microservices for my app?" in this article: devopedia.org/microservices
It's a decent summary but unfortunately doesn't spend enough time on a comparable pro and con list. Mostly because even pros and cons depend on your situation.
Like microservice don't need different runtime unless you use different platforms. But you don't have to, you can also use a single platform but split in services just to be able to guarantee the kind of isolation that allows you to deploy fast without having to review/test a larger application.
Also the cost of infrastructure is relative. You can build microservice in Elixir where its BEAM architecture provides distribution and resiliency so you don't necessarily need containers / orchestration.
On the other hand, even a Monolith of a smaller project might be micro enough to allow some deployment agility.
The main cost of microservice comes from setting up and maintaining enough logging and monitoring capacity to always be able to tell how things are going behind the scenes.
The main cost of monoliths comes from spending enough resources of review and testing to make sure working on one part of the Monolith didn't break something in a totally apparently unrelated part. A good architecture may mitigate some risk but will by no means guarantee it. You need to invest a lot more in testing upfront in this case.