- [Morgan] Nice work getting through this course. Let's take a look at how the architecture you built turned out. The employee directory application is currently being hosted across multiple EC2 instances inside of a VPC in private subnets. The EC2 instances are part of an EC2 auto scaling group and traffic is being distributed across them using an Application Load Balancer. The database is being hosted on Amazon DynamoDB and the images are stored in S3. Beautiful. Looking at this from a maintenance perspective, you would need to ensure that your autoscaling policies are working well with your expectations. And it would likely take some amount of tweaking over time to get it right. You also would need to install any security patches and updates for EC2 as they come out, as well as keep an eye out for new instance sizes and types that might help you further optimize your solution. Now, this is really a great solution, but as with everything built on AWS, there are multiple ways you can architect a solution and have success. It really depends on what you are optimizing for and what you are trying to do that will determine how you architect an application. That being said, what I want to do now is present you with an architecture that could be a wonderful serverless redesign of the employee directory application, taking full advantage of cloud-native services like AWS Lambda. I'm going to touch on some services we haven't covered in this course also to give you ideas of alternative architectures. So this employee directory application is a great example of a standard three tier application, where you have the presentation layer, the application layer, and the data layer. The presentation layer is the user interface, the application layer is the business logic, and the data layer is the database. As things are right now, the Amazon EC2 instances are hosting both the presentation layer as well as the application layer. This is true because the EC2 instances have a web server running that is serving the content for the website, like the HTML, CSS, and the JavaScript, which is the presentation layer. Then, the same instances are also handling requests for the backend logic for viewing, adding, updating, and deleting employees, which is the application layer. What I want to do now is separate these two pieces entirely, having the front end of the website hosted separately from the backend application logic. It's important to separate the presentation layer from the application layer so that the instances are not overloaded by handling different types of requests at the same time. We are going to move the presentation layer to be hosted on Amazon S3. S3 supports static website hosting and therefore, this is a great place for us to host the HTML, CSS, and JavaScript for our website. When you're hosting a static website with S3, you may think, "Well, my website isn't static, it's dynamic. It's pulling data from a database. So this isn't a static website and therefore S3 wouldn't work for this use case." This is where JavaScript comes in. JavaScript files and scripts have the ability to make HTTP requests and load dynamic content, modifying the static page to display results that come back from the requests. So this should work well for us. The presentation layer is taken care of now on Amazon S3. Now what I want to tackle is the application layer. It used to be hosted on Amazon EC2, but let's go ahead and change this to AWS Lambda. This means that our employee directory application code would only be run in response to events being triggered by the front end presentation layer. Now you don't really want your front end talking directly to your backend code. So instead you would expose your backend Lambda functions using an API. We would use the service, Amazon API Gateway, to host this API. Each action that you could take on an employee would have its own method on the API. This API, hosted on API Gateway, would act as the front door to trigger the backend code, which we host on AWS Lambda, instead of EC2, as discussed. We could have one Lambda function to handle all of the requests for employee data or we could have one Lambda function per each action that you can take. We would keep DynamoDB for the database or the data layer and we would also keep S3 for the employee photo storage. All of the access between these services will be handled via role-based access using IAM roles. One really nice thing about this is notice how, because we built the solution in a more modular way, we were able to swap out how we were handling the presentation and application layer while leaving the data layer totally intact with no modifications. That is the type of flexibility that can help you innovate and adapt to change quickly. So now for completeness and clarity, let's focus on the new architecture and fill it out a bit more. I will add some other AWS services to this diagram that you can explore on your own. I'm going to add Amazon Route 53 for domain name management for our website. And I'm also going to add Amazon CloudFront here as well, which will allow us to cache the static assets, like the HTML, CSS, and JavaScript, closer to our end users by taking advantage of the AWS global infrastructure's AWS edge locations. If a user wants to visit the employee directory application website and view all of the employees, here is the flow. The user would first type in the domain for the website, which would get sent to Amazon Route 53. Route 53 would then send back to the client the address of the static website being hosted on S3. And then S3 would send back the content to be rendered in the browser. This website has JavaScript making the API calls to the backend to load the dynamic content. So the API call to load all the employees would be made and it would hit API Gateway first. API Gateway would validate the request and then trigger the backend Lambda function. The Lambda function would then send an API call to DynamoDB to query the employees in the table. And then it would then return that data to API Gateway, which would then be returned to the JavaScript, which finally would be rendered on the page. All right. And that's that. With this architecture we just laid out, we have optimized for scalability, operational overhead, and depending on your usage, it could also already be optimized for cost. The serverless aspects of this make the operations for support much less than compared with Amazon EC2-based solutions. There is no patching or AMI management when you use serverless solutions like AWS Lambda. Also notice how it was not required that I create a VPC, subnets, security groups, or a network access control list for this solution. The networking aspect of this is managed for you, though you can integrate serverless services with your VPC if you need to for compliance reasons. However, it's not required to get a solution up and running. You have many options to choose from when designing your application. You can imagine a scenario where you redesign the same application to be hosted using AWS container services. And then this entire diagram would change. There are a lot of ways you can build on AWS and that's really the beauty of it. You can swap certain pieces of your solution out as AWS services are released or gain new features. And because everything in AWS is an API call, you can automate the process along the way. That's it for this course. From me, Alana, Meowzy and Kiwi, thank you so much for learning with us. Please remember to check the course notes after the video for links to other courses where you can learn more about the AWS cloud. Also, one more reminder to please, please, please remember to delete any resources you created in your AWS account for this class to avoid incurring costs. Thanks again. And we'll see you next time.
