Microservice: Basic Principles

Microservices are a software development approach in which a complex application is divided into loosely coupled services. Microservices can be developed, deployed, and scaled independently. Microservices architecture consists of a collection of small, independent services. Each service should be implemented as a single service for a specific business solution. The diagram below illustrates a microservice architecture.

Some of the important design principles of microservices are described below.

Single Responsibility

Each microservice should have a single responsibility within the application. This ensures the microservice is simple, focused on one function, and easy to maintain. For example, a microservice dedicated to authentication will do the authentication function only. The single responsibility principle explicitly means that there should be only one reason to change the microservice in the future.

Decentralization

Microservices should be independent of each other, with minimal or no interdependence. In other words, microservices should be encapsulated. This allows the creation of flexible and agile systems.

In microservices-based applications, each service has its own data. Which means each microservice will have its own database. Multiple services sharing the same database spoil the intention of microservice architecture. It should be possible to do the separate CICD (continuous integration/continuous delivery) for a discrete microservice.

Suppose we have a client application to manage the CRM (Customer Relationship Management) and payment. In that case, there will be separate microservices and databases for the CRM and payment-related services.

Autonomous

Each microservice should be autonomous. It should be able to function independently without requiring coordination with other microservices. This allows the faster development and deployment of new features. An autonomous microservice should have the following characteristics.

Function Independently

The microservice should be able to function independently without relying on other microservices.

Resources and Data available

The microservice should have all the resources and data it needs to function effectively.

Stateless

The microservice should be stateless, meaning it should not rely on any state maintained by other microservices.

API

The microservice should be exposed through a well-defined API that other microservices can interact with.

Handle failures

The microservice should be designed to handle failures and recover quickly without affecting the other microservices in the application.

Composable

The microservice should be designed to be composable, meaning it can be easily combined with other microservices to create more complex functionality.

Service-oriented

Microservices are organized around services, which are typically exposed as RESTful APIs. This allows easy integration with other systems and promotes a loosely coupled architecture. The service-oriented nature of microservices enables the application to be broken down into smaller components, each of which can be developed, deployed, and scaled independently. This promotes flexibility and agility in the development process, as changes and updates can be made to the individual microservices without influencing the overall system.

Additionally, the service-oriented nature of microservices allows for better fault isolation and easier troubleshooting. Because each microservice is self-contained and has a single responsibility, failures and issues can be isolated to specific microservices and addressed independently.

Resilience

Microservices should be designed to be resilient, meaning they should be able to handle failures and recover quickly. This is achieved through redundancy, fault tolerance, graceful degradation, and monitoring and logging techniques.

Redundancy

Microservices are often deployed in a redundant configuration, meaning there are multiple instances of the service running in different locations. This helps ensure that if one instance fails, another can take over.

Fault tolerance

Microservices are designed to be fault-tolerant, meaning they can continue to function even if some parts of the system fail. For example, a microservice might use a circuit breaker pattern to detect when a service it depends on is not responding and to return a cached response instead.

Graceful degradation

In situations where a microservice cannot function as intended, it may degrade gracefully by providing a reduced set of features or functionality. This helps ensure that the system can continue to function even if some parts are unavailable.

Monitoring and logging

Microservices architecture includes built-in monitoring and logging mechanisms to collect data about system behavior and usage patterns. This data can be used to determine potential issues and make decisions about system changes and improvements.

Flexibility

Microservices should be flexible, meaning they should be able to adapt to changing business requirements and environments. This requires a modular and extensible architecture that can support new features and functionality. Microservice provides flexibility in the following ways.

Independent Deployment

Microservices can be deployed independently. This means that developers can update, modify or replace a single microservice without affecting the rest of the system. This allows for a faster development cycle and enables the system to adapt more quickly to changing requirements.

Modular Architecture

Microservices are designed as modular components, which means that they can be easily modified, extended, or replaced. Developers can add new features or services without rebuilding the entire system. Also, it is easy to maintain and upgrade individual components.

Service Discovery

Microservices use service discovery mechanisms to locate and communicate with each other. This means that new microservices can be added to the system without the need for any manual configuration or changes to the existing codebase. This allows for a more flexible and scalable architecture, where new services can be added based on the requirements.

Scaling

Microservices allow for flexible scaling of the system, as each microservice can be scaled independently of the others. This means that resources can be allocated based on the specific needs of each microservice, providing optimal performance and scalability for the system.

Realtime Load Balancing

When a client sends a request to the server, sometimes, the database has to retrieve the data from multiple microservices simultaneously. At that point, the Load balancer defines how much of the Central Processing Unit is to be used for a particular service to fetch the data and, finally, how the client request should be passed.

Command Query Responsibility Segregation

Command Query Responsibility Segregation (CQRS) can be used in microservice architecture to improve an application's scalability, flexibility, and performance. In CQRS, the system is divided into two distinct parts: the command side and the query side. The command side is responsible for handling all the operations that change the state of the system, while the query side is responsible for retrieving data from the system.

In microservices, CQRS can be used to separate the read and write concerns of the system. Each microservice can be responsible for either handling commands or queries, but not both. This can help scale the system horizontally as each service can be independently scaled based on demand.CQRS can also improve the performance of the system by allowing for the optimization of the read and write operations separately.

Implementing CQRS in a microservice architecture can add complexity to the system. It requires careful design and coordination between the command and query sides to ensure consistency and maintainability. Therefore, it is recommended to only use CQRS when there is a clear need for it, such as in systems with high write and read loads or complex business logic.

Continuous Integration and Deployment

Microservices should be built using a continuous integration and deployment (CI/CD) pipeline, which enables frequent and automated testing, deployment, and monitoring of changes to the system.