Microservice Architecture

By this article I will explain the key architectural concepts of the Microservices Architecture and how use those architectural principles in practice. First, it is better to get understand about monolithic architecture then we will see the contrast between monolithic and microservice architecture.

Monolithic Architecture

Here are some of the characteristics of applications based on monolithic architecture.

• Monolithic applications are designed, developed, and deployed as a single unit.
• Monolithic applications are bit complex and this leads to cumbersome in maintaining, upgrading, and adding new features.
• It is difficult to practice agile development and delivery methodologies with Monolithic architecture.
• It is required to redeploy the entire application in order to update a part of it.
• The application has to be scaled as a single unit, making it difficult to manage conflicting resource requirements.
• One unstable service can bring the whole application down.

It’s really difficult to adopt new technologies and frameworks, as of all the functionalities have to build on homogeneous frameworks.

Microservices Architecture

Microservices architecture is about developing a single application as a suite of small and independent services that are run in their own process, developed, and deployed independently.

The key idea is that by looking at the functionalities offered from the monolith, we can identify the required business capabilities. Then those business capabilities can be implemented as fully independent, fine-grained, and self-contained microservices. They might be implemented on top of different technology stacks and each service is addressing a very specific and limited business scope.

Guidelines for Designing Microservices

• Single Responsibility Principle: Having a limited and focused business scope for a microservice helps us to meet agility in development and delivery of services.
• During the designing phase of the microservices, we should find their boundaries and align them with business capabilities: Domain-Driven-Design.
• Make sure the microservices design ensures the independent development and deployment of the service.
• Our focus should be on the scope of the microservice but not about making the service smaller. The size of the service should be the required size to facilitate a given business capability.
• A given microservice should have very few functionalities and a simple message format.

Messaging in Microservices

It is required to have a simple and lightweight messaging mechanism such as HTTP, JMS. The HTTP/S protocol is the most popular way to implement synchronous communication between microservices. In most cases, RESTful APIs use HTTP as a transport layer. The REST architectural style relies on stateless communication, uniform interfaces, and standard methods.

Synchronous Messaging — REST

Synchronous messaging involves a client that waits for the server to respond to a message. It means that synchronous messaging is a two way communication. i.e. Sender sends a message to receiver and receiver receives this message and gives reply to the sender. Sender will not send another message until it gets a reply from receiver.

In Microservice architecture, REST is the unanimous choice as it provides a simple messaging style implemented with HTTP request-response, based on resource API style. Therefore, most microservices implementations are using HTTP along with resource API based styles.

Message Formats — JSON, XML

Deciding the best message format for Microservices is another key factor. In most microservices-based applications, they use simple text-based message formats, such as JSON and XML on top of HTTP resource.

Decentralized Data Management

In Microservices architecture, the functionalities are dispersed across multiple microservices and, if we use the same centralized database, then the microservices will no longer be independent from each other. Therefore, each microservice has to have its own database.

Here are the key aspects of implementing decentralized data management in microservices architecture.

• Each microservice can have a private database to persist the data that requires to implement the business functionality offered from it.
• A given microservice can only access the dedicated private database but not the databases of other microservices.

Service Registry and Service Discovery

In Microservices architecture, the number of microservices that you need to deal with is quite high. And also, their locations change dynamically owing to the rapid and agile development and deployment nature of microservices. Therefore, there is a need to find the location of a microservice during the runtime. The solution to this problem is to use a Service Registry.

Service Registry

Service Registry holds the microservices instances and their locations. Microservice instances are registered with the service registry on startup and deregistered on shutdown. The consumers can find the available microservices and their locations through service registry.

Service Discovery

To find the available microservices and their location, we need to have a service discovery mechanism. There are two types of service discovery mechanisms, Client-side Discovery and Server-side Discovery. Let’s have a closer look at those service discovery mechanisms.

Client-side Discovery — In this approach, the client or the API-GW obtains the location of a service instance by querying a Service Registry.

Server-side Discovery — With this approach, client or API-Gateway sends the request to a Load balancer that runs on a well-known location. That component calls the service registry and determines the absolute location of the microservice.

Deployment

When it comes to microservices architecture, the deployment of microservices plays a critical role and has the following key requirements:

• Ability to deploy or un-deploy independently of other microservices.
• When a given service may get more traffic than other services it must be able to scale at each level.
• Building and deploying microservices quickly.
• Failure in one microservice must not affect any of the other services.

Design for Failures

Circuit Breaker

When you are doing an external call to a microservice, you configure a fault monitor component with each invocation and when the failures reach a certain threshold then that component stops any further invocations of the service. After a certain number of requests in open state change the circuit back to close state.

Here we came to end of this article. So, Hope you get an idea of Microservice Architecture and how it works.

Thank you…