So far we've been looking at services like EC2 and S3 which constitute infrastructure as a service, abbreviated IaaS. Infrastructure as a service means you manage your infrastructure by launching and configuring a fleet of different EC2 instances then run your enterprise applications on top of them. But what if you already built your apps and don't have time to choose and configure your infrastructure? That was the situation I was in when AWIT launched our first Coursera specialization. I built a full stack application with over 200 product management interview questions asked by Amazon, Google, Facebook, and Microsoft. And I wanted Coursera learners anywhere in the world to be able to use it but didn't have the time to provision EC2 servers. So I hosted it on a platform as a service, abbreviated PaaS, which provisioned the right group of AWS resources for my application. AWS offers to platform as a services: Lightsail and Elastic Beanstalk. With Amazon Lightsail you select a blueprint to automatically launch your pre-configured stack to host your application. Here's a list of blueprints I use Node.JS in the top right. But there are other popular blueprints like those for Drupal or WordPress. For the exam, know that Lightsail is the easiest way to deploy a full stack application on AWS. However, it does not automatically scale. Lightsail is a good use case for smaller projects like mine where I simply wanted to serve a dedicated group of Coursera learners without worrying about the general public. By the way, Lightsail's General Manager, George Elissaios has a guest appearance in our first specialization. So if you want to learn more from another General Manager of an AWS service, check out our first specialization on Coursera. The other platform as a service is AWS Elastic Beanstalk. AWS Elastic Beanstalk reads your application's code to determine what resources it needs, then automatically launches those resources with your application. Unlike Lightsail, it is capable of auto scaling. But for the purposes of the exam, it is more complex to use. Somewhat related to platform as a service is containerization. Containerization is the practice of putting every piece of your full stack application into a docker container. When I did this in the past, it was an incredible amount of work. However, in exchange for the upfront work, you get containerized applications that run the same in any environment whether on or off EC2 because every dependency is inside that container. And when you need to scale, your container orchestration service just launches more containers. Container orchestration services monitor whether you need to launch more containers to serve increased demand or shut down your existing ones because there is less demand. And you can conserve your resources and your spend. Orchestration services also perform health checks on individual containers and reboot any that have stopped working. AWS offers to services for container orchestration: ECS and the EKS. Amazon Elastic Container Service, abbreviated ECS, is an orchestrator optimized for the AWS environment. While Amazon Elastic Kubernetes Service, abbreviated EKS, uses the open source Kubernetes orchestrator. You could use Kubernetes if you wanted to orchestrate containers both inside and outside AWS. Now containers still need compute to function. AWS offers two approaches to giving containers that compute the first is to simply run your containers on EC2. This gives you the advantage of configuring your EC2 server fleet, but the responsibility of having to manage and scale that fleet. Alternatively, you could use AWS Fargate, which will automatically scale your EC2 fleet depending on how much compute your containers need. Fargate gives you the advantage of saving time and steps otherwise spent provisioning your EC2 server fleet, but reduces your ability to customize your containers' EC2 instances. Remember for the exam that ECS and EKS orchestrate your containers, whereas EC2 and Fargate run your containers. One customer of EKS is Babylon Health, a digital health company that covers 20 million people. And provides 5000 video medical consultations a day through its mobile app. Babylon Health uses EKS to orchestrate its 300-plus containerized applications. and run them using Fargate. After using AWS container services, they reduced the average time to update their applications from four weeks to several hours. The last AWS container service will cover is Amazon Elastic Container Registry, abbreviated ECR. There are two major uses for container registries. The first is you can download and experiment with containers that other people have built and made public. The second is if you're working on containers and updating your applications inside those containers like Babylon Health does, you can use a container registry to track your updates and potentially revert back to earlier versions. With ECR, you can do both. The final trend in compute we'll discuss are serverless architectures. A serverless architecture is one that provisions servers for you behind the scenes, without you ever having to launch a single EC2 instance. What AWS service do we just talk about that is serverless? If you answered Fargate, good job, you're right. Fargate manages your EC2 fleet for your container workloads without you ever having to launch an EC2 instance. Another service implementation is AWS Lambda, which allows you to run serverless functions. A function is just code. A serverless function runs on a trigger and then it stops. Lambda functions cannot run longer than 15 minutes. When would this short burst of code execution be useful? One way I use it is the program Alexa devices with custom responses. The triggers when I speak a certain phrase to Alexa, Alexa detects that phrase and it triggers the Lambda function to execute, which then tells Alexa what to say back to me. And then the Lambda function stops. One customer of AWS Lambda is square Enix. For its massively multiplayer online role playing game more bigger Dragon Quest X (or maybe it's Dragon Quest 10. I don't play this game.) Specifically, players would take in game screenshots, then wait several hours to receive the screenshot while Square's on-premises servers performed image processing. After migrating their screenshot capability to AWS Lambda, players received their scree shots in 10 seconds. Even during New Year's when they took screenshots at the rate of 6000 per minute. Also, the Lambda reduced their costs of processing these screenshots to one 20th of their original cost.
