This article was originally written for nurture.farm’s official blog – sprout. The original article can be found here.

Microservice-based architectures have evolved from monolithic architectures as the expectation from a software system increased in terms of speed of deployment, separation of concerns, and scalability. The software systems that cater to millions of requests per minute are increasingly becoming popular.

What are monoliths?

A monolith is a software architecture pattern where the different building blocks of an application are in one place.

What do we mean by building blocks? Let us try to understand using an example. We all have done online shopping. Think about the online shopping flow for a moment and list down different components of the shopping application. There are high chances that your list will have some or all components listed down:

1. Product Listing
2. Search bar
3. Product description page
4. Cart page
5. Payment page
6. Profile page
7. Order tracking page

Now, all these pages or components are powered by codes written somewhere. If the code of all these components is written in a single codebase and deployed together in one file, then we can term the architecture followed as a monolith.

Monoliths are a very good way to start a project which is yet to be proven in terms of user flow because it is relatively easy to develop, test and deploy. There are no external dependencies, and we can horizontally scale by adding more hardware resources to an extent.

Where do monoliths fail?

However, things become a little difficult as soon as your project starts having more components with a number of developers working on it. Let us discuss why.

1. In the example of e-commerce above, if your project starts consuming more memory than budgeted due to some bug in the search bar, your whole application might go down. This is particularly bad because search is not a P0 feature. A person with a weblink or some other way of accessing a product (maybe through a category page) will also not be able to buy a product, resulting in business loss.
2. A large project means a very bloated code base, which might slow down your IDE and affect developer productivity adversely.
3. We can always increase the number of machines to scale the system horizontally; however, we would hit a particularly dead end when the data grows beyond a certain size. Unlike applications, databases can’t be horizontally scaled easily (think MySQL).
4. Monolith usually means marriage to a particular set of the technology stack, and anything new is difficult to introduce. For example, when your monolithic application is built in Java, you want to introduce fast and efficient Go for a particular component that is more frequently used than other components.

Enter Microservices

Let us now see how microservice-based architectures approach this same example of a shopping application.

If there is a separate codebase for each of the components — listing, search, payment, description, cart, and the deployment of each component can happen independently and incrementally in isolation, then the architecture pattern followed is microservice architecture.

And why are microservices important? Each microservice is built around one particular business use case. A dedicated team can work on a particular service, e.g. payment, and keep developing it without disturbing any other components. The impact of changes is also localised.

And going by the example that we discussed earlier, the search component going down will not affect other components. Maintenance of the system is easy. And more commonly, the developers know what impact a particular piece of code has, which is not always the case in monolithic applications.

---

Read complete article here.

If you liked this article and would like one such blog to land in your inbox every week, consider subscribing to our newsletter: https://skillcaptain.substack.com