Common deployment patterns for microservices

Common deployment patterns for microservices.md

Deployment pattern	Description
Single service per host	Involves deploying one microservice per host (physical or virtual machine), which gives each microservice full access to the resources of the host. This pattern is simple and easy to implement, but it can be wasteful and inefficient in terms of resource utilization and scalability
Multiple services per host	Involves deploying multiple microservices per host, which allows you to share the resources of the host among different microservices. This pattern can improve resource utilization and scalability, but it can also introduce complexity and challenges in terms of isolation, security, and configuration management
Service instance per container	Involves deploying each instance of a microservice in a separate container, which is a lightweight and portable unit of software that encapsulates the code, dependencies, and configuration of a microservice. This pattern can provide high levels of isolation, portability, and flexibility for your microservices, but it can also require more infrastructure and tooling to manage the containers and their lifecycle
Service per container	Involves deploying one microservice per container, which is similar to the service instance per container pattern, but with a one-to-one mapping between microservices and containers. This pattern can simplify the management of containers and their lifecycle, but it can also limit the scalability and availability of your microservices
Sidecar	Involves deploying an additional container alongside each microservice container, which provides some cross-cutting functionality or enhancement for the microservice. For example, a sidecar container can provide logging, monitoring, caching, or security features for the microservice. This pattern can decouple your microservices from these concerns and enable them to focus on their core business logic
Ambassador	Involves deploying an additional container in front of each microservice container, which acts as a proxy or intermediary for the microservice. For example, an ambassador container can provide routing, load balancing, authentication, or encryption features for the microservice. This pattern can abstract away the complexity and heterogeneity of your infrastructure and enable your microservices to communicate with each other or with external systems more easily
Adapter	Involves deploying an additional container behind each microservice container, which acts as a translator or adapter for the microservice. For example, an adapter container can provide data transformation, formatting, or validation features for the microservice. This pattern can enable your microservices to interact with different types of data sources or sinks more seamlessly