Microservices (Part 1) — Introduction
Monolithic Application Architecture
Monolithic application architecture is the architecture followed by most of the developers to create enterprise-level applications before the emergence of Microservices. In Monolithic applications, all the business modules run in a single process which is typically a WAR/EAR file. Classes of these different modules may talk to each other and they also may use the same libraries. There are many coupling between these modules. Moreover, Monolithic applications typically use a single database containing multiple tables related to all the available business modules. A monolithic application contains 3 main tiers namely the client tier, server tier, and database tier.
Example: Consider an eCommerce application. This application may contain components like,
- webserver
- load balancer
- catalog service
Advantages of Monolithic
- Easy to test the overall application(Integration testing).
- Easy to Monitor.
- Simplicity.
However, this architectural style is inadequate for large enterprises as there are some major disadvantages.
- Strong coupling between different modules of the application.
- Large application size and complex in nature.
- Harder for developers to understand and make changes quickly.
- Any updates require a complete re-deployment of the entire application.
- Less scalable.
- Less reusable.
Microservices Architecture
Definition —
Microservices is an approach for developing a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms, often an HTTP resource API.
Microservices is basically an architectural style that helps to overcome the problems faced in monolithic applications. In a microservices architecture, all the services should be built around particular business capabilities and they should be independently deployable. These services can be written in different programming languages and use different data storage technologies as well.
Scaling: Monolithic vs Microservices
A monolithic Application has to replicate the entire system across multiple servers in order to scale. This is a very complex and costly process with a lot of disadvantages. There is a huge wastage of resources as some of the functionalities may not be required in the replicating instance.
A Microservices application scales by distributing only the required services across servers. This has many advantages over the scaling done in monolithic applications.
- The resources are better utilized.
- The overall cost is less.
- Fewer configurations to be done.
Scale Cube in Microservices
Scale cube is a scaling model introduced in a famous book called “The Art of Scalability”. According to this model, the scaling is done in 3 main axises namely X, Y, and Z.
- X-axis: Refers to the process of running multiple copies of an application behind a load balancer. The problem with this scaling is that all the copies need to potentially access all of the data.
- Y-axis: Refers to scaling of the application by splitting it into multiple different services. Each service has a dedication functionality.
- Z-axis: Each server runs an identical copy of the code. However, each server is responsible for only a subset of data.
Characteristics of Microservices
(According to martinflower.com. Please check the website for more information.)
Componentization Via Services
In the microservices architecture, all the services are treated as components. That means these services do not share SDKs or Libraries between them. This is done in order to avoid the coupling between these services. As mentioned in the first section, these services are independently deployable. That means these services can be deployed without affecting other services in the application as there are low couplings.
Organized around Business Capabilities
Think about a traditional organization. Teams are organized according to the technology. As an example, there may be teams like the front-end team, back-end team, QA team, etc. Microservices architecture follows a different team structure.
In the Microservices architecture, teams are organized as inventory, finance, shipping, etc. That means the teams are organized according to the business capability. These teams are cross-functional. They may contain people from all aspects such as developers, QA personals, etc. Teams can contain 8–10 people(2 pizza teams).
Products Not Projects
In the traditional software development model, the delivery team will create software according to the present requirements and deliver it. They may hand over the software to the maintenance team and move on to a new project.
In the microservices architecture, the teams have ownership of the components over their full lifetime. Therefore these components are named as products.
Smart End Points and Dumb Pipes
In the traditional software development process, developers use powerful middlewares like ESbs to route messages, apply business logic, etc. In the Microservices architecture, the smart lines in the endpoints and not in between the endpoints. This is done in order to make the application more decoupled and cohesive.
Decentralized Governance
In the traditional monolithic application development process, there is a predefined fixed set of rules regarding the technologies and patterns to be followed. As an example, the application modules are written in the same language and may use the same type of database. This is different in the microservices architecture. Each service has its own governance.
Decentralized Data Management
In monolithic applications, a change to the database will affect all the components as there is a single central database. In the Microservices architecture, every service is responsible for its own data and own persistence. There is no unique data model approach.
Infrastructure Automation
It is the technique used to reduce human interactions with IT systems. This is done by creating scripts or functions for repeatable actions. Microservices need to implement services such as continuous delivery, blue-green deployment, etc.
Design for Failure
All the services have a possibility to fail at a given time. Therefore it's a must to handle these failures in a correct way. Microservices architecture can use monitoring tools to check the status of different services and better prepare for failure. Moreover, there are tools like “Chaos Money” that are used to test the resiliency of services.
Evolutionary Design
In the microservices architecture, there should be more granular release planning. Should always try to identify change impacts and fix them as soon as possible.
Important Points
- It's important to note that the microservices architecture should be implemented carefully. If developers try to create granular microservices, the architecture will fail. why?
Think about a situation where an application has a user login and user registration process. What if we try to put these 2 functionalities in separate services?
The application will be slower as the microservices take time to talk to each other. Therefore, there should be the right balance between these services.
- Before implementing Microservices architecture, the developers should always have a clear idea about the domain and objective of the application.
- The developers can use any language to develop microservices. However, most developers go with Java.
- The Design should always be a Domain-driven design. There must be a good understanding of the processes and rules related to a particular domain before trying to develop a solution.
Advantages of Microservices Architecture
- Highly scalable.
- Easy migrations as there are no dependencies.
- Highly available.
- The codebase is easier to understand.
- Preserve Modularity.
Disadvantages of Microservices Architecture
- Dependency Management is hard.
- Harder to monitor the overall application.
- Harder to test.
- Harder to do versioning and deployments.
- Complex to understand the overall application architecture.
Part 2 of this article describes the essential best practices to be followed in the microservices architecture. I have used the following playlist by Mr.Krishntha Dinesh to gather the required information.
