AWS Partner Network (APN) Blog
Automating Serverless Best Practices with Dashbird’s Serverless Well-Architected Insights
By Tim Robinson, Principal AWS Well-Architected Geo SA Manager, APAC
By Stephen Salim, AWS Well-Architected Geo SA, APAC
 |
| Dashbird |
 |
Effective use of the AWS Well-Architected Framework educates customers on best practices and how to measure and improve their workloads.
Through iterative use of this review mechanism, technical architects are able to discuss potential issues they find with a workload, which can then be remediated either internally or as a professional services engagement. This can result in improved risk posture, workload performance, and efficiency.
Each AWS Well-Architected review consists of questions that work to teach, measure, and improve customer workloads based on the six pillars of Well-Architected: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability.
Until recently, the AWS Well-Architected Framework has been applied to a variety of customer architectures with a goal to improve their cloud risk posture and align them to best practices.
However, in response to the increased breadth of services offered by Amazon Web Services (AWS), it is now recognized that a customer can benefit from specific alignment to either their architecture or an industry vertical via lenses, which are included within the AWS Well-Architected Tool and include questions applicable to that particular workload.
In this post, we will take you through the use of lenses within the Well-Architected review process and how findings from the Serverless Application Lens can be automated using Dashbird Insights to show misconfigurations and best practice violations in relation to serverless workloads. We will then walk through the deployment of an example serverless application that we’ll profile using Dashbird Insights.
Dashbird is an AWS DevOps Competency Partner which provides an all-in-one tool, purpose-built for providing observability, troubleshooting, recommendations for best practices, and cost breakdown of serverless applications running on the AWS Cloud.
Use of Lenses Within the Well-Architected Review Process
An example of the effective application of a lens would be for a customer who has implemented their workload using serverless technology. In this scenario, conducting a review using the serverless lens can result in greater alignment in terms of questions and advice in-line with the services utilized by the customer.
The customer can also take advantage of the Well-Architected Serverless Application Lens documentation, which covers common serverless application scenarios and identifies key elements to ensure workloads are built according to best practices.
Using Dashbird, customers can achieve a bird’s-eye view of their serverless environments, making troubleshooting issues and performing end-to-end observability possible.
Recently, Dashbird complemented their existing product with the Serverless Well-Architected Insights feature, which provides customers with an efficient method of embracing best practices surrounding the Serverless Application Lens, through the automation of many of the documented best practices.
Automate Improved Efficiency Findings with Dashbird Insights
Dashbird’s Serverless Well-Architected Insights feature provides customers with continuous findings aligned with the Well-Architected serverless lens. Through the use of the insights facility, serverless developers are provided with recommendations to continually improve their security compliance, performance reliability, and cost optimization.
All findings are displayed in a single pane of glass report, detecting misconfigurations, best practice violations, and problematic resources across AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon Elastic Container Service (Amazon ECS), AWS Step Functions, Amazon Simple Queue Service (SQS), and Amazon Kinesis Data Streams.
For each detected insight, the user is presented with an explanation of the issue, together with a step-by-step guide to troubleshooting.
For this post, we have put together a sample application which you can deploy to show how Dashbird’s Serverless Well-Architected Insights feature can be used to detect issues during a Well-Architected serverless lens review and assist you with associated resolution of high risk issues.
Our sample application deploys a web-based application called “BLUE CAR remote healthcare.” It models a remote healthcare service which allows a customer to request a self-driving healthcare vehicle from any location in the world. A user can log into the platform, place an anchor point in the map, and request a remote healthcare vehicle (aka BLUE CAR) that will animate towards the anchor point location.
Figure 1 – Blue Car app screenshot.
This application is adapted from WildRydes sample code that you can find in the AWS Serverless Workshops site and is built using services such as Amazon API Gateway, AWS Lambda, Amazon DynamoDB, and AWS X-Ray. Through the use of these correctly configured services, the platform can scale automatically in-line with demand, without the need for static compute resources.
To help you deploy this sample application, we have created a build script you can run from the AWS Cloud9 integrated development environment (IDE) in your AWS account. The script will build and deploy the web app using serverless resources as shown below.
For details on how to deploy this sample application, follow the steps in the AWS Well-Architected labs.
Figure 2 – Application architecture.
Once the application is deployed, you can leverage Dashbird Well-Architected Insights to detect any issue or configurations that may require alignments with AWS Well-Architected best practices.
Dashbird Well-Architected Insights provides a single pane of glass location to visualize all insights detected in your workload. Each insight is aligned to one of the pillars within AWS Well-Architected Framework.
To gain access to this capability, you’ll need to establish a connection between your AWS account with the Dashbird platform. You can follow the steps in the labs to do so.
Dashbird provides continuous insights on the state of your serverless workload aligned with the Well-Architected serverless lens. This means as soon as a certain state or issue occurs, the platform generates insight items which can be used as part of your troubleshooting investigation. As you can see from the diagram below, insights are grouped per pillar and can be viewed per region and per service.
Figure 3 – Dasihbird.io insights dashboard.
The AWS lab will take you through a modern load test within the BLUE CAR example application. In addition, we show you how to use artillery.io to generate large amounts of request data which we’ll use as a sample load within our application.
When the request load is generated, you’ll see an insight in the Dashbird Well-Architected Insights console (highlighted in red below), called “Lambda function has high error percentage.” This indicates more than 5% of the function invocation has failed and further investigation is required. More information about this insight can be found in the Dashbird documentation.
Figure 4 – Dasihbird.io insights resource.
Diving deeper into the Well-Architected Insight shows the task is timing out after three seconds. This means the Lambda function took longer than the allowed time to run in the function configuration. In a real-world scenario, this usually means the Lambda function requires more memory allocation in order to process things faster. Refer to the documentation to decide what the appropriate memory allocation is for your function.
A deeper investigation into the memory utilization within Dashbird’s insights product indicates the Lambda function is actually not the bottleneck of the issue. Therefore, further investigation within the application stack is needed.
Figure 5 – Dasihbird.io insights details.
Clicking the AWS icon in the Trace section redirects you to the AWS X-Ray console that shows which endpoints the Lambda function interacts with. This allows you to isolate the service which is causing a bottleneck. In our example, the DynamoDB table which the Lambda function writes to is being throttled.
Figure 6 – AWS X-Ray trace.
From this point, users can take the appropriate remediation action, which in our example is to enable auto scaling capability in the DynamoDB table. The inclusion of auto scaling within the DynamoDB configuration allows the database to scale according to demand, removing the need to guess capacity.
Figure 7 – DynamoDB Table configuration.
Customer Case Study: Clarus
Clarus provides automated communication tools to physician practices throughout the United States. Founded in 2013, the company specializes in automating physician practice call management through simple-to-use technology, eliminating the errors and inefficiencies of traditional call centers.
The business has grown exponentially over the past few years and is now responsible for servicing approximately nine million call requests annually. Clarus’s engineering team has transformed the company from traditional server-based infrastructure to a fully-automated serverless organization.
“We needed to find a technology approach that aligned with our business model,” says the Clarus team. “Clarus provides a mission-critical service that must be reliable regardless of the call volume flowing through the system, including large surges. Going serverless allowed us to do precisely that.”
Clarus has seen a significant increase in call volume it manages due to the pandemic. Fortunately, due to its decision to transition to serverless architecture, the business has seen a reduction in costs despite an increase in both customers and associated call volumes.
“Since the COVID-19 pandemic, we have seen our call volumes almost double. However, we also migrated our workloads to serverless architecture at the same time,” says Clarus. “As a result, we are only using resources when we need them and have capitalized on this from a cost perspective. Our migration to serverless architecture has resulted in a cost reduction.”
As the company has decided to run its mission-critical workloads using serverless technology, the ability to monitor and observe workloads in near real-time becomes increasingly important.
“We invested a large amount of effort to ensure that our transition to serverless architecture was both seamless and scalable,” says Clarus. “The Well-Architected lens documentation proved invaluable in making this a reality and confidence that we were building in the right way.
“We needed a methodology to monitor our environment at a high level while receiving the maximum amount of information possible. Dashbird offered us all of this, providing a high degree of visibility across our workloads.
“We also use Dashbird when we introduce a new AWS service to detect anomalies and provide an immediate response.” adds Clarus. “We have recently used it to identify Lambda cold starts and integrated it with X-Ray to identify why this was occurring. This provided us with immediate visibility and reporting on anomalies within our architecture.”
Conclusion
Lenses extend the guidance offered by AWS Well-Architected to specific industry and technology domains, such as serverless applications. Customers can use applicable lenses together with the AWS Well-Architected Framework and the six pillars to ensure they are building in alignment with best practices.
Through the use of developer tools such as Dashbird, it’s possible to automate a lot of the best practice checks which the lenses reference to provide a continuous compliance approach to best practice aligned with a serverless review.
To learn more, please check out the AWS serverless best practices lab with the Well-Architected lens documentation and Dashbird Blog, which includes articles on best practices for building serverless application workloads at scale.
About AWS Well-Architected
AWS Well-Architected is a set of guiding design principles developed by AWS to help organizations build secure, high-performing, resilient, and efficient infrastructure for a variety of applications and workloads.
Use the AWS Well-Architected Tool to review your workloads periodically to address important design considerations and ensure they follow best practices and guidance of the AWS Well-Architected Framework. For follow-up questions or comments, join our growing community on AWS re:Post.
.
.
Dashbird – AWS Partner Spotlight
Dashbird is an AWS Competency Partner which provides an all-in-one tool, purpose-built for providing observability, troubleshooting, recommendations for best practices, and cost breakdown of serverless applications running on AWS.