- [Alana] Hello, and welcome back.
It's time to talk about deploying our application.
How often do you think a deployment should be happening?
Quarterly? Weekly? Daily? Multiple times a day?
The answer to this is going to be different for everyone.
One thing I think we can agree on is that
a deployment shouldn't be a scary event.
If we automate our deployments,
and are doing this with some regular cadence,
deployment becomes an event that we have more
and more confidence in.
Now, deployment doesn't just go to production.
We have multiple stages, like dev, staging, testing,
and multiple branches of developments getting deployed.
We can easily see this won't scale to any manual process.
We are all going to have different requirements
for our deployments, and there are many ways
to deploy our applications, each with
their own advantages and disadvantages.
Here's Russ to run you through
some different deployment scenarios,
starting with something very simple.
- [Russ] Let's go over some deployment options.
The simplest deployment is just three steps.
First, we terminate the existing application on each
of the hosts where it's running.
Next, we deploy a new version to the same hosts.
The disadvantage to this approach would be
the downtime between terminating the application
and the deployment.
The advantage would be how simple this approach is.
You could have an application where this isn't an issue.
Maybe the users of your application
are only online during business hours
for a single time zone.
Bringing the application down at 10:00 PM
would have minimal impact, nice and easy.
How would you roll back this simple deployment?
It's 10:00 PM, we've rolled out the new version,
some testing has been performed on the new version
of the application, and we've encountered an error.
Not great.
We can roll back by returning to the original version
of the application.
This is effectively the same steps as initial deployment
using the previous version of the application.
You might've kept a copy of the previous version
on the hosts, so we can terminate our new version
and reinstate the old version.
Remember, it's important to have a plan for rollback.
Deployments may not go according to plan.
We don't want to come up with a rollback plan
in the middle of the deployment,
especially not at the 10:00 PM outage window.
What if zero downtime is a requirement for our deployment?
Let's take an application that has been deployed
to four hosts behind a load balancer.
We can look at metrics, like CPU usage,
and see that we have enough resources to remove one
or two hosts from the load balancer during deployment.
So, I deregister one host from my load balancer.
The goal here is to stop the traffic going
to the application on the host.
My application continues to work happily
on the remaining hosts, while I deploy
to the deregistered host.
I can do exactly the same steps on the deregistered host
as my replacement deployment.
Stop the application, install the new version,
start the application, and now register with
the load balancer.
My deployment looks good.
I can move onto the remaining hosts.
Let's call this a ramped deployment,
as we're slowly ramping up the hosts that serve
the new version of the application.
We have zero downtime.
It's a little bit more complex
than the replacement deployment, as we need
to coordinate with the load balancer,
but it's the same steps that we're using
for our replacement deployment,
so it's not that much more complex.
When the first host is serving version 2
of the application, we can start gathering metrics on
how the application is performing.
Are we seeing fatal exceptions coming from the application?
There is a variation on this type of deployment,
called a canary deployment, where we stop at a small number
of hosts and gather the results running version 2
with a percentage of production traffic.
We might discover an issue with the deployment.
We don't go ahead with the deployment
on our remaining hosts.
Rollback will be similar to our replacement deployment.
We need to reinstate the previous version
of the application on the hosts running version 2.
This is going to take time, and potentially impact our users
while we are removing hosts to redeploy the previous version
of the application.
We can roll back, it'll just take time.
The deployment options we have covered,
where you use the application hosts,
they are a type of in-place deployment,
but we are working in the cloud, where we don't really need
to have long-lived hosts.
We can turn on instances and have them ready super quick.
Let's take advantage of this with a blue/green deployment.
With a blue/green deployment, we turn on a new environment
that can handle production load.
We refer to this as the green environment.
The existing production environment is called
the blue environment.
We deploy the application to the green hosts.
No production traffic is going to the green host just yet.
This gives us a chance to perform some acceptance tests
or smoke tests on the newly deployed version 2.
We decide we're happy with the deployment.
We can start sending production traffic to the green hosts.
This can be done with a DNS switch or registering
and deregistering hosts from a load balancer.
You control the batch size of hosts in the green environment
that start receiving production traffic.
Maybe we want to add traffic to hosts one at a time,
or two at a time, or all of the hosts at once.
Once we have deployed, what do we do with the blue hosts
that still have version 1 of the application?
Now is a good time to talk about rollback.
With the blue/green deployment,
we can roll back very quickly by sending traffic back
to the blue hosts.
We can keep those hosts available until we are confident
they won't be needed for a rollback.
Before we wrap up, let's go over some considerations
for your deployments.
Sometimes, your application may not lend itself
to all forms of deployment.
Blue/green deployments mean newly provisioned hosts.
What if your application needs to store state
or data on the same host as the application?
This isn't a good practice.
Ideally, all applications should store state external
to the hosts, but some of us are working
with legacy applications that may not lend themselves
to this type of deployment.
In this case, we would need to look at in-place deployment.
Zero downtime sounds great, and something we want
for all of our applications.
Keep in mind during the zero-downtime deployment,
we're going to have version 1 and 2 running in parallel.
Maybe just for a short time, but we need to consider this.
We need to make sure changes remain compatible
with other systems we're talking to,
like a database or an API.
So, good luck with all of your future deployments.