Before the concept of microservices evolved, most web-based applications were built using a monolithic architectural style. In a monolithic rchitecture, an application is delivered as a single deployable software artifact. All the UI (user interface), business and database access logic are packaged together into a single application artifact and deployed to an application server.
While an application might be a deployed as a single unit of work, most of the time there will be multiple development teams working on the application. Each development team will have their own discrete pieces of the application they’re responsible for and oftentimes specific customers they’re serving with their functional piece.
For example, customer relations management (CRM) application that involves the coordination of multiple teams including the UI, the customer master, the data warehouse and the mutual funds teams. Below Figure illustrates the basic architecture of this application.
The problem here is that as the size and complexity of the monolithic CRM application grew, the communication and coordination costs of the individual teams working on the application didn’t scale. Every time an individual team needed to make a change, the entire application had to be rebuilt, retested and redeployed.
A microservice is a small, loosely coupled, distributed service.
Microservices allow you to take a large application and decompose it into easy-to manage components with narrowly defined responsibilities. Microservices help combat the traditional problems of complexity in a large code base by decomposing the large code base down into small, well-defined pieces. The key concept you need to embrace as you think about microservices is decomposing and unbundling the functionality of your applications so they’re completely independent of one another. If we take the
CRM application we saw in above figure and decompose it into microservices, it might look like what’s shown in below figure.Looking at below figure, you can see that each functional team completely owns their service code and service infrastructure. They can build, deploy, and test independently of each other because their code, source control repository, and the infrastructure (app server and database) are now completely independent of the other parts of the application.