MICROSERVICES DESIGN PATTERNS AND DESIGN PRINCIPLES

Introduction to Microservices:

Microservices are a cloud native architectural approach in which a single application is composed of many loosely coupled and independently deployable smaller components or services .

Microservices is a collection of services that are:

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team

BENEFITS OF MICROSERVICES:

MICROSERVICES :-DESIGN PRINCIPLES

These Design principles act as a guiding theory and inform us about the basic tenets of any architecture.

1. Single Responsibility Principle:

Every business capability within a microservices architecture is distributed into a single service/module, and that module is responsible for performing a particular task assigned to it. This means that a single service is independent of the entire system and is not responsible for other functions within the application architecture.

2. Built around Business Capabilities:

Each microservice should be designed to?solve a business problem. The developer can use the appropriate technology stack for each business problem in each microservice. Unlike a monolithic application, you are not constrained to use a single best-fit homogenous technology stack for the whole architecture. This microservices design principle means developers should choose what's best and readily available for use in every component of the application.

3. Fault Tolerance:

If a component fails, fault tolerance is the capability that enables a system to continue operating properly. Each service is necessarily fault-tolerant so that failures on the side of its collaborating services will have minimal impact on its own SLA. Services, by virtue of being independent of each other, have the opportunity to cut off communication with a failed service.

4. Failure Isolation

5. Decentralized Data:

Microservices each maintain their?own copy of the data. In other words, each microservice has its own database. You should not set up multiple services to access or share the same database, since it defeats the purpose of autonomous microservice operation.Data pertaining to a specific microservice is private to that service.

6. Loose Coupling:

Intercommunication and interaction between the service users and the services determine the functioning of a microservices architecture. Tightly coupled services always run at the risk of affecting the entire application, even if it’s a minor change or security issue like memory leaks and database connectivity issues. The challenges usually multiply when business logic evolves, or new features are to be implemented.

7. Continuous Monitoring:

Microservices in production are distributed and interrelated. It is daunting to manually discover and identify errors. Instead, use an automated monitoring system that can track performance constantly. As part of the microservices design and deployment process,?select a tool or set of tools that captures and analyzes data on services' performance, and generates useful metrics.

8.CI/CD:-

• Continuous integration. Code changes are frequently merged into the main branch. Automated build and test processes ensure that code in the main branch is always production-quality.
• Continuous deployment. Any code changes that pass the CI process are automatically published to a production-like environment. Deployment into the live production environment may require manual approval, but is otherwise automated. The goal is that your code should always be?ready?to deploy into production.

9. Hexagonal Architecture:

Hexagonal architecture?is applied to one microservice. At strategic level, each microservice would be a bounded context. At tactic level, inside each microservice, the hexagon would enclose the application layer and the domain model.

MICROSERVICES: DESIGN PATTERN

1. Decompose Pattern

• Decompose by Business Capability:

A business capability is something that a business does in order to generate value. The set of capabilities for a given business depend on the type of business. Each business capability can be thought of as a service, except it’s business-oriented rather than technical.

• Decompose by Subdomain:

It uses subdomains and bounded context concepts to solve this problem. DDD?breaks the whole domain model created for the enterprise into subdomains. Each subdomain will have a model, and the scope of that model will be called the bounded context. Each microservice will be developed around the bounded context.

• Strangler Pattern:

The Strangler Pattern or the Vine Pattern is based on the analogy to a vine which basically strangles a tree that it is wrapped around. So, when this pattern is applied on the web applications, a call goes back and forth for each URI call and the services are broken down into different domains. These domains will be hosted as separate services. The strangler application consists of two types of services. First, there are services that implement functionality that previously resided in the monolith. Second, there are services that implement new features. The latter are particularly useful since they demonstrate to the business the value of using microservices.

• Bulkhead Pattern:

Bulkhead pattern isolates critical resources, such as connection pool, memory, and CPU, for each workload or service. By using bulkheads, a single workload (or service) can't consume all of the resources, starving others. This pattern increases the resiliency of the system by preventing cascading failures caused by one service.

• Sidecar Pattern:

Sidecar pattern deploys helper components of an application as a separate container or process to provide isolation and encapsulation.

2.Database:

For every application, there is humongous amount of data present. So, when we break down an application from its monolithic architecture to microservices, it is very important to note that each microservice has sufficient amount of data to process a request. So, either the system can have a database per each service or it can have shared database per service.??

3.Observability Patterns

4.Cross Cutting Concerns Pattern

• External Configuration Pattern:

Externalize all application configuration including the database credentials and network location. On startup, a service reads the configuration from an external source, e.g. OS environment variables, etc.

• Service Discovery Pattern:

The Service Discovery mechanism helps us know where each instance is located. In this way, a Service Discovery component acts as a registry in which the addresses of all instances are tracked.?The instances have dynamically assigned network paths. Consequently, if a client wants to make a request to a service, it must use a Service Discovery mechanism.

• Circuit Breaker Pattern:

The Circuit Breaker pattern, can prevent an application from repeatedly trying to execute an operation that's likely to fail. Allowing it to continue without waiting for the fault to be fixed or wasting CPU cycles while it determines that the fault is long lasting. The Circuit Breaker pattern also enables an application to detect whether the fault has been resolved. If the problem appears to have been fixed, the application can try to invoke the operation.

• Blue , Green Deployment Pattern:

A blue/green deployment is a deployment strategy in which you create two separate, but identical environments. One environment (blue) is running the current application version and one environment (green) is running the new application version. Using a blue/green deployment strategy increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails. Once testing has been completed on the green environment, live application traffic is directed to the green environment and the blue environment is deprecated.

• Canary Deployment Pattern:

A?canary deployment is a microservices pattern that should be part of every continuous delivery strategy. This pattern helps organizations deploy new releases to production gradually, to a subset of users at first, before making the changes available to all users. In the unfortunate event that things go sideways in the push to prod, canary deployments help minimize the resulting downtime, contain the negative effects to a small number of users, and make it easier to initiate a rollback if necessary.?

• Deployment Strategies Pattern