Microservices!! This has become one of the most popular words nowadays. Many popular companies in the world such as Amazon, Netflix, Twitter, Paypal has stepped into the microservices in order to achieve a smooth development & deployment process and also to provide a better experience for their customers. The way of thinking about the network architecture, managing and allocating resources has been redefined. Let’s get to know what is microservices.
Why Microservices?
When considering moving with microservices let’s discuss what we had before. This architecture identified as Monolithic architecture which has been used for a long time and still going well with most of the applications.
Monolithic Architecture
This architecture is kind of a container which contains all the software components of an application tightly packaged manner. All the software components are tightly coupled and distributed as one large package.
Challenges with Monolithic Architecture
Large & Complex applications
It is easy to manage when an application code base is small. But with the growth of the application, It will become hard to understand and modify. This also affects the code quality over time and difficult to implement a change.
Slows development process
This kind of large code base is hard to understand and modify. When there is a new feature or issue to be fixed, It will take more than the considerable amount of time since the understanding and usages are expanded in a large scope.
Blocks continuous integration
It is required to redeploy the whole application when there is a change. That means all the time we have to spend more resources and time on deploying component that never affected by the change implemented.
Unscalable
A monolithic application is also supported for scaling. But the application is packaged as one single block. Because of that when scaling we have to up an instance with a copy of the application which has all the component rather than the selected component or components. That means with the monolithic architecture we cannot increase each component independently. This can be redirected to the unnecessary use of resources.
Unreliable
If there is an error encountered in one component, the entire application will fail to run since all the software components are packaged and served and running in one process. That means any module can impact the availability of the entire application.
Inflexible
It will be extremely expensive to adapt to new technologies. When there is a new framework which is better than the existing framework, entire application needs to rewrite to get the benefits of new framework even though the new framework has better features in some special context such as cart service or authentication service.
What is Microservice architecture
Microservice architecture is an architectural style that structures an application as a collection of autonomous services that are
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities.
The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.
These multiple services don’t share the data structure but will be communicated through APIs. The advantage of drilling down applications business into microservices is one service only responsible for one single task. This will help to achieve a better quality of each business domain based activity.
The view of the deployment with the microservice architecture is as follows.
Each microservice is,
- capable of communicating through each other with a well-defined interface such as REST
- responsible for its own data model and data since each microservice is handled by different instances
The communication between each microservice is stateless; that means each pair of request and response is an independent transaction.
Let’s move into Microservice architecture with the complete flow of request handling.
Each of these small, loosely coupled services has a considerable amount of code base which can be managed by a small team of developers and can be deployed independently. Each team can deploy their own service with latest changes without rebuilding and redeploying the application.
Each service responsible for persisting their own data and implementation details are hidden from other services. In addition to that, It is not required to use the same technology stack in all services. Different services can have different technology stack and libraries.
Management – Responsible for handling services by considering activities such as failures, load balancing
Service Discovery – Maintain a list of services, which contains the list of nodes and components located in the node
API Gateway – This will be the entry point for the client, this will forward the appropriate service or aggregate set of services to achieve a complex task
Features of Microservices
- Small focused
- Loosely coupled
- Language neutral
- Bounded Context
Advantages of Microservices
- Simpler To Deploy
– Deploy in literal pieces without affecting other services. - Mixed Technology Stack
– Different technologies and libraries can be used in different services independently. - Granular Scaling
– Each service can be scaled independently. - Simpler To Understand
– Follow code easier since the function is isolated and less dependent. - Reusability Across Business
– Share small services like payment or login systems across the business. - Faster Defect Isolation
– When a test fails or service goes down, isolate it quickly with microservices. - Minimized Risk Of Change
– Avoid locking in technologies or languages – change on the fly without risk.
Drawbacks of Microservices
- The decomposition of the application’s entire business capabilities into multiple granular units, where drawing the line around sub-business units can be hard and tricky
- Poorly defined boundaries can have a negative impact on scaling applications
- Hard to reuse code across different services, especially when built on different languages
- Tedious to keep track of the hosts running various services, and can lead to a lot of confusion and expenditure of resources trying to orchestrate these various components together
- Require technical skills to effectively pull off, and is a big transition for developers accustomed to traditional forms of application engineering
Bonus Topic – Design First (API First) Approach to Microservices
APIs have become the most common way for various services to communicate with each other. In order to better expose services via APIs, a common interface for these APIs needs to be present to tell exactly what each service is supposed to do. This interface is a contract that defines the SLA between the client and the services.
This approach simply states that designing and defining the interface of the microservice first, reviewing and stabilizing this contract, and only then implementing the service. The Design First approach ensures that your services are compliant with the requirements of the client upfront before any actual development has taken place.
References:
