Microservices Deployment Patterns

This block of templates describes possible deployment options for the developed microservices.

Service Instance Per Host Template

Deploying each service instance on its host (virtual or physical) is recommended when moving to a microservice architecture. The Service Instance Per Host pattern allows you to isolate service instances from each other, avoid version conflicts and resource requirements, make the most of host resources, and make redeployments easier and faster. The disadvantages of the pattern include potentially less efficient use of resources compared to deploying multiple instances per host.

Sometimes there are varieties of the described pattern that are most often used in practice: “Service Instance Per VM” and “Service Instance Per Container.” When using them, each service instance is packaged and deployed as a separate virtual machine or container, respectively.

Blue-Green Deployment Template

The pattern allows you to deploy new versions of services as seamlessly as possible to users, reducing downtime to a minimum. This is achieved by running two identical production environments – nominally blue and green. Suppose blue is an existing active instance and green is a new application version deployed alongside it.

At any given time, only one of the environments is active, and it serves all production traffic. After successfully deploying a new version – with all tests passing and so on – traffic switches to it. In case of errors, you can always revert to the previous version.

Resiliency Patterns

This group of patterns is designed to improve the reliability of microservices architecture applications.

Circuit Breaker Pattern

When microservices interact, situations are not excluded when, for some reason, one of the services stops responding. Repeated calls help to cope with temporary disruptions (slow network connection, temporary unavailability, etc.). However, repeated calls will only waste resources for more severe failures caused by a complete outage of service.

In such cases, it is recommended to use the Circuit Breaker pattern. The microservice will request another microservice through the proxy server. It counts the number of recent failures and, based on this, determines whether to allow subsequent calls or return an exception immediately.

A proxy server can be in three states:

• Closed. There is a transfer of requests between services and counting the number of failures. If the number of failures in the specified time interval exceeds the threshold, the proxy server switch is placed in the Open state.
• Open. Requests from the original service are immediately returned with an error. After the specified timeout expires, the switch is switched to the Half-Open state.
• Half-Open. The switch skips a limited number of requests from the original service and counts the number of successful requests. If the required amount is reached, the switch goes into the Closed state; if not, it returns to the Open state.

Using a template improves resiliency and prevents cascading failures but requires careful configuration and monitoring.

Bulkhead Template

The pattern got its name from the bulkheads used in shipbuilding: they protect the ship from total flooding in the event of damage to its parts. Similarly, in the architecture of the application: bulkheads isolate the elements of the application into pools so that if one of them fails, the rest will continue to function.

The pattern allows you to separate resources to ensure that the resources used to call one service do not affect the resources used to call another service. An example is using a separate connection pool for each of the downstream services.

Another use case for the template is to assign a separate service instance to each service client. In this case, if one of the clients makes too many requests by overloading its instance, the other clients can continue working.

Using this pattern prevents cascading failures and isolates critical resources but introduces additional complexity and less efficient use of resources.

Also Read: Data Management Patterns In Microservice Architecture