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

Video

https://youtu.be/iKuDvNYDuHA