Deployment Patterns

Multiple Service Instances per Host Pattern

• Deploy multiple instances of different microservices on a single host, whether it’s a virtual machine or a physical server
• By sharing the same host, this pattern maximizes resource utilization, reducing the cost and overhead associated with running multiple separate hosts
• However, it requires careful resource management to ensure that the services do not compete for the same resources, potentially leading to performance bottlenecks.

Service Instance per Host Pattern

• Each instance of a microservice runs on its own host where each host could be a virtual machine or a physical server.
• This pattern provides strong isolation between microservices, enhancing security and fault tolerance, as issues in one microservice do not affect others.
• The trade-off is higher resource usage since each service has its own host, potentially leading to underutilization of resources.

Service Instance per Container Pattern

• Each microservice instance is deployed in its own container.
• Containers provide a lightweight and efficient way to encapsulate a microservice along with its dependencies, ensuring consistency across different environments.
• This pattern leverages container orchestration platforms like Kubernetes to manage the deployment, scaling and operation of containers, making it easier to maintain and scale microservices.

Serverless Deployment Pattern

• In a serverless deployment, microservices are deployed as serverless functions, such as AWS Lambda or Azure Functions.
• The cloud provider manages the infrastructure, automatically handling the execution, scaling and resource allocation.
• This pattern is particularly useful for event-driven applications, where functions are triggered by events.
• It simplifies deployment and reduces operational overhead, but may come with limitations on execution time and resource usage.

Blue-Green Deployment Pattern

• This pattern involves maintaining two environments: Blue (current production) and Green (new version).
• The new version of the microservice is deployed to the Green environment, while the Blue environment continues to serve live traffic.
• Once the new version is tested and verified in the Green environment, traffic is switched from Blue to Green.
• This pattern minimizes downtime and allows for quick rollback if issues are encountered in the new version.