When you build and run applications in the cloud, how often are you asking yourself “am I doing this right” ?
This is actually a very good question, and to let you get a good answer, we released publicly in 2015 the AWS Well-Architected Framework, a formal approach to compare your workload against our best practices, and get guidance on how to improve. Today, the Well-Architected Framework gives a consistent way for customers and partners to design and evaluate cloud architectures, and is based on five pillars:
To provide more workload-specific advice, in 2017 we extended the framework with the concept of “lens” to go beyond a general perspective, and enter specific technology domains. Currently, there are three lenses that you can use:
The first thing to do to improve something, is decide what to measure and how. To let you review your workloads in a more structured way, we launched in 2018 the AWS Well-Architected Tool, a free tool available in the AWS Management Console, where you can define your workload, and answer questions regarding the five pillars.
You can use the Well-Architected Tool in different ways. For example:
Today, I am happy to announce that we added the ability to apply lenses to the Well-Architected Tool, and the first one to be available is the Serverless Lens!
Using the Serverless Lens in AWS Well-Architected Tool
In the Well-Architected Tool console, I start by defining my workload. I am currently building the backend for a mobile app using the Amplify Framework. It’ll be a simple game, but I am going to use DynamoDB Global Tables to store data for my users, and the application will be running in two AWS Regions. Adding the AWS account IDs is optional, but can be useful to understand the application deployment in a multi-account setup.
Now, I can choose which lenses to apply. The AWS Well-Architected Framework is there by default. I select the Serverless Lens. This is adding a set of additional questions that help me understand how to design, deploy, and architect my serverless app following the framework best practices.
When the workload is defined, I start my review. I jump straight to the Serverless Lens. The new questions are distributed across the five pillars. For example, one of my favorite questions is around performance:
For each question, there are resources on the right side of the console that help me understand the possible answers and the terminology used. I select the activities and the technology choices that are part of my implementation, specifically:
/tmpof the Lambda functions, or external data stores like Amazon ElastiCache.
I save and exit, and even if I answered just one question, I already get some feedback from the tool. From the workload overview, I select the Serverless Lens. There, I notice that I have a high risk that I need to mitigate.
Just below, I have a suggestion on how to address the risk, including specific recommendations based on the question raising the risk. For a serverless application is important to balance performance and costs, using the right capacity unit that is automatically scaled by the platform.
I click on the first recommendation, and I receive specific action items for my improvement plan. This is covering the different architectural components I can use in my serverless apps, such as Lambda functions, DynamoDB tables, or API Gateway endpoints. In my case, I am going to follow the suggestion to use the Lambda Power Tuning open-source tool to fine-tune the memory/power configuration of my Lambda functions.
Before working on my improvement plan, I go on and answer all questions. I can now see the full report in the AWS console, or download it in PDF format to share it with other stakeholders. In this way, we can work together to plan the necessary improvements and have a successful serverless app.
Once we have made the improvements, I can go back and mark the correct answers to remove the high risk issue. Great architectures come as result of multiple iterations.
The Serverless Lens is available today in all regions where the Well-Architected Tool is offered, as described in the AWS Region Table. It can be applied to existing workloads, or used for new workloads you define in the tool.
There is no costs in using the AWS Well-Architected Tool, you can use it to improve the application you are working on, or to get visibility into multiple workloads used by the department or area you are working on.
As a CIO/CTO, you can use it as a dashboard describing the status of all the applications you are responsible for. To make this easier, you can share a workload with another AWS account, that you can use to have a single view across multiple applications.
Since the output of the tool is a report with risks and how to address them, you should use the tool during the overall lifecycle of your application, especially during the design and implementation phase, and not just when you are going in production, because it may be too late to implement some of the suggestions you get.
Source: AWS News