- [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.