1
Q
Deployment patterns
A
Multiple service instances per host Service instance per host Service instance per VM Service instance per Container Serverless deployment Service deployment platform
2
Q
Multiple service instances per host: context
A
You have applied the Microservice architecture pattern and architected your system as a set of services. Each service is deployed as a set of service instances for throughput and availability.
3
Q
Multiple service instances per host: problem
A
How are services packaged and deployed?
4
Q
Multiple service instances per host: forces
A
- Services are written using a variety of languages, frameworks, and framework versions
- Each service consists of multiple service instances for throughput and availability
- Service must be independently deployable and scalable
- Service instances need to be isolated from one another
- You need to be able to quickly build and deploy a service
- You need to be able to constrain the resources (CPU and memory) consumed by a service
- You need to monitor the behavior of each service instance
- You want deployment to reliable
- You must deploy the application as cost-effectively as possible
5
Q
Multiple service instances per host: solution
A
Run multiple instances of different services on a host (Physical or Virtual machine).
- There are various ways of deploying a service instance on a shared host including:
- Deploy each service instance as a JVM process. For example, a Tomcat or Jetty instances per service instance.
- Deploy multiple service instances in the same JVM. For example, as web applications or OSGI bundles.
6
Q
Multiple service instances per host: result benefits
A
More efficient resource utilization than the Service Instance per host pattern
7
Q
Multiple service instances per host: result drawback
A
- Risk of conflicting resource requirements
- Risk of conflicting dependency versions
- Difficult to limit the resources consumed by a service instance
- If multiple services instances are deployed in the same process then its difficult to monitor the resource consumption of each service instance.
- Its also impossible to isolate each instance
8
Q
Multiple service instances per host: related
A
The Single Service Instance per Host pattern is an alternative solution.
The Serverless deployment pattern is an alternative solution.
9
Q
Single service instances per host: context
A
You have applied the Microservice architecture pattern and architected your system as a set of services. Each service is deployed as a set of service instances for throughput and availability.
10
Q
Single service instances per host: problem
A
How are services packaged and deployed?
11
Q
Single service instances per host: forces
A
- Services are written using a variety of languages, frameworks, and framework versions
- Each service consists of multiple service instances for throughput and availability
- Service must be independently deployable and scalable
- Service instances need to be isolated from one another
- You need to be able to quickly build and deploy a service
- You need to be able to constrain the resources (CPU and memory) consumed by a service
- You need to monitor the behavior of each service instance
- You want deployment to reliable
- You must deploy the application as cost-effectively as possible
12
Q
Single service instances per host: solution
A
Deploy each single service instance on its own host
13
Q
Single service instances per host: result benefits
A
- Services instances are isolated from one another
- There is no possibility of conflicting resource requirements or dependency versions
- A service instance can only consume at most the resources of a single host
- Its straightforward to monitor, manage, and redeploy each service instance
14
Q
Single service instances per host: result drawbacks
A
Potentially less efficient resource utilization compared to Multiple Services per Host because there are more hosts
15
Q
Single service instances per host: relateds
A
The Multiple Service Instances per Host pattern is an alternative solution
The Service Instance per VM pattern is a refinement of this pattern
The Service Instance per Container pattern is a refinement of this pattern
The Serverless deployment pattern is an alternative solution.
16
Q
Service Instance per VM: context
A
You have applied the Microservice architecture pattern and architected your system as a set of services. Each service is deployed as a set of service instances for throughput and availability.
17
Q
Service Instance per VM: problem
A
How are services packaged and deployed?
18
Q
Service Instance per VM: forces
A
- Services are written using a variety of languages, frameworks, and framework versions
- Each service consists of multiple service instances for throughput and availability
- Service must be independently deployable and scalable
- Service instances need to be isolated from one another
- You need to be able to quickly build and deploy a service
- You need to be able to constrain the resources (CPU and memory) consumed by a service
- You need to monitor the behavior of each service instance
- You want deployment to reliable
- You must deploy the application as cost-effectively as possible
19
Q
Service Instance per VM: solution
A
Package the service as a virtual machine image and deploy each service instance as a separate VM
20
Q
Service Instance per VM: examples
A
Netflix packages each service as an EC2 AMI and deploys each service instance as a EC2 instance.
21
Q
Service Instance per VM: result benefits
A
- Its straightforward to scale the service by increasing the number of instances. Amazon Autoscaling Groups can even do this automatically based on load.
- The VM encapsulates the details of the technology used to build the service. All services are, for example, started and stopped in exactly the same way.
- Each service instance is isolated
- A VM imposes limits on the CPU and memory consumed by a service instance
- IaaS solutions such as AWS provide a mature and feature rich infrastructure for deploying and managing virtual machines. For example, Elastic Load Balancer -
Autoscaling groups
…
22
Q
Service Instance per VM: result drawbacks
A
Building a VM image is slow and time consuming
23
Q
Service Instance per VM: relateds
A
- This pattern is a refinement of the Single Service per Host pattern
- The Service Instance per Container pattern is an alternative solution
- The Serverless deployment pattern is an alternative solution.
24
Q
Service Instance per Container: context
A
You have applied the Microservice architecture pattern and architected your system as a set of services. Each service is deployed as a set of service instances for throughput and availability.
25
Service Instance per Container: problem
How are services packaged and deployed?
26
Service Instance per Container: forces
Services are written using a variety of languages, frameworks, and framework versions
Each service consists of multiple service instances for throughput and availability
Service must be independently deployable and scalable
Service instances need to be isolated from one another
You need to be able to quickly build and deploy a service
You need to be able to constrain the resources (CPU and memory) consumed by a service
You need to monitor the behavior of each service instance
You want deployment to reliable
You must deploy the application as cost-effectively as possible
27
Service Instance per Container: solution
Package the service as a (Docker) container image and deploy each service instance as a container
28
Service Instance per Container: examples
Docker is becoming an extremely popular way of packaging and deploying services. Each service is packaged as a Docker image and each service instance is a Docker container. There are several Docker clustering frameworks including:
* Kubernetes
* Marathon/Mesos
* Amazon EC2 Container Service
29
Service Instance per Container: result benefits
* It is straightforward to scale up and down a service by changing the number of container instances.
* The container encapsulates the details of the technology used to build the service. All services are, for example, started and stopped in exactly the same way.
* Each service instance is isolated
* A container imposes limits on the CPU and memory consumed by a service instance
* Containers are extremely fast to build and start. For example, it’s 100x faster to package an application as a Docker container than it is to package it as an AMI. Docker containers also start much faster than a VM since only the application process starts rather than an entire OS.
30
Service Instance per Container: result drawbacks
The infrastructure for deploying containers is not as rich as the infrastructure for deploying virtual machines.
31
Service Instance per Container: relateds
* This pattern is a refinement of the Service Instance per Host pattern
* The Service Instance per VM pattern is an alternative solution
* The Serverless deployment pattern is an alternative solution.
32
Serverless deployment: context
You have applied the Microservice architecture pattern and architected your system as a set of services. Each service is deployed as a set of service instances for throughput and availability.
33
Serverless deployment: problem
How are services packaged and deployed?
34
Serverless deployment: forces
Services are written using a variety of languages, frameworks, and framework versions
Each service consists of multiple service instances for throughput and availability
Service must be independently deployable and scalable
Service instances need to be isolated from one another
You need to be able to quickly build and deploy a service
You need to be able to constrain the resources (CPU and memory) consumed by a service
You need to monitor the behavior of each service instance
You want deployment to reliable
You must deploy the application as cost-effectively as possible
35
Serverless deployment: solution
Use a deployment infrastructure that hides any concept of servers (i.e. reserved or preallocated resources)- physical or virtual hosts, or containers. The infrastructure takes your service’s code and runs it. You are charged for each request based on the resources consumed.
To deploy your service using this approach, you package the code (e.g. as a ZIP file), upload it to the deployment infrastructure and describe the desired performance characteristics.
The deployment infrastructure is a utility operated by a public cloud provider. It typically uses either containers or virtual machines to isolate the services. However, these details are hidden from you. Neither you nor anyone else in your organization is responsible for managing any low-level infrastructure such as operating systems, virtual machines, etc.
36
Serverless deployment: examples
AWS Lambda
Google Cloud Functions
Azure Functions
37
Serverless deployment: result benefits
It eliminates the need to spend time on the undifferentiated heavy lifting of managing low-level infrastructure. Instead, you can focus on your code.
The serverless deployment infrastructure is extremely elastic. It automatically scales your services to handle the load.
You pay for each request rather than provisioning what might be under utilized virtual machines or containers.
38
Serverless deployment: result drawback
Significant limitation and constraints - A serverless deployment environment typically has far more constraints that a VM-based or Container-based infrastructure. For example, AWS Lambda only supports a few languages. It is only suitable for deploying stateless applications that run in response to a request. You cannot deploy a long running stateful application such as a database or message broker.
Limited “input sources” - lambdas can only respond to requests from a limited set of input sources. AWS Lambda is not intended to run services that, for example, subscribe to a message broker such as RabbitMQ.
Applications must startup quickly - serverless deployment is not a good fit your service takes a long time to start
Risk of high latency - the time it takes for the infrastructure to provision an instance of your function and for the function to initialize might result in significant latency. Moreover, a serverless deployment infrastructure can only react to increases in load. You cannot proactively pre-provision capacity. As a result, your application might initially exhibit high latency when there are sudden, massive spikes in load.
39
Serverless deployment: relateds
The Multiple Service Instances per Host pattern is an alternative deployment solution
The Single Service per Host pattern is an alternative deployment solution
40
Service deployment platform: context
You have applied the Microservice architecture pattern and architected your system as a set of services. Each service is deployed as a set of service instances for throughput and availability.
41
Service deployment platform: problem
How are services packaged and deployed?
42
Service deployment platform: forces
Services are written using a variety of languages, frameworks, and framework versions
Each service consists of multiple service instances for throughput and availability
Service must be independently deployable and scalable
Service instances need to be isolated from one another
You need to be able to quickly build and deploy a service
You need to be able to constrain the resources (CPU and memory) consumed by a service
You need to monitor the behavior of each service instance
You want deployment to reliable
You must deploy the application as cost-effectively as possible
43
Service deployment platform: solution
Use a deployment platform, which is automated infrastructure for application deployment. It provides a service abstraction, which is a named, set of highly available (e.g. load balanced) service instances.
44
Service deployment platform: examples
Docker orchestration frameworks including Docker swarm mode and Kubernetes
Serverless platforms such as AWS Lambda
PaaS including Cloud Foundry and AWS Elastic Beanstalk
45
Service deployment platform: relateds
Some deployment platforms provide a Service Registry and Server-Side discovery
Internally, a deployment platform might use use containers or virtual machines to deploy a service. Docker orchestration frameworks are, of course, explicitly container-based
Microservices
flashcards
Decks in class (15)
# Cards
-
Cap 112
-
Application Architecture Patterns16
-
Decomposite patterns17
-
Deployment patterns45
-
Cross cutting concerns16
-
Communication style pattern20
-
External API11
-
Transactional messaging23
-
Service discovery39
-
Circuit breaker6
-
Data management44
-
Security8
-
Testing Patterns18
-
Observability patterns49
-
UI Patterns9
