Micro-service architecture, a word that has grabbed everyone’s attention and is gaining momentum everyday. So, what is micro-service, why does everyone want to shift to it and why do we need it? Let’s understand the concept of micro-service architecture in detail.
The central idea behind micro-services is that some types of applications become easier to build and maintain when they are broken down into smaller, create able pieces which work together. Each component is continuously developed and separately maintained, and the application is then simply the sum of its constituent components. This is in contrast to a traditional, “monolithic” application which is developed all in one piece.
In a monolithic architecture, we will need just one code base. That code base will have all code related to all modules. For small projects monolithic architecture is preferred. The actual issue arises when the number of modules increases significantly.
Issues that could arise because of monolithic architecture are:
- It will be difficult to manage the code base
- Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements
- Monolithic applications has a barrier to adopt new technologies. Since, changes in framework or languages will effect an entire application, it is extremely expensive in terms of time and cost
- Another problem with monolithic applications is reliability. Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application
- You must redeploy the entire application on each update
- Impact of a change is usually not very well understood which leads to do extensive manual testing
Micro-service architecture says that we divide our application in small independent services which works independently and ideally do not communicate with each other. This could be said that A service has no knowledge about B service.
Basically, the idea is to split your application into a set of smaller, interconnected services instead of building a single monolithic application. Each micro-service is a small application that has its own hexagonal architecture consisting of business logic along with various adapters. Some micro-services would expose a REST, RPC or message-based API and most services consume APIs provided by other services.
Also, not only code base, complete micro-service architecture says each service will have its own database and that database access is limited to particular service only.
Benefits of Micro-services
- It tackles the problem of complexity by decomposing application into a set of manageable services which are much faster to develop, and much easier to understand and maintain
- It enables each service to be developed independently by a team that is focused on that service
- It reduces barrier of adopting new technologies since the developers are free to choose whatever technologies make sense for their service and not bounded to the choices made at the start of the project
- Micro-service architecture enables each micro-service to be deployed independently. As a result, it makes continuous deployment possible for complex applications
- Micro-service architecture enables each service to be scaled independently
Drawbacks of Micro-services
- Using micro-service architecture means using distributed system. So, now there will be calls to various services at some facade layer (aggregation layer), where we need to handle RPC and service calls failure
- Testing the architecture becomes difficult
- Major issue comes when debugging the issue. To debug the issues, we need something to link calls between different services (done via distributed tracing)
- In micro-services, our database are also partitioned. If a business requires transactions between various services then we need to take care of distributed transactions (SAGA Pattern)
- You need to monitor and manage multiple applications