Instead of building a single indivisible application, split the large application into loosely coupled service modules in which each follows different business logic and exposes various APIs. Each of these independent service modules is a Microservice.
Why Microservices
Let’s use the example that we have an android application and see how it works in monolithic and microservices architecture. This application has various functions like ordering a product, stock information, shipping etc.
Before learning about microservices, we should understand the monolithic application. Conventionally we follow a monolithic architecture. When a client raises a query about a product, a single REST call requests the application and the application passes the request to the database. The load balancer distributes the requests to N number of application instances which in turn calls various databases if required and the response is returned to the client.
The entire application is treated as a single unit and all the business logic will be running as a single process.
But in Microservices architecture, the product query is passed to each logically grouped microservice such as order service, stock info service and shipping service etc. The client would call each of the microservices directly. Each microservice would request the database independently and return the response to the client. Fine grained APIs provided by microservices have direct interaction with multiple services.
Every architecture has its own drawbacks. During continuous deployment in monolithic applications, deploying a change in one component leads to the redeployment of the entire application. That is, deploying the same set of code again and again causes various code integration problems. It will be harder to track all the code when there is a code failure happens.
In Microservice architecture, the change only belongs to the service deployed and code failures will not affect the other service modules in the application.
Microservices Approach
From the above diagram, order Info, Stock Info and Shipping info are logically separated and each referred to as a microservice component. Logically grouping the business units within an application is not a new terminology wherein many of us confuse the microservices with SOA. SOA scope relies on an interface level that exposes the functionalities as service interfaces. In contrast, Microservice works on the application level so that each microservice component can expose numerous APIs.
Why API Gateway in Microservices Application
After seeing the microservices approach diagram, everyone gets asked why we should use API gateway in Microservices application. While the client communicated directly to the microservices, code refactoring of microservices would become a challenge to the application. In this scenario, API gateway takes the responsibility of being a single point of entry to all the clients.
Client requests will be passed through the API gateway and this API gateway takes care of routing the request to multiple microservices. The API gateway encapsulates the internal structure of the application and exposes the services as API to the clients. Microservice is only responsible for receiving the request and generating responses, wherein the API gateway centralizes the authentication, logging, transformations, load balancing and secure the APIs to the entire application.
Every microservice generates the response in different formats like Xml response, Json response etc. API gateway collates all the responses into one and responds to the client.
Since the API gateway is abstract to the clients, the implementation can be updated to the application while having the same interface as public to the clients. Also, an application that can take up new technologies for future changes while keeping the rest of the application the same.
The implementation of microservices with the help of API gateway is to achieve the agile development and delivery of the application.
One of the best way to achieve a continuous delivery to a microservice is by adopting the wrappers and containers. The wrapper is to wrap the code base that establishes a direct communication with the client without changing the interface from the user and the response converted into the desired format. One example is where the REST wrapper collects the multiple endpoints into single entry endpoint. Containers package the dependencies into a single service to ensure the cross compatibility.
Good article Rekha. Keep writing more blogs like this!