What's up with Monolithic and Microservices Architecture

Monolithic Architecture

The literal meaning of Monolith is something huge, like a single giant stone. In the same way, the Monolithic architecture is the traditional unified model for the software development where the application is single-tiered in which the user interface and data access code are combined into a single program from a single platform.

The monolithic application can be also comprised of a series of components within a single platform such as User Authorization, Presentation View, Business Module, Persistence Layer, Integration Layer, etc. This application is designed to be self-contained and the modules are highly interconnected and interdependent, since the existence of tightly coupled components, it also requires all the components functioning for the whole program to be executed properly.

Monolithic Approach for E-Commerce Application (for checkout service)

The diagram below shows a very simple monolithic architecture for the E-Commerce application where Application UI represents the store web view. Similarly, it also consists of few services such as Address, Payment, and Order serving for the checkout process by using the same database. It might be possible that the services are modular and independent from each other but still, they must work together to fulfill the complete checkout process. And if something goes wrong with any of those single modules it might be possible that the whole system goes down.

When does Monolithic Architecture make sense?

• Simple to build - If the application you are building is simple, and everything is in the same language and framework.
• Simple to test - If you want to test your application quickly without any hassles just by launching some testing tools.
• Simple to deploy - If you have seldomly new features which will require to trigger the release of the whole application.

When does Monolithic Architecture pain?

• Difficult to maintain - If the Application gets too large and takes a long time to make changes or to understand the flow.
• Less reliable - If the release of new features gets increases, most likely the occurrence of the bugs also increases which could also bring down the whole application.
• Challenge to scale - If the system reaches a certain size, compiling, testing, deploying, etc. gets too expensive to maintain a decent uptime. And even scaling from the manpower point of view is difficult since it arises lots of conflicts while working together because of tightly coupled software architecture.
• No partial deployment - If you have frequent feature update then it leads to redeploy the entire application since the partial deployment of the module is not possible in this architecture.

Microservices Architecture

A variant of service-oriented architecture where the application is designed as a set of small services. It is composed of loosely coupled elements that have dedicated and bounded contexts and also has a well-defined interface to communicate with other services. Flexibility, scalability, and simplicity are few takeaways from this architecture which helps software developers to build complex applications. Netflix, eBay, Spotify, Amazon, Uber are some of the world-renowned companies that are truly benefiting from this architecture.

Unlike in the monolithic approach where the whole unit is connected with a single database, one can truly comfort from using a dedicated database for every single service to make it independent in a microservices architecture. Having a database per service is essential to make sure that the service is loosely coupled. The Flexibility of choosing the right tech stack as well as the right type of database for every single service is always there.

Microservices Approach for E-Commerce Application (for checkout service)

The approach below shows the simple implementation of Microservices Architecture for the checkout process in the E-Commerce application. Each service responsible for checkout process are dependent and loosely coupled, have their database, and served the service to the Application whenever it is requested. The failure of a single service will only stop serving the content from that service but it won't pull down the whole system to the ground and that's the key beauty of this architecture.

What to gain from Microservices Architecture?

• Highly scalable - Every single service can be scaled separately as per the requirements. And also the resources can be used more wisely if the scaling of the service demands more manpower.
• Productivity - This approach will allow the team members to work independently on the same project without much need of coordination and it is a better way for large teams. Decision making is quite easier for the team members since they are working decentralized based on the service and they could also choose the right tech stack for that service.
• Reliability - The failure of one microservice affects only one part where the client is using it which means it won't affect the overall performance of the software. And this is not the case in the monolithic approach.
• Deployment - This approach requires more effort for the deployment since one needs to deploys each service independently but the bright side is, the development team can always deploy their service at their convenience without doing much coordination with other teams. And if something goes wrong, it is much easier to rollback one small microservice than the entire app in the monolithic approach.
• Agility - Agility is a way to go. Microservices architecture allows a large team to get split into several smaller teams handling dedicated responsibilities for separate service which ultimately provides the possibility to work more efficiently by working in a short iterative development cycle.

What are the challenges with Microservices Architecture?

• High complexity - Being the existence of the several services that function independently requires the proper setup of communication channels that needed to be set to communicate between different modules and with the increment of services, this setup could get complicated to handle.
• Complex testing - Unlike, in the monolithic approach where all modules exist in the same unit, microservices have distributed applications where testing gets complicated since it requires lots of configurations to test between different modules.
• More time & effort - Since every single service is equipped with its database in microservices approach which requires better transaction management. Each independent unit has to be separately deployed and monitored which means the team has to put more time and effort into monitoring and preparing each service for the deployment.
• Cost - Cost factor is tricky and difficult to compare but still microservices architecture doesn't come cheap since it requires dedicated resources for every single service.

When to switch to Microservices Architecture?

• If you have a team with diverse knowledge of languages.
• If you want to tackle the scalability of every service independently.
• If your codebase is huge and difficult to maintain.
• If you see that the existing application could be chopped into several clusters to transform into service.
• If you have distributed teams in different countries.
• If you have some liberal timeline since transforming into microservices requires quite a bit of research and planning.

Are you really using Microservices?

If you think you are truly benefiting from microservices, perhaps the following questions make you think otherwise. 🙈

• Are you able to restart your services independently?
• Are you able to deploy your services independently?
• Does the modification on one service require synchronized modifications of others as well?
• Does the collapse of one database bring the whole system down?

Additional resources:

Why transition from monolith to microservices?

Everything you need to know to get started with microservices

Are you sure you are using microservices?

Conclusion

Like the Yin and yang ☯️, nothing in the world is perfect, everyone has their package to carry 😜. Choosing the right architecture for software development truly depends on the necessities and the circumstances. I hope with this article you got a bit about Monolithic Architecture and Microservices Architecture.

If you have any remarks, please feel free to drop the comments, I will be happy to pick it up 😁