AWS - Immutable Deployment

-

 

The AWS service most commonly associated with immutable deployments is AWS Elastic Beanstalk.

Immutable deployment is often confused with blue/green deployment strategy.

The word immutable means something that is unchanging over time or unable to be changed. It’s often used to describe things that are fixed, permanent, or resistant to modification.

Let's say your application is deployed as below:


So, we have a load balancer with a target group attached to a auto scaling group and there are 3 instances serving traffic for an application version1.

Now, you want to deploy application of version2 without any downtime using Immutable deployment strategy. 

This starts by creating a another ASG with one instance deployed with application version2.


At this moment, there are totally 4 instances.

And the load balancer routes traffic to all the 4 instances in round robin fashion. Once the new instances look good, ASG count on v2 version increased by 2 and the ASG count on v1 is set to 0.



This is method is called "Immutable Deployment" where no downtime required. In case of any issues rollback is straight forward, Scale up ASG 1 and scale down ASG 2.

In this strategy, at some point your application will serve traffic for version 1 and 2.

What is BLUE/GREEN?

There are many services like AWS Elastic Beanstalk, ECS, EKS, Lambda, API GW and CloudFormation uses this strategy. 

This primary focus on swapping the traffic by making changes in the Load balancer layer.

Let's go with the same example as above.



We create another ASG2 and add it to the target group and remove ASG1 from the target group.

If there are any issues, we add ASG1 back to the target group. This strategy allows only one version of the application to take traffic and roll back is much faster compared to immutable strategy. But, the cost is bit high as we have to run two versions of the application with full capacity.



Comments

Post a Comment

Popular posts from this blog

K8s - ETCD

-
Image
  etcd is a "strongly consistent , distributed key-value store". Why etcd? 1. Consistency : Since the API server is the central coordination point of the entire cluster; strong consistency is essential. It would be a disaster if, say, two nodes tried to attach the same persistent volume over iSCSI because the API server told them both that it was available. 2. Availability: API downtime means that the entire Kubernetes control plane comes to a halt, which is undesirable for production clusters. The  CAP theorem  says that 100% availability is impossible with strong consistency, but minimizing downtime is still a critical goal. 3. Consistent Performance: The API server for a busy Kubernetes cluster receives a fair amount of read and write traffic. The secret behind etcd's balance of strong consistency and high availability is the  Raft algorithm . Raft solves a particular problem: how can multiple independent processes decide on a single value for somethin...
Read more

SRE/DevOps Syllabus

-
Image
  DEVOPS/SRE Principles. Git What is Git? Architecture of Git. Working principle of Git. Create and cloning a repo. Version control branching. Version control commit. Version control managing workflows. Git hooks. Git Reflog. Git Stash. Git Cherry Picking. Undoing changes in different states of Git. Git based terraform template management. AWS CI/CD SDLC Automation. Code Commit. Code Build. Code Deployment. Code Pipeline. Elastic Beankstalk. Code Artifact. CodeGuru. Terraform Terraform Basics. Terraform State. Working with Terraform. Terraform with AWS. Remote State. Terraform Provisioners. Terraform Import, Tainting and Debugging. Terraform Modules. Terraform Functions and Conditional Expressions. Automation using Python - AWS AWS lambda. Automating EC2 with Lambda. Automating S3 with Lambda. Automating VPC with Lambda. Cost optimization with Lambda. SNS,SQS and SES with Python. Managing and Automating AWS Security with Python. Kubernetes - CKAD Application Developer. Kubernetes A...
Read more

K8s - Deployment and HPA replicas

-
Image
  We all know that replica is a critical part of a K8s deployment. Default replica is 1. Setting replicas as 3 will ensure 3 pods of that deployment is running at any given time.  Replica are internally managed by replica set which is in turn controlled by the K8s  ReplicationController   . When a pod is bad or deleted as part of replicaset, replication controller will ensure a new pod is created. Now, coming to HPA (Horizontal Pod Autoscaler) which is a dynamic scaler which works at the pod level based on the metrics configured.  When we configure we must mention min and max values. They should be greater than 1. Let's image I create a HPA with min as 5 and max as 10 under the condition of CPU utilization more than 50%. Initial deployment is set with the replica as 1. On top the deployment, I am attaching a HPA with the mentioned configuration. Under HPA, we are forcing the min replicas to 5. Hence, it autoscales the pod to 5 even though the CPU utilization is ...
Read more