Learn what elasticity and high availability means in for applications deployed on AWS.
- [Instructor] As we get started learning about high availability and elasticity on Amazon Web Services, let's consider even higher up. What is DevOps? DevOps is a set of patterns and practices that keeps systems running. And how does this relate to our topic? If we think about high availability and elasticity, we usually hear about these things when they're not working. So, in other words, the website's not available. Why isn't it working? The website is returning pages to the users with too much time, it's slow.
Another aspect of this that we need to consider is how much are we paying Amazon for our service costs? Are we getting the shock bill at the end of the month, with service costs that we didn't anticipate? These are all parts of what we're going to examine in this course. We're going to go down a journey which is going to result in high availability, elasticity, and costs being done right. And when they're done right, they're nearly invisible. The website just works. It's not down. It works quickly and in a way that the user would expect, and for the business, costs are predictable.
One of the key aspects of achieving high availability and elasticity on Amazon I found as a practice in cloud architect, is simplicity in design. So another aspect of this course is going to be taken from my real world experience helping clients to build, in the most simple and effective way possible, solutions on the Amazon ecosystem that deliver these abilities. So, what point in your application design should you think about and start implementing high availability and elasticity? This is a difficult problem.
I work with a lot of development teams who are very anxious to build features and ship features and not very interested in some of these abilities. They then build the features, hand off their working code to the DevOps teams, who sometimes can be frustrated because there's a disconnect, often times in the real world, between developers and DevOps teams around implementing these availabilities. A tip from the real world is to physically have these teams sit and work together, and during the later phases of the development, to actually start building out high availability and elasticity based solutions and testing them, so that when they're rolled into production, you can have practice in working with them, and more predictability around the effectiveness and the cost.
This is a tricky situation to implement though because as you're implementing high availability, you're often implementing redundancy. AWS service costs, of course, increase when you use more services. So, it's a sliding scale, if you will, in the real world. And my takeaway tip is to start during the later phases of the design portion of your application development. Don't wait until deployment. This oftentimes doesn't happen. Another consideration when looking at implementing high availability and elasticity for Amazon based applications is looking through the layers of the application.
Of course, we're running on the Amazon Cloud, which is running on the public Internet. In this course, we're not going to be focusing too much on Internet layer monitoring. We're going to instead look at user interface and service layers.
- Simplifying HA with services
- Metrics, tools, and levels of monitoring
- Self-healing architectures
- Scaling S3, EC2, ECS, Lambda, ElastiCache, and more
- Script and code tools
- Setting up the AWS CLI and SDK
- Using third-party tools