![]() In a Lucid Chart diagram this HA setup would look like this:ĪWS Services are simply put your usual services from your software stack, but managed by Amazon. If one of servers goes down, or even the whole AZ, the load balancer will keep working and only send traffic to the server in the AZ that is still working. For a web server setup for example, using EC2 instances, you would create 2 servers, each in a different AZ, and have a EC2 LoadBalancer (which is also HA since it’s a managed service) in front of them. all the managed services we’ll see in the next topic), but you’re also required to use them intelligently yourself. Availability Zones (AZ): eu-west-1a, eu-west-1b, eu-west-1cĬertain things are automatically replicated within the AZ’s for a region (e.g.Each region has several availability zones, which are independent data centers that can communicate with each other as if they were a local network. It’s about not having a single point of failure in your setup by using redundant setups using the tools AWS offers you.Īn important part of HA setups is the concept of regions and availability zones (AZ). High-Availability (HA) is a concept that you will see pop up everywhere when using AWS. The right way: build your application for AWSīefore we continue to optimize our setup for AWS I have to explain a few AWS concepts that will be important to understand: Managed Services and High-Availability High-Availability Just keep in mind that if you just compare the cloud cost to your own datacenter cost using the same hardware setup you are not using the cloud the right way and you will pay a lot more than you should. So it doesn’t fix any of the problems we’ve described in the previous chapter.ĪWS has a tool to calculate the cost of such a move, called the TCO Calculator. This works of course, but it does not scale, it’s not redundant and it will probably cost you more than running your old setup. You run a single EC2 instance (= the AWS equivalent of a virtual server) with your full stack inside of it. In this scenario you re-create your entire server just like you did in the old setup. If you just see AWS as another managed hosting provider you could go for the lift and shift solution. When you move this web server setup to the cloud you can basically do it two ways: the wrong way and the right way. So let’s see now how we can move this setup to AWS, and while doing so, get rid of the problems from the previous paragraph. This is a waste of resources and even worse, your money. Problem 3: The whole setup is constantly running at full power, no matter what load it’s currently having. If you get an unexpected traffic boost, this might cause your server to go down. Problem 2: The CPU/RAM of this server does not scale up or down automatically depending on the server load, there’s always a manual intervention required to make changes to the hardware configuration. If any component crashes, your entire site is offline. Problem 1: There are a lot of single point of failures in this setup: a lot of non-redundant single-instance services are running on the same server. If you use a managed hosting provider you already got rid of being responsible for the hardware, but you still run the same kind of static server setup that you would have if you did it yourself. Making changes to this setup is hard and keeping the setup in sync with your development stack is probably even harder (even when you use Docker). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |