Hi, welcome to the session on growing your company with AWS Container Services. My name is Mesaido Kasingh and I'm a developer advocate with the ECS service team. Before we start, I would like to give you an idea of what a developer advocate does with inside a service team. We work closely with product managers and system engineers in the team to help them understand and collect the signals and trends from our customers based on your feedback and help us all improve our products. Instead of going through architectural details and how things work under the covers, you'll see some of that. Don't worry. I decided to do today something different. We're going to go through the story of an imaginary company which is based on the stories of many real world scenarios and customers. The names of course are not real, but the actual use case is they are an early stage startup and we are going to company them on their journey from the early stages. As they continue to grow from were, we'll jump over to a demo of how they deploy the solution. Last but not least, we'll also see how they continue to evolve over time, how their priorities changed, and how they utilized the continues services within AWS in order to allow growth and handle complexity. So welcome to any company. Any company has a brand new product, something new in tech that will enable you to bring any product from any industry to market in less than eight weeks. They do this by streamlining the process, fully automated, allow you to upload a few artifacts and they will take care of the rest of everything for you. Marketing channels, advertising, partnership, press releases everything will be done from a to z. Automated managed AWS a service Scott, the founder of any company, wanted to solve a personal pain point that he had with his previous companies that he started. Launching a product is hard. It has a number of moving parts, relationships that need to be formed and coordinated, hiring multiple people to track the whole process. And in his experience, it never ever went smoothly. There were always hiccups along the way, things that were forgotten, things that he wished that they'd done better. So he was thinking, why not create a service that will take you through all the checkboxes and manage it for you? That is what brought Scott to any company's mission statement. Any company is a small startup in the early stages. They're just getting started. Meet Scott, the CEO. He's also the chief marketing officer. He's trying to raise funding, create a company at the same time. And he lives more in the air, in hotels than he usually does at home. Diane's the CTO, the technical visionary for the company. She came up with the technology and process to make the product possible. Alice is the vp of engineering. She's a coder at heart, hands on, and also has great leadership skills that will grow the company. So as founders do, they got together and made a strategy for the first six months of the company. And these are the bullet points that they came up with. Most important things they needed to do. The first thing they needed to do was create a web presence. They needed to get the word out to the world about their new technology and a new service. Of course, they need to find customers, build a product, and build a company in the background. But the most important thing was to build a web presence as soon as possible and as quick as possible. So Alice took on the responsibility for getting the website up and running. She has previous experience with containers and knows that the technology is sound and it will allow them to grow in the future. She does not really want to have any time to maintain the infrastructure underneath that runs the website. And she wants something that is fire and forget. The product is going to be awesome, of course. So it will need to handle significant load and Alice does not want to have to do that on her own. And the most important thing as a developer, git flow for life. So Alice was started to look for a suitable service that would search her needs. She contacted the AWS account team and they decided together to go with AWS apprunner. Let's have a look what apprunner is. So at the top here is the customer's application coming out of a container registry like ECR public or ECR private in your account or source code repository. For example, GitHub. Sitting underneath that is apprunner. We have a front end API, a very familiar AWS oriented API that you are accustomed to working with, along with a very robust AWS console experience. We've invested heavily from the user experience perspective into designing a service that takes the different areas of the AWS console and folds them into one easy to use product. Everything you see in the console is also backed by the front end API. That also allows you to interact directly with the service programmatically. Underneath is the orchestration workflow. That's what's handling the end to end story that takes you from a git push all the way into a running application deployed on the AWS cloud. With apprunner, there are a variety of these components that you do not need to manage. A build system, pipeline, load balancers. All of those are set up automatically for you. AWS also sets up and handles the author scaling of the application based on the number of requests apprunner is still a fairly new service, but the building blocks and the shoulders on which it is standing are very, very tried and tested. App runner is built on these mature services that we've encapsulated together into one simple service. And by leaving the undifferentiated heavy lifting to us, you don't need deep AWS domain knowledge to get up and running and be successful with your application. Apprunner is suitable for many types of applications. Were are the characteristics that we see most of our customers using for apprunner applications, web applications and rest APIs that serve HTTP requests. Also, these applications are stateless. They store their information in an external data store, for example DynamoDB RDS. And these applications are long running applications that can serve many requests, sometimes simultaneously. In order to handle load, let's have a look at the user experience in apprunner. Developer writes the code in their ide and pushes it to a source code repo, for example GitHub. Or they can create a docker image and upload it to their ECR repository. They then create an apprunner service which has a number of configurations, the build and runtime compute resources, a health check to know that tour application is actually working, auto scaling parameters and the deployment details. All that information is then used to provide you a customizable public secure URL with which you can access your application. So let's have a look what happens when you deploy an app runner services. Your application is deployed in an AWS managed VPC where your application is taken and packaged as a container and deployed on a fargate task running in that VPC in multiple subnets. Your customers, when they access the application, will make a DNS request to route 53 where they will receive an FQDN which is pointing to the service URL which is actually a network load balancer. They will make the HTTP request to the load balancer. From there they will be forwarded to a managed router inside the app runner service, and each of those requests will be forwarded to each one of your containers based on the number of containers running, just so that you know, apprunner can also scale down to zero, which means that if there are no requests coming into your application, you will not be paying for any of the requests coming in and you'll be able to save and optimize your costs from there. Any application which needs to make a request out to the Internet, for example to pull down dependencies in the application or modules, or any other kind of code will go through the managed. Net gateway out to the Internet in order to pull those dependencies down into the application itself. Time for a demo. Let's go through a scenario that people in any company would go through in order to deploy their application. So first things we're going to start with is of course shell, because there's no other reason why not to. And here we have simple git repository where sorry, not a git repository show where alice decided okay, I have an idea what I would like to do. I've got some kind of a boilerplate template or boilerplate design where I would like to base my website upon. She found something on git, cloned it to her repository, to her local machine, and for the purposes of this demo I created a script which will do a couple of things to make the flow of the demo tiny bit easier. What this does will make a couple of files, but in the meantime just going to download the file were to this repository and the repository is simple, is a node JS application. All I did was added the demo bash script. I'm going to run the script at the moment. What it will do will create a few files for me in this repository, in this repo, so that I can make my work a little easier. A docker ignore file docker file a build script, a customized script just to save time. Standard default, not a JS application which will create a static website. So I'm going to run my build script which will build a docker container for me. Also in the interest of saving time, this build script is going to go and build my container locally, but also above and beyond that. It's going to push it to an ECR private repository which I've already configured with my account. So I'll be able to use that same docker image further along the way. It's going to also add two tags to the same image as well, one with latest and one with a timestamp based on the amount of the specific date and time that I'm working on. Takes a couple of seconds for this to work completely building the image. Now it's pushing, as we say to my repository in my AWS account because I've already pre populated the image, or at least part of it with of the image into my repo is going a little bit quicker. Some of the layers are already there and it pushes the second one of the same with a different tag does it a very quick push and my image is roundy is ready. I'm going to run this locally on my machine because I want to see how this actually looks? So I'll run it with a port 3000, open up my own browser and look at localhost 3000 to see exactly what this looked like. So, boilerplate website with some kind of design. It has a video file and some animations going on in between. Looks pretty professional. Everything which was done with the default template was the name of Elementor, was the name of this website, and it looks like a good base which I can start upon, but I want to make some changes because it has to be suitable for any company, of course, for my website, for my company. So builds a script which will go in and modify this boilerplate website with a number of customizations. Mostly in this case it's going to be replacing anywhere where it says Elementor, almost anywhere where it says elementor into any company you can see. Made a number of changes in my repo, in my files, and I'm going to build a new container based on these changes. So it goes through the process again using of course docker caching. It should be a little bit quicker the second time when I'm doing it. Once the image is built again, push it to my ECR repository again with minimal changes. Most of the layers are already there so it should be pretty quick. And the second push is just to add a new tag which will be even quicker. And Alice says okay, I want to just see exactly what it looks like and see if my changes were all right. And aws we had originally the previous version of the website with the video animation. And after refreshing you can see these things have changed. Any company has been replaced, has replaced all the text were it's at elementor, that video is no longer there. All the customizations I made any company is more looking something which is more suitable for my personal website and the website for the company. So it looks there are a couple of things which didn't replace properly because they're graphic elements, which of course Alice would be able to do properly when she works in more detail on making the website 100% presentable for the rest of the world. So Alice has her container which is ran locally on a machine, but now she wants to take that same container, same application she wrote, and push it into apronaut so it will be accessible from the rest of the world. So let's go to the apparatus console were I already have an any company web service which has been running built in the background which is watching a git repo or an ECR repository in this case to make changes based on every new push so as soon as I pushed my previous versions and I was pushing them, up until now it has been making those changes and deploying a new version for my service. But let's go through how we would create a new service. So as we said, you can have either a container registry AWS, your source, or a source code repository, for example GitHub, where you would create a connection to GitHub. Choose your GitHub repo, which branch you would like to work off. In this case, I'm going to be working off the option of a container registry where I can choose either ECR public or ECR private. I'm going to choose my repository where I have this container called Summit demo with a tag which I've tagged it, and every time this tag is updated, a new build will occur. I have the options of choosing how I would like my deployments to work, either on a manual. In other words, I would initiate these deployments in a manual fashion or automatically. If there would be a new push to the GitHub repository or the ECR repo a new version, then a new build will kick off and start. You have to give the service a iem role so it will allow it access to pull the ECR, the docker image from the ECR. And here we configure the service and give a number of different options as well. Choose the amount of cpu and memory that I'm giving the service, which port it's listening on, and how I configure. Auto scaling auto scaling is done by the user configuring how many requests their application will be able to handle, and as soon as it goes over the number of requests, concurrent requests to that Docker container, it will scale up and bring up a new node. When the number of requests diminishes, then it will go back down and scale those containers down. You can create your own custom configuration. In this case, I'm going to use the defaults. I can continue a health check to know that my application is up and running properly. I also can add an IEM role to the container itself. If I wanted to perform actions on my behalf into the APIs of AWS, I can configure what kind of encryption I would like if it's an AWS owned key, or my own key if I would like to provide it as well. The next option is networking. If I would like this application to have access to resources in my own private VPC, I would choose custom VPC. If I only want access or access into the container and without having that container or the application have access into my own resources, I would choose public for this case. For the website we are going to choose public, click next and deploy as we said console that you all know and recognize different tabs. For example, the activity tab will give me what's happening with my service and all the different actions which are currently occurring or have occurred in the past. The metrics will give me the service metrics of the container, how it's performing. This will give me a summary of my configuration and I can change it. And over here I have the option of configuring a custom domain. By default every service is provisioned with a region awsaprunner.com fqdn but of course for each of tour customers custom applications they would like to have a more recognizable and usable name. So you can link a route 53 hosted zone to the service and create a AE record or a CNamE record that will be able to attach and link to this apprunner service. So your users and your clients will be able to access through a generic or your own private FQDN instead of having coming through the apprunner domain names in FQDNs. If we quickly jump into the previous one, you'll see this is what the event log looks like. It gives me a status of how what everything is happening when we deploy applications in apprunner and update those applications. There's a pipeline in the background which deploys a new version in a blue green deployment so you do not suffer any downtime when you update your applications and only when your application has been tested and verified based on your health checks that everything is up and running, it will switch to a new version. That is why you can see that in my case I'm still using a previous version of my application which hasn't got the updates for any company in the customization because the process is not completed of deploying a new version yet and therefore I'm still running my old version where my first push of my docker container when I started this demo only had these original or the same default template which I was using. That's how you use apprunner. Thank you very much for watching this demo and let's go back to the rest of the presentation. So let's continue with any company's journey. They're growing at an insane rate and six months have gone by and of course AWS all founders do they have another meeting to understand were they want to go with the next six to 18 months and they came up with these three bullet points that they need to build a product as fast as possible with minimal maintenance. They need to bring revenue into the company and of course they need to gain market share, which means customers. So over the past six months, the company of course has grown. Instead of the three people which were doing everything from running around finding customers to developing a website, they have expanded. So instead of having one person doing everything, they now have teams underneath. And most of the employees are now working on creating a product under Alice, who is the vp of engineering, who still likes to code, of course, by the way. So they said, alice, can you build us a product? That's of course what she was hired for. But the requirements stayed pretty much the same, except for two things which were added to the end. The product has to be of course secure because they don't want to lose any customers because of a security breach or information leaking or landing up on the front page of the New York Times by any chance because they didn't guard their customer PII. And the second thing, of course, it's not only going to be a website that they built up until now using apprunner, because there is going to be information and data and things which they need to store and they need to be stored in place where that can be accessed on a regular basis, can be used in different ways. So these two different extra points on the requirements were added and let's see what Alice did. So Alice reached out to her account team, spoke to the solutions architect in AWS, and asked, what can we use, which is similar to the way we're working now. And after looking through a number of services, they decided to work on ECS. Amazon Elastic container Services what is ECS? ECS is a fully managed control plane and AWS. Fargate is a fully managed data plane. That means it is the compute that runs the containers that you provide for your applications. Customers don't need to maintain any Amis or container host clusters. It's a big and huge operational savings. Because everything is managed by AWS. It's easy to scale to ensure better utilization and cost savings. And of course even further and above and beyond that, you can use Fargate spot and savings plans to provide you further saving options in your account and your applications. The core concepts of ecs are really simple, but really, really powerful. A task consists of one or more containers. This is your application that you're running. You can run these tasks on an EC two instance or a Fargate instance. And you can also use, of course in order to save money. The spot variants of those either EC two spot or Fargate spot. Multiple identical tasks create a service tasks in a service can be connected to a load balancer, which is automatically done by ecs and groups of services and tasks are located in one single cluster. Customers can create many clusters mapped to teams and workloads. A cluster is simply a logical grouping. Any company is leveraging the newly released VPC support for Avroner to access resources that reside in their VPC. This ensures that the private information in their databases is not accessible from the public Internet, which meets the requirement of security. How is this connected to ECS? Besides the fact that appraunner uses AWS Fargate for running the tasks in the background, these other background tasks that they will be starting will be pulling the information that is collected through a front end application that is running on apprunner, pushed into an RDS database, and based on which is stored inside that database, they'll be able to provide business insight into their customers and the way they're using their products. So what did we see here today? We saw an example of a company by the name of any company was actually not really real, but could be your company or mine. Makes no difference. They managed to deploy their resources, meet the requirements in a very, very simple and easy way, the way they used to working in the AWS cloud and above and beyond that allowed them to grow further as their business grew, as they collected more customers and more market share. The second thing we touched today was serverless containers, which we by that I mean Fargate and apprunner, where you provide the container image and the configuration that goes along with it. And you do not need to manage any of the underlying infrastructure underneath in order to run the container. All of that is managed and taken care of by AWS in the cloud. So before I leave you to go into your next session, I want you to put here two links to different resources that you can dive deep into. I kind of geek out on the details of how things actually work and these two blog posts will be able to give you a lot more information, a lot more insight into how both Fargate and how apprunner works underneath, and how they can bring benefit to you. Thank you very much for your time. I hope you enjoyed the session and hope you learned something new about running containers on AWS and how you can benefit from the services which we have offering you today. My name is Mesaido. Casing. My emails here are up on the screen. The easiest way to get hold of me is to ping me on Twitter. My dms are open. Anything you would like to discuss. I'm always happy to hear from our customers. Thank you very much for your time and have a great day.