March 10, 2017
Microservices is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism. Most popular way of communication between services is using HTTP/Rest with JSON because of its comparatively lower complexity over other protocols. Classic monolithic architecture has the server side that is burdened with everything including HTTP requests, business logic and crud operations on data from the underlying database. Any single change to any part of the application would mean deploying a completely new version of the application. This, in turn, leads to lesser release planning. Scaling up of a component would need the entire application to be scaled up.
1. Speeded delivery – Since the back end is broken into multiple services only that service which involves the change needs to be tested before deployment which would mean a fast track continuous delivery.
2. Easier management of project – Since the modules are the loosely coupled management of project which can also be modularized.
3. Scalability – Cost of scalability is very low
4. Diversified technology – Since the components are modularized it’s very easy to use multiple technologies for multiple features in an application.
5. Failure recovery – Since several unique and diverse services are communicating together, it’s quite possible that a service could fail, for one reason or another. In these instances, the client should allow its neighboring services to function while it bows out in as graceful a manner as possible.
6. Evolutionary model – ideal for evolutionary systems where you can’t fully anticipate the types of devices that may one day be accessing your application. This is because the style’s practitioners see decomposition as a powerful tool that gives them control over application development.
When to use microservices?
We can choose microservices in 2 approaches
1) Monolithic architecture-first approach:
-Extend the well-designed modular components from the monolith: Usually, we find business people supporting monolith first design, thinking it will be easy if required, to convert a modularly designed, monolith application to microservices at a later stage. In fact, they opt for a modular monolith application, to reduce the cost they may incur to develop microservices for which the need should arise.
-Recreate the microservices application from scratch and dump the existing monolith application: Most of the time microservices applications are developed from scratch because of bad modularity in monolith applications.
2)Developing applications with microservices architecture – This should be done when
-Modularity is an important aspect.
-High volume transaction is expected.
-Availability of the right skill set to design, develop and deploy applications in the initial phase
-Commitment to using cutting-edge tools and technologies.
Microservices architecture diagram
-Scope: We must ensure that each microservice should not deal with anything outside of its specific scope. API gateways or proxy could be a solution to this.
-Data Sharing is tedious. If each microservice opts for a dedicated database, communication among multiple databases can become a challenge. We might have to develop an internal process to handle communication among databases.
-Failure detection: By design, we will have multiple services catering to one application if any one of them goes down it might be difficult to track the failure as it may go unnoticed among many other services.
-Versioning: Microservices tend to evolve fast.Hence, it is necessary to account for versioning of services.
-Interdependencies: Since the number of services interacting with each other handling dependencies becomes very tedious. It’s very essential to keep dependencies to a minimum
-Transport and data format: Microservices are usually exposed publicly through a RESTful API over HTTP. Any data format would work with microservices. HTTP + JSON is very widely used.
API gateways in detail
In a microservice based architecture, it’s very essential to ensure that the service does nothing other than what is its scope. However, there might be some common features essential for all the micro services. Ex – Logging, authentication etc. API gateways are a solution to these problems. API gateways are an essential part of the microservice based architecture. They help in speeding up development as the scope of microservices remains clearly defined. The most commonly used gateways are as follows:
-Authentication: Each request to microservice is routed through an authentication gateway for basic authentication thereby allowing microservice to execute the only user and service specific logic during authentication.
-Transport security: gateways handle the responsibility of nullifying security constraints inside the internal network. They also impose necessary security constraints for public network access. Classis example could be SSL implementation for requests over HTTP
-Load-balancing: Each service has its own scaling limitations. Gateways handle the responsibility of dispatching requests to the service from multiple endpoints.
-Request dispatching (including fault tolerance and service discovery): Gateways may work in tandem with service registration/discovery processes or databases that describe how to dispatch each request. Faulty services can be routed to backup or generic services that allow the request to complete rather than fail completely
-Dependency resolution: Gateways provide virtual endpoints that are internally routed to different microservices.
-Transport transformations: Since microservice based architecture consists of multiple services, each service might define its own transport mechanism and that might not be suitable for all the clients. Hence a gateway is implemented that handles the responsibility of handing over data to the client over desired transport.
Sample Amazon Microservices architecture