Building Well-Architected Serverless Applications: Managing the Application Lifecycle – Part 3 | Amazon VGT2 Las Vegas

More Info

In Amazon API Gateway, Amazon Simple Notification Service (SNS), AWS Amplify, AWS CloudFormation, AWS CodeBuild, AWS CodeCommit, AWS CodeDeploy, AWS CodePipeline, AWS Config, AWS Lambda, AWS Personal Health Dashboard, AWS Serverless Application Model, AWS Systems Manager, AWS Well-Architected Tool, Serverless

This series of articles leverages the AWS Well-Architected Tool alongside the Serverless Lens to assist users in constructing and managing applications rooted in best practices. Each entry addresses the nine serverless-specific inquiries highlighted by the Serverless Lens and their associated recommended practices. For a detailed overview, see the introductory post for a comprehensive table of contents and an explanation of the example application.

Question OPS2: How do you approach application lifecycle management?

In this section, we continue from part 2 of the Operational Excellence question, focusing on deployment to multiple stages utilizing temporary environments and rollout strategies. Part 1 discusses employing infrastructure as code with version control to ensure consistent application deployment.

Best Practice: Implement Configuration Management

Utilize environment variables and configuration management systems to implement and track configuration changes. These systems minimize errors that arise from manual processes, reduce the effort required for deployment, and separate configuration from business logic.

Environment variables are appropriate for rarely changing configuration settings, such as logging levels and database connection strings. On the other hand, configuration management systems are designed for dynamic configurations that may change frequently or include sensitive data, like secrets.

Environment Variables

The serverless airline example referenced throughout this series uses AWS Amplify Console environment variables to manage application-wide settings. For instance, Stripe payment keys for all branches and names of individual branches are stored in the Amplify Console within the Environment variables section.

For AWS Lambda, environment variables are configured as part of the function settings stored with the AWS Serverless Application Model (AWS SAM). For example, the AWS SAM template for the airline booking ReserveBooking function includes global environment variables such as LOG_LEVEL, as shown in the code snippet below:

Globals:
  Function:
    Environment:
      Variables:
        LOG_LEVEL: INFO

This information is accessible in the AWS Lambda console under the function configuration.

For further details on using AWS Lambda environment variables and storing sensitive data, check out this excellent resource: Fast Company.

Dynamic Configuration

Dynamic configurations are also managed in configuration management systems to specify external values unique to each environment. This may include values like an Amazon Simple Notification Service (Amazon SNS) topic, Lambda function names, or external API credentials. AWS Systems Manager Parameter Store, AWS Secrets Manager, and AWS AppConfig have built-in integrations with AWS CloudFormation for storing dynamic configurations. Visit this blog post for more examples on referencing dynamic configurations within AWS CloudFormation.

In the serverless airline application, dynamic configurations are maintained in AWS Systems Manager Parameter Store. During the deployment of CloudFormation stacks, various parameters are stored here. For instance, in the booking service’s AWS SAM template, the ARN for the booking SNS topic is stored as follows:

BookingTopicParameter:
  Type: "AWS::SSM::Parameter"
  Properties:
    Name: !Sub /${Stage}/service/booking/messaging/bookingTopic
    Description: Booking SNS Topic ARN
    Type: String
    Value: !Ref BookingTopic

To view the stored SNS topic value, navigate to the Parameter Store console and search for BookingTopic.

The loyalty service then accesses this value within another stack. When the Amplify Console Makefile deploys the loyalty service, it retrieves the booking service value from Parameter Store and uses it as a parameter override. The deployment process can also be parameterized using the ${AWS_BRANCH} environment variable to cater to multiple environments within the same AWS account and region.

sam deploy 
  --parameter-overrides 
  BookingSNSTopic=/$${AWS_BRANCH}/service/booking/messaging/bookingTopic

Environment variables and configuration management systems are vital for efficient application configuration management.

Improvement Plan Summary

• Utilize environment variables for infrequently changing configuration options like logging levels and database connection strings.
• Adopt a configuration management system for dynamic configurations that may change frequently or contain sensitive data.

Best Practice: Implement CI/CD with Automated Testing Across Different Accounts

Continuous Integration/Continuous Delivery/Continuous Deployment (CI/CD) is a cornerstone of cloud application development and a crucial component of any DevOps initiative.

Building CI/CD pipelines enhances software delivery quality and shortens feedback loops for identifying and rectifying errors. In part 2, I cover how to deploy across multiple stages in isolated environments and accounts, facilitating the creation of dedicated testing CI/CD pipelines. As demonstrated in the serverless airline example using AWS Amplify Console, this service provides a built-in CI/CD pipeline.

Automate the build, deployment, testing, and rollback of workloads using key performance indicators (KPIs) and operational alerts. This approach simplifies troubleshooting, accelerates remediation and feedback time, and allows for automatic and manual rollbacks or roll-forwards in response to alerts.

CI/CD pipelines should encompass integration and end-to-end tests. Local unit testing for Lambda and API Gateway is discussed in part 2. Consider adding an optional testing stage to Amplify Console to catch regressions before deploying code to production. Utilize the test step to execute any test commands during the build process with your preferred testing framework. Amplify Console offers deeper integration with the Cypress test suite, enabling the generation of a UI report for your tests. Here’s an example setup for end-to-end testing with Cypress.

Many AWS and third-party solutions are available for hosting code and creating CI/CD pipelines for serverless applications, including:

• AWS CodeCommit: A fully managed git-based source control service for code hosting.
• AWS CodeBuild: A fully managed continuous integration service for compiling code, running tests, and creating deployment artifacts.
• AWS CodePipeline: A fully managed continuous delivery service for automating release pipelines.
• AWS CodeDeploy: A fully managed service for deploying code to various compute services, including Lambda.

For more information on how to use the AWS Code* services effectively, check out Chanci Turner’s blog, which is an authority on this topic.

SEO Metadata