‫So let's talk about the Beanstalk
‫deployment options whenever you're doing
‫an update to your application.
‫So you have several ones, and each of them
‫is going to be described with diagrams
‫in the next few slides, so don't worry about it.
‫But I just wanna give you an overview
‫of what they are before we dive into them.
‫So the first one is all at once,
‫where you deploy all in one go.
‫It's the fastest, but then your instances
‫are going to be down because they will be updating,
‫and so you'll have some downtime.
‫You have rolling, where you update
‫a few instances at a time, and then you move on
‫to the next set of instances, called a bucket,
‫once the first bucket is healthy.
‫You can also do rolling with additional batch.
‫This is just like rolling, but you spin up new instances
‫to update instances over time so that you'll still have
‫the old application available with the same capacity.
‫You have immutable.
‫This is when you have instances in Auto Scaling group.
‫You deploy new instances altogether.
‫You deploy the version to these instances,
‫and then you swipe out all the instances
‫when everything is healthy.
‫You have blue/green, where you create
‫a whole new environment altogether,
‫and then you switch over when ready.
‫And finally, we have traffic splitting.
‫This is for canary testing.
‫Canary testing is when you send a small percentage
‫of the application traffic to a brand new deployment.
‫So all these things, obviously,
‫you're going to learn in the next few slides,
‫so don't worry, this is just an overview,
‫and you'll learn about the diagrams for all of these.
‫So let's talk about all at once.
‫Here is our four EC2 instances,
‫and they all run the version one,
‫which is blue, of our application.
‫Then we are going to do an all at once deployment.
‫So we want deploy v2.
‫And what happens, that first Elastic Beanstalk
‫will just stop the applications on all our EC2 instances.
‫So then I put it as gray, as in they don't run anything.
‫And then we will be running the new V2,
‫because Elastic Beanstalk will deploy V2 to these instances.
‫So what do we notice?
‫Well, it's very quick.
‫It's the fastest deployment.
‫The application, though, has downtime,
‫because you can see in the middle they're all gray,
‫and so they can't serve any traffic.
‫I think it's great for when you have quick iterations
‫and development environments when you wanna deploy your code
‫fast and quickly, and you don't really care about downtime.
‫And finally with this setup, there's no additional cost.
‫Now let's talk about rolling.
‫The application will basically be running below capacity,
‫and we can set how much below we want to set,
‫like running the capacity.
‫So that's called the bucket size.
‫And so let's have a look.
‫We have four instances running v1,
‫and the bucket size will be two for the example.
‫So what happens is that the first two instances
‫will be stopped...
‫Not the instances, sorry, the application on the instances
‫will be stopped, and so they're gray.
‫But we still have the other two instances running v1.
‫So you can see we have maybe half capacity here.
‫Then these first two instances will be updated,
‫so they'll be running v2, and then we will roll on
‫to the next bucket, or to the next batch.
‫And so that's why it's called rolling.
‫As you can see now, the bottom two instances
‫will have their application v1 taken down to some gray,
‫and then updated to v2.
‫And so at the end, we have all the EC2 instances
‫that have been updated to run the v2 application code.
‫So as you can see now, the application,
‫at some point during the deployment,
‫is running both versions simultaneously.
‫And there is no additional cost, okay?
‫You still have the same number of EC2 instances
‫running in your infrastructure.
‫And so if you set a very small bucket size
‫and you have hundreds and hundreds of instances,
‫it may be a very long deployment, okay?
‫Right now, in this example,
‫we have a bucket size of two and four instances,
‫but we can have a bucket size of 2 and 100 instances.
‫It will just take a very long time to upgrade everything.
‫Now, there's an additional mode
‫called rolling with additional batches.
‫And so in this case, the application is not running
‫under capacity, just like before.
‫Before, at some point, we were only running
‫two instances out of four.
‫So that was below capacity.
‫In this mode, we run at capacity,
‫and we can also set the bucket size.
‫And basically our application will still be
‫running both versions simultaneously,
‫but at a small additional cost.
‫That additional batch, that we'll see in a second,
‫will be removed at the end of the deployment.
‫And again, the deployment is going to be long.
‫It's honestly a good way to deal with prod.
‫So let's have a look.
‫We have our four v1 EC2 instances,
‫and the first thing we're going to do
‫is deploy new EC2 instances,
‫and they will have the v2 version on it.
‫So now, from four instances, Elastic Beanstalk
‫automatically created six instances for us,
‫so an additional two.
‫and you can see that the additional two
‫are running, already, the newer version.
‫Now we take the first batch to the first bucket of two
‫and they get stopped, the application gets stopped,
‫and the application gets updated to v2, excellent.
‫Then the process repeats again, just like in rolling.
‫So the application running v1 gets stopped,
‫and then the application is updated to v2.
‫And so at the end, you can see,
‫we have six EC2 instances running v2.
‫And so at the end of it, the additional batch
‫gets terminated and taken away.
‫So why would you do this?
‫Well, now we can see that we are running always at capacity.
‫The lowest number of EC2 instances running the application
‫we have at any time is four.
‫So sometimes we are running at over capacity, obviously,
‫and this is why you have a small additional cost.
‫It's very small, but there is an additional cost.
‫And sometimes the exam asks you,
‫is there an additional cost to this kind of stuff?
‫Then we have immutable type of deployments.
‫And these deployments are also zero downtime,
‫but this time the new code is going to be deployed
‫to new instances.
‫So before, it was on previous instances,
‫now it's deployed on new instances.
‫And where do these instances come from?
‫Well, they come from a temporary ASG.
‫So there's a high cost, you double the capacity
‫because you get a full new ASG,
‫and it's the the longest kind of deployment.
‫As a bonus though, you get a very quick rollback
‫in case of failures, because to just mitigate failure,
‫you just have to terminate.
‫Not you, but Elastic Beanstalk
‫will just terminate the new ASG.
‫So it's a great choice for prod,
‫if you're willing to take a little bit more cost.
‫So here's the idea.
‫We have a current ASG with three applications v1
‫running on three instances.
‫And then we're going to have a new
‫temporary ASG being created.
‫At first, Beanstalk will launch one instance on it,
‫just to make sure that one works.
‫And if it works and it passes the health checks,
‫it's going to launch all the remaining ones.
‫So right now, three instances.
‫When it's happy, it's going to sort of merge
‫the ASG with a temporary ASG.
‫So it's going to move all the temporary ASG instances
‫to the current ASG.
‫So now, in the current ASG, we have six instances, okay?
‫And when all of this is done and the temporary ASG is empty,
‫then we have the current ASG
‫that will terminate all the v1 applications,
‫while the v2 applications are still there.
‫And then, finally, the temporary ASG will just be removed.
‫Finally, there's something you may hear in the exam
‫or in the white papers, it's called blue/green,
‫and it's not a direct feature of Elastic Beanstalk,
‫but I'll try to give you my best version of it.
‫It's basically a zero downtime,
‫and it helps with the release facility,
‫allows for more testing, et cetera, et cetera.
‫And so the idea is that you wanna deploy
‫a new stage environment.
‫So it's just another Elastic Beanstalk environment,
‫and you'll deploy your new v2 there.
‫So before, all the deployment strategies
‫were within the same environment,
‫here, we create a new environment.
‫And so the new environment stage, or green,
‫can be validated independently in our own time
‫and then roll back if issues.
‫And then we can use something like Route 53, for example,
‫to prevent the traffic from going into the two directions.
‫So we can set up weighted policies
‫and redirect a little bit of traffic
‫to the stage environment so we can test everything.
‫And then when we're happy using
‫the Elastic Beanstalk console,
‫you can swap URLs, when done, with a test environment.
‫So this is not a very direct feature,
‫and it's actually very manual to do.
‫It's not embedded into Elastic Beanstalk,
‫so some documentation will say there is blue/green,
‫some will say it's not there, but overall it's very manual.
‫So just one graph, I try to make it simple.
‫But in the blue environment, running into one
‫Elastic Beanstalk environment, we have all the v1,
‫and then we'll deploy a green environment
‫with all the v2, okay?
‫And they're both running at the same time, just very fine.
‫And then in Route 53 we're going to set up a weighted
‫type of policy to send 90% of the traffic to blue.
‫So just keep most of the traffic going
‫to the instances we know work,
‫and maybe only 10% of the traffic to the green environment,
‫just to test it out and make sure it's working
‫and the users aren't having any problems.
‫And so the web traffic basically gets split 90/10,
‫but it's whatever you want, as far as the weight goes.
‫And so when you're happy where you're testing,
‫when you measured everything you want
‫with your v2 environment and you think you got it,
‫then you basically shut down the blue environment
‫and swipe the URL to make the green be the main environment.
‫So that's it for blue/green, right?
‫And it's pretty complicated,
‫and I think pretty manual, Elastic Beanstalk,
‫but that's the way it is.
‫Another kind of deployment you can do with Elastic Beanstalk
‫is called traffic splitting.
‫And this will be used for canary testing.
‫So if you see canary testing on the exam,
‫think traffic splitting.
‫So what is canary testing?
‫Well, a new application version is going to be deployed
‫to a temporary Auto Scaling group with the same capacity.
‫So we have the main Auto Scaling group
‫and a temporary Auto Scaling group with the same capacity.
‫So three instances in the main one,
‫and three instances in the temp.
‫So it doubles the capacity.
‫And what's going to happen is that a small percentage
‫of the traffic is going to be sent to the temporary ASG
‫for a configurable amount of time.
‫So we have an ALB, and we're going to say,
‫"Okay, 90% of the traffic goes to my main ASG,"
‫"while 10% of the traffic goes to my temporary ASG."
‫And all of this is automated.
‫The deployment health of the new temporary ASG
‫is going to be monitored.
‫And in case there is a deployment failure,
‫or there is a metric that goes wrong,
‫this will trigger an automated rollback,
‫which will be very, very quick
‫because the main ASG is already here,
‫and all we have to do to roll back
‫is to stop sending 10% of the traffic to this temporary ASG.
‫So there is no application downtime.
‫And then once everything is stable and correct,
‫then the new instances are going to be migrated
‫from the temporary ASG to the main original ASG.
‫And then the old application version
‫is going to be terminated.
‫So I really like that, because all of this is automated,
‫and this could be a big improvement
‫on top of the blue/green technique that I just described
‫in the previous lecture.
‫So if you wanted to compare all of those,
‫there is this link on the Beanstalk documentation,
‫which shows you the difference
‫between all the deployment methods I just explained.
‫And this is really cool,
‫because it gives you the method name,
‫the impact of a failed deployment,
‫the deploy time, if it's zero down time,
‫if there's a DNS change, what is the rollback process,
‫and where the code is deployed to.
‫So if you understood this lecture,
‫this table should make sense to you.
‫So what I recommend for you is to just explore this link,
‫have a read through, and make sure the table makes sense,
‫because the exam will give you one or two scenario questions
‫around the kind of deployment mechanism for Beanstalk
‫based on the constraints and requirements
‫of the deployment itself.
‫So that's it for this lecture, I hope you liked it.
‫You should be a deployment expert now,
‫and I will see you in the next lecture.