“Microservice” is a Buzzword in the industry right? Apart from Microservice, design rest of the design marked as “Monolith”. But as an architect, when you are trying to create a new Software based on a specific Domain what will you do? Adopt Microservice without judging anything as this is the hit one, every one runs behind it or just stop for a second and think about your company infrastructure, employee expertise and based on that choose Microservice.
As an Architect it is our duty to choose Microservice when it is required and not going with the flow and use Microservice. In this tutorial I will talk about few aspects, which I think most important before you adopt Microservice. I am open to hear any other proposal or aspects to cover which I missed, even counter logic. This is my realization while working In Microservice and so-called Monolith both the architectures.
Let’s begin with the aspects to consider before choosing Microservice as default architecture.
1. Project associates Strength: While you get a project the first parameter to consider is how many associates are going to work in this project and what are their experiences. If your strength is low, like 10-12 don’t go for Microservices, as Microiservices means independent services and the motto is “You Build it you run it”. So, one team should complete ownership on a Microservice. If your associate strength is small statistically, each one or two persons will 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. On the other side, if one/two persons take ownership of two or three microservices, the motto, Developers should only focus about a small portion but know everything about that service is going to break. So what do you think about that?
2. Microservice and It’s associate Knowledge: Microservice is a new architecture and there are various concepts inter-related with Microservice like Distributed Artechtures rules, like High availability, Resiliency, Service discovery, CAP theorem, , Domain-driven Design, Circuit Breaker pattern, Distributed cache mechanism, Route Tracing etc. Not only that DevOps culture is tightly coupled with Microservice in order to unleash the full power of Microservice. So you need to know CI/CD tools and it’s culture (Automated deployment). The team should be efficient to drive all of these for a Microservice. If the Microservices deployed in cloud or 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 knowledge, always think when you are dealing with Microservices it means multiple services and multiple teams, so each team member should have clear understanding all of the associated knowledge to run it’s Microservices independently. If you don’t have such leisure make sure for each team to have one or two persons, who know all the associated knowledge so they can educate their team.
3. Organization Infrastructure: Another important dimension is Organization infrastructure. Before adapting Microservice always check in what mode you organizations work. As per Conway’s law whatever your organization structure that is reflected in your code implementation. So check, is your organization adopt the Agile technology? Is the team built with cross-technology member (Like UI, Middle layer, Database), What are the deployment and QA test mode, is your organization follows manual deployment and manual testing, or they are already or going to adopt DevOps culture, Where the artifacts going to deploy, is Organization has few servers where you install Application servers and deploy your artifacts or Organization move to Cloud. Based on these parameter choose are you going to adopt Microservices or not. If Organization has its own servers (few) where application servers are installed, in that case, all the different Microservice artifacts going to deploy same server space, which does not fulfill the Horizontal scaling so Microservices adoption will be in danger. Also in case of Manual testing and Manual deployment if you adopt Microservice it is a nightmare for Ops team and QA team. Also for a developer it is a nightmare to integrate the changes and test in SIT.
4. Domain Criticality: Check the nature of the domain you are working on. Sit with Business analysist and understand how critical is this, is there such a need where we need to break domain into subdomains so that related function can be encapsulated under a context based on that decision if Domain is not very complex? It is better to stick with Monolith. No need to create Context map and encapsulate subdomains in a Bounded Context.
5. The budget of the Project: This is another important aspect to look on. Think about the budget of the project. The nature of the project is fixed bid or TNM type. Microservice projects are expensive than monoliths as it needs more server or cloud infrastructure, Automated pipeline, Count of Resources, all team should be cross skills team. So in terms of infrastructure and resources level it is much more costly than Monolith. So think about what the budget aligned with your project (Secretly I am giving one tip to you: Please do not publish to anyone. As a good Loyal Architect Always Think about Revenue margin, a modular monolith is better than Microservice in case of small budget it serves the purpose of Revenue. In future if you want to move to Microservice also that is possible.)
Conclusion: Nowadays, Microservices technology hit in such a way. Novice or mid-level developers think Monolith means bad it is a BBOM (Big ball of mud) all modules are strangled with each other. But If you maintain modular approach, It is good and many cases it is better than microservices when our resources are finite. So choose carefully not go with the flow. I always recommend to go with Monolith first but makes it Modular. If you use Java 9 use Module else you can adopt SOA but start with modular one and when there’s an actual need, like Module boundaries are going to leak, or you can’t maintain Acyclic Graph (DAG) among modules, then think for beaking Monolith basis on DDD and can lean towards Microservices.
Not before that, what I am trying to say is: Do not use Microservices as Others are adopting it. Adopt it when you need it. I saw many cases where some project try to adopt Microservice but just because of lack of knowledge they create such a project which is neither a Microservice and nor a Monolith. They create many services, without a proper encapsulation and each service chained with other in such a way one Agile team can’t take an independent decision on deploying one Microservice, multiple teams, multiple artifacts depends on each other, Teams are blaming each other as functionality span over many services, It is a horrible situation. I will discuss that in my future articles. But for now think twice before adopt Microservice as Uncle Ben said “Great power comes with Great Responsibility”.
| Published on Java Code Geeks with permission by Shamik Mitra, partner at our JCG program. See the original article here: Microservice Vs Monolith:Which one to Choose? Opinions expressed by Java Code Geeks contributors are their own. |
