Microservices
Tags: microservices, architecture, microserviceecosystem, microservicearchitecture
Published: 2023-11-02 19:17:32

In this article we will be discussing about the Microservices compared to the monolith architecture and the characteristics of Microservices and Microservice ecosystem.

Microservices is about the development of a larger application as a suite of modular services. each module supports a specific business goal, or we call it a business functionality. to communicate between and among the independent and separated functionalities well-defined and simple interfaces are used. the following diagram will elaborate the overall view of a microservices architecture.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gm4jfha3mknnzn4w05qt.png)

Microservices are built depending on the business capabilities. this design model is called “Domain Driven Design”. as we are separately developing each microservice, we can use a suitable programming language and a data storage technique irrespective of other microservices. Each microservice is tested and deployed separately, hence faster release cycle is resulted.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/256zox92boc30x20l99t.png)

Microservices are;

> 1. Highly maintainable and testable
> 2. Loosely coupled
> 3. Independently deployable
> 4. Organized around business capabilities
> 5. Owned by a small team


## Monolith Architecture


monolith architecture is a singular, large computing network with one code base that couples all of the business concerns together.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/43sa0up5uts9kg16phdp.png)

change in one business capability will result in the re-deployment of whole bundle which consume a lot of time and money in testing. As the scalable unit is large only a single component scaling is not possible and the whole bunch of components should be scaled. Programming language used and data storage technique cannot be changed according to the user requirement due to high coupling with the underlayer frameworks.

## Microservices Architecture

Business capabilities should be exactly same in both architectures. Thus, we are defining separate microservice for each, covering all the business capabilities. Business capabilities are system user requirements and that’s why they should not be changed in any of the architectures.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/97zcv4rocc98o02otw7d.png)

When scaling,

In monolith architecture, we have to replicate the whole bundle in the server while in the microservice architecture we can choose the scalable unit as per the requirement. Replication of a component can be done as needed.

## Characteristics of Microservices

_**Componentization via services**_

Independently replaceable and upgradable units of the software are called components. We choose microservice component based on the service. Each component provides a separate independent service. Thus, it is called componentization via service. In here the major difference seen in the process of deployment. The deployment is done as a service rather than a .jar/.war file or a dill. In the world of microservices the component is not a library anymore, it is a service.

**_Organized around business capabilities_**

All the microservices are organized business capabilities or business functions. Each microservice will provide an independent business function of the system.

**_Samrt endpoints and dumb pipes_**

Pipes are only be delivering the message. The main responsibility of the pipe is reliable transmission of the message. No business logics are applied on the pipes. Business logics are only applicable at the end points, which means the microservice is the one that apply the business logic.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jytly5khfi2xnb791clq.png)

**_Decentralized governance_**

Choosing the right tool, best technology, suitable programming language and data storage mechanism for each solution is possible with microservice. But in each case best practices and principles should be followed.

**_Decentralized Data Management_**

Each microservice maintains an independent and separate data store for them. Each data store is coupled loosely with one another. And also they only connect with other data stores using APIs. Which means data stores do not connect directly with other data stores.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5lck34vmvp477e57972f.png)

**_Infrastructure Automation_**

As we are having several micro-services we have a proper automation pipeline from compilation, deployment and scaling. Maintaing a number of microservices is different than in the monolith architecture. If we are looking forward to moving to the microservices architecture infrastructure automation is a must.

_Advantages of infrastructure automation,_

- Ease of scaling up and down
- Faster Deployment cycles
- Resilient and highly available

**_Design for Failure_**

Application needed to be designed in a way that they can tolerate the failure of services.

## Microservices Ecosystem

There are several components that consist of the microservices ecosystem. Those components are identified as follows,

1. Load Balancer
2. Service Discovery Server/ Service Registry
3. API Gateway
4. Central Configuration Server
5. Monitoring
6. Containerization
7. Centralized log analysis

Let’s dive into a brief introduction to each component.

**_Load Balancer_**

Load balancer is responsible for distributing the incoming load/ traffic among many instances of microservices. Load balancers can be seen either as client-side load balancer or server-side load balancers.

**Client-side load balancing**

In a client-side load balancer service registry has access to all related details about microservices. When a microservice wants to communicate with another microservice, the load balancer on the client side talks to the service registry and does the balancing of traffic on its own at the client side.

This scenario can be explained using the following diagram.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zx8hi92hppn730qdk3sd.PNG)

According to the diagram Microservice B has three identical instances. When Microservice A wants to communicate with Micro-service B the load balancer at Microservice A (Client Side) talks to service registry to get details about microservice B and itself decides to which instance the traffic would be routed.

**Server-side load balancing**

In this scenario also, three instances of microservice B and microservice A is present. Unlike in client-side load balancing here microservice A does not own its own client-side load balancer. Therefore, when microservice A wants to communicate with microservice B it has to send a request to the load balancer component. Then the load balancer component calls to the service registry and route the relevant details about microservice B. then only the load balancer decides to which instance the traffic be routed.

The following diagram shows the server-side load balancing.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6n6lylkxyih7vas386oe.PNG)

**_Service Discovery Server/Service Registry
_**
Instead of manually keeping a track of the deployed microservices, their hosts and ports, Service discovery functionality or the service registry allows microservices to self-register themselves at startup through APIs.

Though in monolith architecture it is possible to maintain a document about microservices, their ports and all that, In microservices architecture having a dynamically changing architecture maintaining documentation is not possible.

With the service discovery functionality, microservices can update themselves about alterations of their nodes, and IS to the service registry.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ns8mzjjozdgpm1m76che.PNG)

**_API Gateway_**

In monolithic architecture a single endpoint is there to access all the other services. But in the microservices architecture several endpoints are present. To access those multiple end points while maintaining the uniformity in the architecture API gateways have been deployed. Those API gateways are required to handle and route the requests to the relevant endpoints. To maintain the high availability in the system several API gateways can be deployed.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/if7ci5rpeq4ece6vswrh.PNG)

**_Central Configuration Server_**

The central configuration server can be used to apply the configurations to all the microservices at once instead of changing them one by one. At the startup of the microservice the central configuration server requests the configurations of the particular service and keeps a track record of that. If there are any alterations to the configurations, the central configuration server can be modified, so that the other microservices can easily access the updated configurations of a particular microservice.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/einbqesswexq96lcc0yj.PNG)

**_Monitoring_**

In monitoring a single server monitors how each microservice is performing. Unlike in the monolith architecture monitoring is quite complex in microservices architecture, thus a single monitoring server is required.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zf62xx10awchvtfms8js.PNG)

**_Containerization_**

Application along with all the dependencies are packaged as a single container. So the container can run itself wherever it is. container runtime or the container orchestrater is enough. Container orchestration is automatically provision, deployment, scaling and management of containerized applications.

**_Centralized log analysis
_**
Centralized log analysis is used for troubleshooting purposes. A central component collects all the log details about each microservice for easy reference.

**_Circuit Breaker_**

Circuit breaker involves in maintain the high availability of the whole application.


_In this article we discussed about the microservices architecture, microservices architecture compared to monolith architecture characteristics of microservices and microservices ecosystem. Microservices architecture is not the absolute best solution for any software project. The architectural design should be chosen depending on the user requirements, performance, security, scalability deployment strategy and all that.

Stay tuned for the next...
Thank You_