Defining application areas and AWS services - Amazon Web Services (AWS) Tutorial

- [Narrator] As we get started, looking at individual Amazon services, I pulled a grid together to focus us. So, we're going to look at availability and elasticity for services grouped by application area. So, front end, middle tier, and data and files. And we're going to look at the most common services. Of course, Amazon has over 50 services as of this recording, so the class would be too long if I went through all of them. And then we're going to focus on this new application architecture of whether or not the Amazon service is implemented with a server, a virtual server, or not. So, on the front end, we're going to look at EC2 and Beanstalk which have servers. Beanstalk is either with virtual machines or containers. For the middle tier, we're going to look at either EC2 Beanstalk and or Lambda which is a serverless. So, those can be either front end or middle tier. Purely on the front end, we're going to look at CloudFront and ElastiCache and CloudFront does not have servers and ElastiCache does. In the middle tier, I just pulled out one of the services I use most often which is Kinesis so the data pipeline that does not have servers. And in data and files, again, one from each side. So, RDS, Redshift, EMR, I'll probably just look at RDS because the pattern's the same for all three. They do have servers and S3 and DynamoDB do not have servers. So, as we go through the services, you'll see these patterns emerge as I work with both availability and elasticity. Speaking of patterns, you want to pay attention to if we're working with availability for servers generally to have higher availability, we're going to start by adding more server instances in multiple availability zones. You may remember from an earlier discussion that Amazon has it's services and servers in regions which contain availability zones. So, that's a first pattern, of course, we could then extend that to multiple regions. If the service is serverless, the pattern is to add instances of the service in new regions rather than availability zones for high availabilities. So, it's a different pattern and I just wanted to, you know, call this out before we drilled into the specifics. For elasticity, again, we have two different patterns. If it's servers to utilize elasticity, we want to add or reduce the number of server instances. If it's serverless, we're going to resize the service instance resources. Let me put some specifics to that. So, servers would be the count of servers. So, if you had virtual machines and if you had five, maybe you'll have six. If you have serverless, let's say Lambda, it could be the amount of memory being allocated for the particular Lambda and the number of Lambdas is actually something that you would not have to deal with. Amazon would scale that automatically which is a really important aspect of working with a new serverless services that Amazon has and reduce your management costs around both availability and elasticity. Because this is an intermediate level course, I do assume that you have some experience working with these services for your production applications so I'm not going to spend a lot of time going through the detail of how you setup, from a basic standpoint, the various services. I'm going to use a number of different methods just as I commonly would at work. Sometimes I'll use the Console, so I'll click to create a service. Sometimes I'll use a script, I'll probably will use CloudFormation rather than just the CLI because CloudFormation, as you'll see in a minute, is an integrated scripting tool and it creates what are called stacks. So, it's a combination of the CLI and other scripting components and it allows you to setup multiple services more quickly. So, if you're not familiar with CloudFormation it's kind of a side benefit of working through this course. Not yet at this point but later in the course, we will look at the SDK as well. Just for completeness and how to write code for scaling and availability.