- [Instructor] So, as we've mentioned earlier,
the domain name system can be an excellent tool
for building deployment systems.
It's a universally accessible distributed database.
It's everywhere.
And it doesn't depend where you're hosting,
you're going to have DNS available.
And if your hosting provider doesn't offer programmatic DNS,
you can host your DNS on one provider and your instances
on another and it'll work just fine.
It also has some nice properties, because DNS
has active and standby built in, and has for decades.
So you can publish a primary with 100% use,
and a secondary, with 0% use.
But if your primary is completely dead,
all the computers on the internet will eventually notice
and start using the standby.
So you get sort of failover without you having to do
any of the work of the failing over, beyond configuring it.
And you don't have to maintain any central load balancers
that do the distribution, you can do round robin DNS,
where you publish five different domain names
for your service, and computers on the internet
are supposed to distribute their traffic among them,
which they do, to varying degrees.
One really great thing is reverting is easy.
Reverting is the same thing as deploying,
just kind of do it the other way.
It does have its downsides too.
There are some programs out there with broken DNS resolvers,
especially old versions of Java that, once they've resolved
a name, they keep it forever.
So if you change your domain to point to a new version
and you're running an API that's accessed by some of
these programs, then they may have a real slow time
switching to your new release.
And when you put out a new release,
it takes awhile for it to propagate through the internet.
It goes to your domain name server, which then has to go
to caching resolvers and intermediate servers, and that has
to go to caching resolvers at the endpoint, so it can take
awhile for your changes to propagate through the internet.
If you've already started out a release propagating
out through the internet and you immediately notice
that your release broke everything, well, you go ahead
and you start the revert.
Now you have the release and the revert chasing each-other
through the internet, so it sort of provides a limit
on how quickly you can turn around.
And there's a few things that are not really bad or good.
It's a little slow, but I haven't found that to be
a real significant drawback in practice.
What's more annoying is sometimes it's hard
to know when it's done.
Has traffic on your older server trickled off completely?
Or maybe not?
Maybe you still get a few requests to the older server?
When is it safe to turn it off?
Y'know, these things are a little bit questionable.
And a general strategy for building DNS-based deployment
systems is, first, get a way to program your DNS.
Move your DNS to a hosting provider that has an API.
I used Amazon's Route 53 quite happily, and have for awhile.
And you don't have to use Amazon
to use their DNS hosting provider.
Any hosting provider that gives you an API
will do just fine.
Then it's a matter of building deploy strips that can
generate these change requests and start them propagating.
I generally take the rule of starting off
with a 90/10 split, 90% goes to the old service,
10% with the new service.
And then, take it down in steps, between 10 and 20,
depending on the service.
So, 90/10, 70/30, et cetera,
until you loop down to 0/100.
The old service is still there, and if the new service
totally dies, well, servers will fall over to the old one.
You have to be aware of that, too, because if you're
depending on your old service not getting used,
someone might fall over to it anyway.
And then, reverting, of course, is trivial.
You just run the process the other way.
One little tip, though?
When reverting, it's often convenient to take fewer steps
and do it more quickly.
Most of the times, when I'm reverting,
I'm doing it in a bit of a hurry.
It's totally reasonable to build a deployment system
that incorporates DNS as kind of an easier alternative
to using a load balancer.
We'll be exploring load balancers shortly.