Microservices and Deployment
The above diagram represents a typical microservices architecture set up. As described on “microservices.io”:
Microservices is an architectural style that structures an application as a collection of services that have following properties:
· Highly maintainable and testable
· Loosely coupled
· Independently deployable
· Organized around business capabilities
· Owned by a small team
Why Microservices?
Microservices came into picture due to following disadvantages of Monolithic architecture:
· Change cycles are tied together — a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed.
· It’s often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module.
· While Scaling, you are required to scale the entire application which results in requirement of greater resources.
Micro-services and challenges
However, there are certain limitations and disadvantages of Micro-services as well, so it entirely depends upon the business requirement and team and resource at disposal to go for the approach, whether to follow monolithic architecture or micro-services.
· Micro-services result in complexity of architecture and it is directly proportional with number of services involved.
· Micro-services are expensive. Remote call between services result in higher costs associated with network latency.
· Security challenge is another aspect where micro-services can be overhead, due to increase in inter-service communication over network.
Circuit Breaker
While designing microservices architecture, one must consider the “design for failure” as an integral part of system design. Services are used as components in this architectural pattern, and what if a component fails or shuts down? Precious resources such as threads might be consumed in the caller while waiting for the other service to respond. This ultimately results in resource exhaustion, which makes calling service unable to handle other requests. This pattern is commonly known as “Circuit Breaker”, and the client needs to respond to UI as well as handle it with caution.
It is very important to detect failures and restore failing service automatically. A lot of emphasis is given on real time monitoring of the application.
Deployment of Micro-service
A micro-service application consists of multiple service components and it might be possible different service components are written in different languages and frameworks. Hence, each service might have its own specific resource requirement and deployment process. In micro-services, deployment process must also be fast, reliable and cost effective.
There can be a few micro-services deployment pattern, some of which we will be discussing:
Multiple Service Instances per Host
This pattern uses the strategy to host multiple services or service instances on one or more physical or virtual host. Understand it like, one port is hosting instances of 3 different services and other port is also hosting instances of the same services.
Pros:
· Efficient resource usage.
· Deployment of a service instance is fast.
· Due to less overhead, service start up is fast and smooth
Cons:
· No isolation level for service instances, meaning one service’s resource utilization can not be monitored or restricted.
· One development team needs to know deployment process of each service instance hosted on specific port.
Service Instance per Host
In this pattern, we run one service instance per host, maintaining a complete level of isolation. Now, there can be two different threads of this pattern: service instance per VM and service instance per container.
Service instance per VM
Each service instance is packaged as a VM (Virtual Machine), that is launched using VM image. For example: Amazon EC2 AMI, which is used by Netflix to package its services. Basically, each running service is an EC2 instance in itself.
Pros:
· Services run in complete isolation.
· Fixed amount of CPU and memory utilization.
· Load balancing and auto scaling can be achieved smoothly.
· Deployment is simple.
Cons:
· Resource under-utilization can be an issue.
· Due to VM’s size, deployment of new version can be slow.
· Building and managing VMs can be an overhead.
Service instance per Container
As mentioned on Docker’s website:
“A container is a standard unit of software that packages up code and all its dependencies, so the application runs quickly and reliably from one computing environment to another.”
Containers are like virtualization mechanism at OS level, meaning that, they have their own port namespace and root file system.
In this pattern, services are packages as container image rather than VM image and multiple containers can be run on each VM. Container managers like Docker Compose, Kubernetes, etc. can come handy while managing a cluster of containers.
Pros:
· Service isolation.
· Allocation of CPU and memory to container can be limited.
· Containers are lightweight and build fast in comparison to VMs.
· Services start faster.
Cons:
· Security in containers can be a concern, since kernel of host OS is shared with one another in a cluster.
· In case of spikes, cost management of over provisioning VMs can be trickier to handle.
Serverless Deployment
Serverless is a method of providing back-end services on an as-used basis. It helps build app with less overhead and cost. For example, AWS Lambda. All one needs to do is to package a service as a .zip file and throw it to Lambda. Now this approach will also have its advantages and limitations, especially when it comes to long running services.
Spring Boot Micro-services and Docker Deployment
Following Github project is a sample of deploying spring micro-services using Docker and Docker-Compose.
The File Structure contains Dockerfiles of respective Spring Microservices including Discovery Server and respective clients which register to this server and are connected through a network create by Docker Compose at run time.
Note: The main idea behind this architecture is: The respective Spring microservices can be developed independently. All one has to do is to clone the repositories with respective Dockerfile and run within a container using Docker Compose.
References: