Deployment and Provisioning
In this group of lectures we run a hands on deployment of the next iteration of the Pizza Time solution. The Pizza Time business has been a success. It needs to support more customers and wants to expand to meet a global market.
We define our new solution, then walk through a hands on deployment that extends our scalability, availability and fault tolerance.
Hi, and welcome to the final lecture of this course. In this course, we'll talk about Route 53, we are going to have a quick overview about the service, we are going to talk about health checks, and routing policies. Then we are going to finally plan the last part of our Pizza Time deployment. And in the last part of this lecture, we'll have a demo on how to deploy the final part of our Pizza Time application. We are going to create a few health checks, and then we are going to create something called latency based routing.
So, Route 53 is a high available and scalable cloud DNS web service. That's really not new, so let's move forward. The most impressive thing about Route 53 is that it is a global service. Route 53 expands across all AWS regions, all AWS edge locations. So, the result is that you have a super fast DNS service. Usually when you hire a DNS provider, they don't tell you where their infrastructure is. And on Route 53, that's different. We can have an idea of the whole Route 53 infrastructure taking a look at the AWS infrastructure. AWS will replicate the Route 53 data across all their service. So, the result is, you have a super fast DNS service anywhere in the world.
Route 53 also provides health checkings. And you can check endpoints running anywhere. You can check endpoints running on AWS, you can check endpoints running on your on-premises environment, or in another cloud provider. And health checks works more or less as the ELB health checks works. So when we went to the page to configure a health check, we'll probably be able to guess what we are supposed to do there.
Talking now about routing policies. We already created a few entries on Route 53 and, so far, we only used the simple routing policy. And the simple routing policy is kinda self-explanatory. We'll have an endpoint, in this case it can be an app server, or whatever. And we will create a DNS entry, a record set that will point to the endpoint that we specify. And that's it, nothing more to add in here. Super simple, as the name suggests. But one of the greater features about Route 53 is that you can also have other types of routing policies. You can have, for example, weighted routing policies, where you can specify weights for your routes, and Route 53 will forward the request, accordingly to the weights that you specify to the routes.
So, for example, let's think about a migration situation. Remember when we migrated from the Elastic Beanstalk application to the application that we immediately launched using Auto Scaling? So, what we could do in a similar situation is we could create the new version, as we did, and we could still use the old version. And we would create a weighted routing policy. We would put a weight value of two in here, for example, and a weight value of eight pointing to the old version. The sum of these two values is 10. And that would mean that AWS in two of 10 times would send the users to the new version, and in eight of 10 times, would send the users to the old version. And what you can accomplish with this is you can test the load of your new version, of your new application, you can test if there is any error, if the users are complaining about it. And you can also do other types of things with weighted routing policies. You can do, for example, A/B testing. You could put a value of five in here, and five in here, and you'd have half of the requests being sent to each of the endpoints. And you could evaluate the result in the end. So, the best way of doing a migration is by using weighted routing policies. You can slowly increase this weighted value, let's say that as you test, and as you see that the performance in here is satisfactory, you can increase the weight in here to, let's say, five, then eight, then 10. And you would decrease the value in here until a certain point that the weight would be zero, which means that Route 53 is not supposed to send any requests to that endpoint.
We can also have latency routing policy. When you create a latency routing policy, you make a request to Route 53, and Route 53 will evaluate the endpoint which will have the least latency, and will forward you to that endpoint. So, in this case, we have a user, and the user will make the request. And Route 53 will evaluate where the user is, and evaluate which endpoint will have the least latency. And after Route 53 evaluate that, Route 53 will take the decision to forward the user to one of the endpoints. So if the user is close to the app two, he will be sent to the app two. And if the user is closer to the app one, he will be sent to the app one. That's very useful when you have a global application, like the case of Pizza Time, and you want to have the request being forwarded to the closest region possible. And you can achieve that using latency based routing.
You can also have failover routing policies. For failover, that's kinda self-explanatory. You have two endpoints, and Route 53 will evaluate the health of the first one. And if there is a problem in here, and this app goes down, only in this case, AWS will forward the request to the standby endpoint.
And you can also have geolocation routing policies. With geolocation routing policies, you will specify where you want to send the request based in the country, or in the continent, or even in the states, in case you are dealing with the United States. So, for example, you can say that all requests coming from Europe will be sent to an endpoint in the Frankfurt region, for example. So, if someone in Germany access your domain, your record set, he will be sent to the Europe region. And you can also say that someone from the U.S. accesses your domain, he will be sent to the Oregon region, because we said so, we said that for U.S., Canada, and others, forward the request to the Oregon region. And when I say, "Others", that is because we can do two things with geolocation. We can specify the best endpoint based on the country. So, in this case, we are expecting, mainly, users from Europe, U.S., and Canada to access our application, so we will deal with those countries. But imagine if we had to define rules for all countries. I don't know how many countries we have, for sure that would be a pain. So, what you can do is you can define also a default endpoint. And if someone requests that URL, if someone access the record set, and Route 53 doesn't know what to do, the service will send that user to the default region.
But there is also another application where you don't want the default region. Maybe you want to have an application, and you have prepared your application to serve only U.S., Canada, and Europe, so you would erase this rule, and only requests coming from IP address in U.S., Canada, and all over Europe would have an endpoint. And, for example, if someone from Brazil tried to access the application, he would not receive anything, because you haven't defined a default region, and you haven't defined a rule for Brazil, so that user would receive no answer when tried to access this record set.
So, we talked about health checks, there is a great feature in here. We can associate record sets with health checks. And, in fact, we talked about failover routing policies. In the failover routing policy, you must create health checks, you must evaluate the health of your endpoints. But for the other types of routing policies, that's not mandatory. In the case of the failover, you'd have to evaluate the health of your endpoint and if something goes down, AWS will automatically failover to the standby. And after the health checks goes back to green, AWS will forward that request back to the main endpoint. But you can do the same with geolocation. With geolocation, you could associate health checks with both endpoints, for example, and if something happens in Frankfurt and this app goes down, no matter if the requests coming from Canada or U.S., the users would be forwarded to the Oregon region. Same thing in the latency based. Let's say that this app is closer, but the health check came and the result is that this endpoint is not working, so AWS would start forwarding the requests only to the other endpoint. And so on for weighted routing policies.
Now it's finally time to finish the deployment of our Route 53 domain. We still need to configure our API record set. We want to have a latency based routing in our API calls. So, if our users in Brazil access our domain, they will be forwarded to the São Paulo region. And if our users in the U.S. or Canada access our Pizza Time URL, they will be forwarded to the Oregon region. But when we made API calls, remember that we deployed our main app, our angular app, in a web distribution on CloudFront. So, since CloudFront is a global service, every time you go to the main URL, you will be forwarded to the web distribution, and the web distribution will be served on an edge location or region closer to you. So we don't need to do anything in our main record set.
But in the API record set, we want to create a latency based routing policy. And we also want to make sure that if something fails in the Oregon region, let's say that the entire region goes down, we want to forward all the API requests to the São Paulo region. Even though we won't be able to create new requests, because the main instance lives inside the Oregon region, we will still be able to make some simple API calls as login and check out order, and so on.
So, now let's go to the AWS console and learn how to create health checks and create also a latency based record set using Route 53. Okay, so the first thing that you should do is take the addresses from both ELBs in the Oregon and São Paulo region. I already did that. And after you have those addresses, you can go in the Route 53 console and, instead of dealing with hosted zones right now, we will create a health check. So, we click on Health checks, Create health check, and we can specify a name. I'll say that it's the pizza time ELB Oregon, and we want to monitor an endpoint, and remember that the ELB service doesn't provide us an IP address, it provides us a domain name, so we will use a domain name. Let me copy and paste the URL from the Oregon region. We'll use port 80, and we will use the root path, so we don't need to add anything here. We click on Next, and we can create an alarm to be associated with this health check. The alarm will use CloudWatch, and we already covered CloudWatch in this course, so you know what you can expect from a CloudWatch alarm. I don't want to create an alarm, I will just simply create the health check. Now I want to create the second health check, the process will be the same. I'll just change the name this time. Let me take the URL. And in here we had the listings of all health checks. I will pause the recording till we have an okay status, then I'll get back to continue configuring our Route 53 domain.
Okay, so both health checkers are okay. And right now we have a health status, and if we select a particular health check, we can take a look at the Monitoring tab, that will have a few metrics, the metrics are stored on CloudWatch, nothing new in here. And we will have a status one every time that we have an okay state. And if something's wrong, we'll have zero as result. We can create alarms by going in the Alarms tab. We can also create alarms on the CloudWatch console. We can add tags. We can take a look at the health checkers that AWS is using, so you can see that AWS will check the health of your endpoint through endpoints located all over the world. So there isn't a single point of failure in these health checks. As I said, you only have problems if the entire AWS infrastructure goes down. It's not impossible, but, yeah, I believe that won't happen anytime soon.
And we can also check the latency of our connection. To do that, we need to associate a latency check with our health check. That has an extra cost in the health check. If you want to associate that, you can either do that when you create the health check, if we have checked the Advanced tab, we could select latency check, but that's really not important for this certification, so I'll skip that part. Just know that you can associate a latency check with a health check. And if you want to do that, you can simply edit the health check and add a latency check to that health check.
Let's now more forward, and manage our hosted zones. So I'll go on Hosted zones, I will select our Pizza Time hosted zone, and the record set that we want to change is this one. We want to change the API dot pizza dot clouda dot rocks, which is the record set that manages our API access. We want to change the routing policy. This is pointing currently to the Oregon ELB, we will keep that and we will only change the routing policy. We'll say that it's latency based, and we need to specify the region here, and we can set an ID. The ID can be anything that will remind you of that particular endpoint, so, in this case, I'll just say that ELB Oregon, you can put anything you want. And we want to evaluate the target health, and we want to associate this with a health check that we already created. So I will select the ELB Oregon. We can click on Save Record Set. And now we can create another record set. We will call it API as well. And that will also be an alias. And this time we don't want to point to the Oregon region, we want to point to the ELB running in the São Paulo region. So I will select the other ELB that we have. Again, routing policy is latency based. Specify the region. Set an ID. Evaluate target health. Associate with a health check. And it's the São Paulo ELB. Now we have both entries created. And we can see that we have a health check associated with this record set. And from now on, every time that we have problems with that particular health check, AWS will automatically failover that entry to the other entry. And just in case that both regions go down or we have problems with our instances in both regions, that we won't have AWS sending the API request to any region.
About the Author
Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.