Other Microservices Design Patterns

Here we will consider the most critical templates from other groups.

Ambassador Template

Applications and services often require standard functionality related to monitoring, logging, security settings, network services, etc. However, in a microservice architecture, individual services can be built using different languages ​​and technologies – therefore, they can have their dependencies and require specific language libraries. The Ambassador pattern suggests placing client frameworks and libraries to solve peripheral problems inside an auxiliary service that acts as a proxy between the client application or leading service and other system parts.

Using the Ambassador pattern allows you to:

• Unify the way client applications address everyday tasks regardless of the language and framework used.
• Solve peripheral tasks without affecting the main functionality, including by transferring development to separate specialized teams. This is useful, for example, when you need to centrally manage network calls and security functions – to avoid duplicating complex code on each component separately.
• Add new functionality to Legacy applications that are difficult to refactor.

Since adding a Proxy increases network latency, albeit slightly, the Ambassador template is not recommended when the latency is critical. Also, it is better not to use the pattern in cases where you can get by with a standard client library – for example, if only one language is used or there is no way to highlight everyday peripheral tasks.

The Proxy can be deployed as a daemon or service. If the leading service is containerized, Proxy is also deployed as a separate container on the same host; for this purpose, a different pattern is used – Sidecar.

Pattern “Stroller” (“Trailer”, Sidecar)

The Sidecar pattern suggests putting peripheral tasks related to monitoring, security, fault tolerance, and so on into a separate component and deploying it inside its processor container. This provides a uniform interface for the host application’s services, written in different languages.

Sidecar is not necessarily part of the application but is related to it: a Sidecar instance is deployed side by side for each application instance. Sidecar has the same lifecycle as the main application.

The advantages of the pattern are the independence of the auxiliary component from the leading application platform, the ability to access the same resources, the minimization of delays due to their proximity, and the ability to update independently. The disadvantages include the overhead of creating an additional component. The template is not recommended for small applications and cases where libraries and standard extension mechanisms can be dispensed with.

Consumer-Driven Contract Testing Template

This is one of the testing styles recommended for large-scale projects where multiple teams work on different services. The essence of the pattern is that the developers write a set of automated tests for each service (Provider Microservice) of other services (Consumer Microservice) that call the service being checked. Each such set of tests is a contract that tests whether the provider’s service meets the customer’s expectations. The tests themselves include the request and the expected response.

The Consumer-Driven Contract Testing pattern increases team autonomy and allows timely detection of changes in services written by other teams. However, its implementation may require additional work to integrate tests since teams can use different testing tools.

External Configuration Template

Almost all applications use a variety of configuration parameters during operation: service addresses, database connection strings, credentials, paths to certificates, and so on. In this case, the parameters will differ depending on the runtime: Dev, Stage, Prod, and so on. Storing configurations locally – in files deployed with the application – is considered an awful practice, especially when moving to microservices. This poses serious security risks and requires redeployment every time the configuration settings are changed.

Therefore, it is recommended to use the External Configuration template in enterprise-level applications, which suggests storing all configurations in external storage. This storage can be a cloud storage service, a database, or another system.

The template decouples the build process from the runtime and minimizes security risks as production configurations are no longer part of the codebase.

Also Read: Microservices Monitoring Patterns