This article will explore various microservices deployment patterns and look at how to deploy microservices so that they can be easily scaled to handle a large number of requests from other integrated components.
In my previous articles, I have explained Software architectural patterns such as Monolithic, SOA, and Microservices architecture patterns. Monolithic architecture sometimes is suitable for startup companies. The monolithic has some own benefits and drawbacks as we have discussed in my previous article Software architecture patterns & designs. SOA is another software architecture pattern, it was very software architecture patterns before 2015. There are some limitations of SOA pull the leg to the back. You can see the comparison between SOA and Microservices architecture patterns in my other article.
Microservices architecture is one of the very popular software architecture patterns that is used widely in software development nowadays. Currently, software applications must be scalable and customizable, the microservices architecture provides high-level software scalability. There another more benefits what microservice architecture has.
Apart from the benefits, the microservice architecture has some challenges such as how to decompose an application to the microservices based application. In the previous article, we have discussed how we can decompose an application to the distributed application based on the Microservices architecture and architected the application as a set of services.
I will cover the following technical topics, that will the reader learn about during this article. And also I will explain various deployment patterns such as Multiple service instances per host, Service instance per host.
Microservices Deployment Patterns
We can deploy each service as a set of service instances for throughput and availability. The Microservices architecture is forced that service must be deployable and scalable independently and all service instances must be isolated to each other.
The Microservice architecture allows to quickly build and deploy a service and also allow us to constrain the resources such as CPU, memory, and I/O resources for a service. A microservices application has tens of or hundreds of services. You can independently increase or decrease resources of deployment machine based on the usage of a service. It also allows you to write a service in any language and framework and accordingly we can provide infrastructure to a service. You can monitor each service independently and deploy service according to its behaviour.
For example, you have a requirement to run a service with its certain number of instances based on the demand for this service in a business application. With the Microservices application, you can easily achieve it by adding multiple VMs or containers for this particular service and also can provide the appropriate CPU, memory, and I/O resources for each instance of this service. So, challenging part is service deployment must be fast, reliable and cost-effective.
There are the following strategies, we can use for deploying microservices of a distributed application:
- Multiple instances of the Microservices per host
- Single instance of the Microservices per host
- A single instance of the Microservices per VM
- The single instance of the Microservices per Container
You can learn more about these microservice deployment patterns, were suggested by Chris Richardson on his blog, https://microservices.io/.
Let’s now have a look at each microservices deployment patterns in detail.
Multiple instances of a Microservice per host
According to this microservices deployment patterns, the Multiple instances of a Microservice run at one physical or virtual host. In this approach, each instance of the service runs on a different well-known port on one virtual or physical machine. It is a very traditional approach to the deployment of a microservice application. Let’s see the following diagram about this approach of the microservices deployment:
As you can see in the preceding diagram, it shows the structure of the microservice deployment pattern. There are two physical or virtual hosts (A and B). These hosts have multiple instances of microservices for our application, and they are Account Service, Order Service, and Book Service.
- You could deploy multiple instances of the microservices on the same Apache Tomcat server or in the same JVM.
- In another way, you could deploy an instance of a microservice as a JVM processor on an Apache Tomcat server such as a Tomcat instance per service instance.
Benefits
This pattern has the following benefits:
- It has more efficient resource utilization than other approaches.
- Deploying a service instance is relatively fast.
Drawbacks
The drawbacks of this approach include:
- There is no isolation between the instances of microservices; therefore, a defective service instance could produce noise or affect other services in the same process.
- It could create conflict over resource utilization between instances of microservices.
- It could also cause problems due to a conflict between versions.
- We can’t assign a specific amount of resource utilization, nor can we increase the resource capacity for a specific instance of microservices.
- It is also difficult to monitor resource utilization independently for one instance of a microservice.
This is the traditional approach to deploying microservices, so it has more limitations than the others. Let’s another approach of the Microservice deployment patterns.
A single instance of a microservice per host
It is another approach to deploying microservices. According to this microservices deployment, patterns deploy the single instance of the microservices on its own single host. A service instance is deployed to its own host. Each service instance runs isolated. There are two specific patterns of this approach as the following:
- The single instance of the Microservices per VM
- Single instance of the Microservices per Container
A host can be a physical machine, a virtual machine, or a container such as a Docker container. The following diagram demonstrates this approach of deploying microservices:
As you can see in the preceding diagram, there is a number of hosts, each of which holds several instances of services. Each service instance has been deployed on its own host machine, that is either a VM or a container. Let’s now discuss the benefits and drawbacks of this approach.
Benefits
The benefits of this pattern include:
- This approach provides complete isolation between the instances of the microservices.
- We can easily heal a defective service without impacting other services.
- There is no resources utilization confliction between the instances of the microservices because each service runs on a separate host using own resources. There is no resource sharing between the instances of the microservices.
- We can assign a specific amount of resources for an instance of the microservices on demand.
- We can easily monitor, manage, and redeploy each service instance.
Drawbacks
The drawbacks of this approach include:
- This approach of deploying microservices has less efficient resources utilization as compared with multiple instances of the microservices per host.
Let’s have a look at the two different types of this pattern.
A single instance of a microservice per VM
This is a specific approach based on the Single instance of the Microservices per host pattern, according to this approach you can package the service as a virtual machine image and deploy it using this VM image. The service instance is deployed as a separate VM. For example, as VM we can use an AWS EC2 instance. Let’s see the following diagram is based on this Single instance of the Microservices per Virtual Machine pattern:
As you can see in the preceding diagram, this pattern packages an instance of the service as a VM image and launches the VM images as a running process, such as the Amazon EC2 AMI.
Netflix packages each service as an EC2 AMI and deploys each service instance as an EC2 instance. There are various tools available on the market to package instances of your services as VM images. For example, Jenkins invokes Aminator to build an instance of your service as an EC2 AMI. Similarly, Packer creates VM images through multiple virtualization technologies such as EC2, DigitalOcean, VirtualBox, and VMware.
Let’s now move on and have a look at the benefits and drawbacks of this approach.
Benefits
The benefits of this approach include:
- VMs based approach is very straightforward to scale by increasing the number of instances. If you use this pattern then you can use the power of the mature cloud infrastructure. For example, the AWS provides autoscaling groups to scale the service automatically based on the traffic or load to the service. AWS also provides another useful feature load balancing (Elastic Load Balancer).
- This approach is very isolated that means each service instance runs isolated without hampered by other services.
- Each instance has a fixed amount of resources such as CPU, and Memory, no other service can share their resources.
- The major benefit of deploying your service as a VM is that the deployment becomes much simpler and more reliable.
- A VM encapsulates your services along with various technologies inside a virtual box and it is like a black box.
Drawbacks
The drawbacks of this approach include:
- One drawback is less efficient resource utilization.
- Building a VM image is slow and time-consuming
- Another drawback is handling the overhead of building and managing the VMs. Some tools such as Boxfuse provide a solution for it but still, it is your responsibility to manage and build the VMs.
Let’s have a look at another, more lightweight approach to deploying microservices: the single instance of microservices per container pattern.
A single instance of microservice per container
According to this approach of the deploying microservice, each instance of the microservices run on a lightweight container. Each instance of the microservice has own container individually. The container is nothing but it is a virtualization mechanism at the operating system level. So, you can package your service as a container image, for example, a Docker image and you can deploy this container image as a container. Let’s see the following diagram:
As you can see in the preceding diagram, each container is virtualized over the operating system of the VM.
Docker is one of the extremely popular container-based technology. Docker provides a way of packaging and deploying services. Each service is packaged as a Docker image and this image is deployed as a Docker container. You can use Docker Containers with the following Docker clustering frameworks:
- Kubernetes
- Marathon/Mesos
- Amazon EC2 Container Service
Docker images have their own port namespace and root filesystem and you can also set a resource utilization limit for each container.
Let’s have a look at the benefits and drawbacks of this method.
Benefits
The benefits of this approach include:
- However, unlike VMs, containers are lightweight technology.
- Container images are typically very fast to build.
- Containers also start very quickly since there is no lengthy OS boot mechanism. When a container starts, what runs is the service.
Drawbacks
The drawbacks of this approach include:
- Currently, the container infrastructure is not so mature as the infrastructure for VMs.
- Also, container infrastructure is not secure as compared with infrastructure for VMs.
- VMs provide rich infrastructure but the container doesn’t.
- This approach has less efficient resource utilization as compared to Multiple Services per Host because there are more hosts.
We’ve now looked at multiple different approaches to deploying microservices. You can choose either VMs or containers for deploying microservices, according to your requirements.
Another method of deploying microservices that is becoming increasingly popular is serverless deployment.
Conclusion
In this article, we have learned about the microservices deployment patterns. We have discussed various deployment strategies, including the multiple instances of microservices per host pattern, the single instance of a microservice per host pattern, the single instance of a microservice per VM pattern, and the single instance of a microservice per container pattern. This gave you an understanding of the different structures, approaches, and strategies used when deploying microservices.
