Microservice vs. Monolith: Which One to Choose?
Microservice vs. Monolith: Which One to Choose?
Learn when it's the right time to adopt microservices and why you first need to understand lots of related concepts as well as DevOps ideas like automated deployment.
Join the DZone community and get the full member experience.Join For Free
Record growth in microservices is disrupting the operational landscape. Read the Global Microservices Trends report to learn more.
"Microservice" is a buzzword in the industry, right? Apart from microservice design, other designs are marked as "Monoliths." But as an architect, when trying to create new software based on a specific domain, what will you do? Adopt microservices without judging as this is the one everyone is getting behind, or stop for a second and think about your company infrastructure and employee expertise, and based on that, choose microservices.
As architects, it is our duty to choose microservices when it is required, not going with the flow and using microservices. In this tutorial, I will talk about a few aspects I think are most important before you adopt microservices. I am open to hearing any other proposals or aspects to cover which I missed, even counter-logic — these are my realizations while working on microservice, and so-called monolithic, architectures.
Let's begin with the aspects to consider before choosing microservices as a default architecture.
1. Strength of Project Associates
When you are starting a project, the first parameter to consider is, how many associates are going to work on this project? What are their experience levels? If your strength is low, like 10-12, don't go for microservices, as microservices mean independent services, and the motto is "You build it, you run it." There should be one team with complete ownership of a microservice. If your associate strength is small, statistically, one or two people have ownership of two or three microservices, and it creates a critical problem; knowledge is confined to them and they will become a pivot employee. Also, if one or two people take ownership of two or three microservices, the motto "Developers should only focus on a small portion but know everything about that service" is going to break. So think about that.
2. Microservice and It's Associated Knowledge
Microservices is a new architecture and there are various concepts related to microservices, like distributed architecture rules, high availability, resiliency, service discovery, the CAP theorem, domain-driven design, circuit breaker patterns, distributed cache mechanisms, and route tracing. DevOps culture is tightly coupled with microservices in order to unleash their full power, so you need to know CI/CD tools and their culture (automated deployment). The team should be efficient to drive all of these for microservices. If the microservices are deployed in the cloud or a container, the team should have an understanding of cloud architecture (PCF, Amazon, Bluemix, etc) or container architecture (Docker, Docker Swarm, Messos, Kubernetes, etc). Think carefully about the team's knowledge — always remember that, when you are dealing with microservices, it means multiple services and multiple teams, so each team member should have a clear understanding of all the associated knowledge needed to run their microservices independently. If you don't have such leisure, make sure that for each team, one or two people know all the associated knowledge so they can educate their team.
Another important dimension is the organizational infrastructure. Before adopting microservices, always check in what mode your organization works. As per Conway's law, whatever your organization's structure, that is reflected in your code implementation. Check if your organization has adopted Agile technology. Is the team built with cross-technology members like UI, middle layers, and a database? What are the deployment and QA test modes — does your organization follow manual deployment and manual testing, or have they adopted DevOps culture. Where are the artifacts going to deploy? Does the organization have servers where you install application servers and deploy your artifacts, or has the organization moves to the cloud? Based on these parameters, choose whether you are going to adopt microservices or not.
If the organization has its own servers where application servers are installed, all the different microservice artifacts are going to deploy to the same server space, which does not fulfill horizontal scaling, so microservices adoption will be in danger.
In the case of manual testing and manual deployment, adopting microservices is a nightmare for the Ops and QA teams. For developers, it is a nightmare to integrate the changes and test in SIT.
Check the nature of the domain you are working on. Sit with a business analyst to understand how critical this is — is there a need to break the domain into subdomains so that related functions can be encapsulated under a context? Based on that, make a decision if the domain is very complex. If not, it is better to stick with a monolith, so there's no need to create a context map and encapsulate subdomains in a bounded context.
The Budget of the Project
This is another important aspect to look at. Think about the budget of the project; is the nature of the project fixed bid or TNM? Microservice projects are more expensive than monoliths, as they need more servers or cloud infrastructure, an automated pipeline, count of resources, and the whole team should be a cross-skills team. In terms of infrastructure and resources, it is much more costly than a monolith, so think about how the budget aligns with your project.
Secretly, I am giving you a tip — please do not publish it to anyone: as a good, loyal architect, always think about revenue margin. A modular monolith is better than microservices in the case of a small budget as it serves the purpose of revenue and, if you want to move to microservices in the future, that is also possible.
Microservices technology hit in such a way that novice or mid-level developers think a monolith means a BBOM (big ball of mud) with all modules tangled with each other, but if you maintain a modular approach, it is good, and in many cases, it is better than microservices when our resources are finite. Choose carefully and don't go with the flow.
I always recommend going with a monolith first, but make it modular. If you use Java 9, use modules; otherwise, you can adopt SOA, but start with a modular architecture and when there's an actual need, like the module boundaries are going to leak or you can't maintain Acyclic Graph (DAG) among modules, then think about breaking up the monolith on the basis of DDD and leaning towards microservices.
What I am trying to say is, do not use microservices just because others are adopting it. Adopt it when you need it. In many cases, I saw a project try to adopt microservices, but just because of lack of knowledge, they created a project that was neither a microservice nor a monolith. They created many services without proper encapsulation and each service was chained with others in such a way that one agile team can't make an independent decision on deploying one microservice. Multiple teams and multiple artifacts depended on each other. Teams were blaming each other as functionality spanned over many services — a horrible situation. I will discuss that in my future articles. For now, think twice before adopting microservices — as Uncle Ben said, "With great power comes great responsibility."
Published at DZone with permission of Shamik Mitra , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.