Behind the scenes of Rolling update.

How to update your new service AWS takes care of it. But what you want in the update and during an update we get to define it. Let's say your application is running and is serving the client's traffic. On updating the service you don't want to have downtime until your new service is spawned up because even if the downtime was for a fraction of second you are going to lose clients/ data and its a disaster.

I am going to focus on this post only about how a rolling update is happening.

Firstly, let us understand Fargate terminologies in simple terms:
Note: Task means your running application. let's go into technical details in later posts

Service schedular:
🍁 It tells AWS what strategy to follow when creating/updating a service. We have two strategy options i.e. REPLICA and DAEMON and each has its rule book to follow.
🍁 Fargate supports REPLICA:
It makes sure that the number of tasks you have defined are maintained Always. Let's say for some reason your application fails to run, AWS will keep on trying to start until it has reached the desired number of a task set by you.
It can create tasks across any zone within a region.

Deployment configuration:
It tells AWS when the task should be registered and deregistered.
It has the following parameters
🍁 maximumPercent:
It tells AWS: When you are going to update my service, at max you can keep X number of the task at running/pending stage at any point in time of your deployment.
🍁 minimumHealthyPercent:
It tells AWS: I want you to keep at least X number of tasks in healthy state and available at any point in time of your deployment.

Desired count
🍁 How many copies of the same application you want up and running.

Now, let's understand better with scenarios and how the above parameters work.

Scenario1:

🦋 Task Definitions: Smoor
🦋 Task Definitions Tag: 1.0
🦋 desired_count: 2
🦋 scheduling_strategy: REPLICA
🦋 deployment_minimum_healthy_percent: 100%
🦋 deployment_maximum_percent: 200%

Above definition states
🍁 I want two replicas of my application running.
🍁 I want a minimum of 100% * 2 = 2 replica available and healthy
🍁 At max healthy service can exist/alive at any point of time is 200% * 2 = 4, i.e. I can allow you (AWS) to run 4 tasks at any given point of time when you are doing rolling update or autoscaling.

Explanation
🍀 Above are the conditions set.
🍀 Now, I want to update my service to version 2.0.
🍀 Currently, two tasks are running of version 1.0
🍀 Based on the definition minimum of two healthy tasks should be running and at a max 4 task can be present in the running/pending state.
🍀 So, AWS will register two tasks having the latest version 2.0 one by one. Waits until the task passes health check.
🍀 Then deregisters task containing version 1.0 and sets back to the desired count i.e. 2.

🍀 Therefore, Doing this you are not loosing any traffic. Until version 2.0 tasks are up and healthy, the older task of version 1.0 will be serving the traffic. Once AWS is Confident enough and new tasks have passed all health checks it deregisters the old task and updates services with the latest version 2.0.

Scenario-2:

🦋 Task Definitions: Smoor
🦋 Task Definitions Tag: 1.0
🦋 desired_count: 4
🦋 scheduling_strategy: REPLICA
🦋 deployment_minimum_healthy_percent: 100%
🦋 deployment_maximum_percent: 100%

Above definition states
🍁 I want four replicas of my application running.
🍁 I want a minimum of 100% * 4 = 4 replica available and healthy
🍁 At max healthy service can exist/alive at any point of time is 100% * 4 = 4, i.e. I can allow you (AWS) to run 4 tasks at any given point of time when you are doing rolling update or autoscaling.

Explanation
🍀 The above conditions set are little tricky. I want 4 healthy tasks running also you(AWS) can't exceed more than 4 tasks when doing any updates.
How an update is going to happen?
🍀 Currently, four tasks are running of 1.0.
🍀 AWS will deregister one task of 1.0.
🍀 AWS will deploy one task of 2.0 and waits till it reaches a healthy state.
🍀 So, at present 3 tasks having version 1.0 are running and 1 task having version 2.0 is running. And is satisfying the condition of deployment_maximum_percent: 100%.
🍀 AWS will continue deregistering one task of 1.0 and registering one task of 2.0 until all four tasks are of 2.0 as per the desired count set.
🍀 This kinda updates take relatively more time and eats a lot of memory during the transition than scenario1.

I hope you got the idea of how a rolling update happens and based on your need you can set the parameters to desired values.