Myth 1: Breaking monolithic to smaller services is Microservice
Let’s get a basic understanding on what is a microservice, to break this myth. To quote one of the popular definition from Martin Fowler,
“Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies”.
Let’s try to get some insights through the keywords from the above definition and understand what it means to be.
- Small services built around business capabilities: Services need to be small and derived out of the domain. The key question here is how “small” is quantified? I really don’t see anybody can quantify what “small” is in general context. The main intent would be to decompose the system to services through DDD which shall be independent, self-contained, highly cohesive and equally important, it would be developed by a smaller team. When such services are derived out of the System, it would be small enough to achieve maximum agility when built with the right tools and technologies.
Conceptually Monolothic vs Microservice:
Technically Monolothic vs Microservice:
Team Monolithic vs Microservice
- Independently deployable by deployment machinery: All these services need to be independent and deployed in automation. Automated deployment is very important when the application is designed with microservices. When an application is designed with multiple autonomous services, we need to administer multiple services compared to a single large monolithic application. If these services are not auto deployed, the administration of these multiple services will be a nightmare and break the core principle of microservices bringing agility
So, just breaking a large monolithic application/design into smaller services will not qualify it to be a microservice.
Myth 2: Microservices provide better architecture and agility compared to Monolithic
This is not always true. Let’s see how agility has evolved over the years. First, agility started with process with scrum practices, then advanced in development practices like CI, TDD, and BDD. It then advanced with Ops like devops tools & technologies. But even with these improvements, the agility of time to market a change in a large monolithic design was still a challenging task.
With the maturity of devops, containerization, and domain driven design, microservices brings agility and increased productivity. But this is really not true for all the cases. Still, for a less complex or relatively small application, monolithic is best in achieving the goals with a high productivity and agility, as compared to microservices design. The complexity in testing, operations, and distributed computing fallacies that microservices brings in is really not required for these less complex application and it will only multiply.
So it is not always that microservices is better compared to monolithic design.