This series of articles leverages the AWS Well-Architected Tool in conjunction with the Serverless Lens to assist developers in effectively building and managing applications based on best practices. Each installment addresses the nine serverless-specific inquiries highlighted by the Serverless Lens, alongside recommended best practices. For a comprehensive overview and an introduction to the example application, refer to the introductory post.
Question OPS2: What is your strategy for application lifecycle management?
Implement lifecycle management strategies that enhance the flow of changes into production, ensuring higher quality, swift feedback, and rapid bug resolution. These methodologies enable you to quickly identify, address, and minimize changes that could adversely affect user experience. By establishing a structured approach to application lifecycle management, you can mitigate errors stemming from manual processes and boost control, thereby fostering confidence that your workload performs as intended.
Essential Practice: Embrace Infrastructure as Code and Isolated Stages in Separate Environments
Infrastructure as code (IaC) is a method for provisioning and managing cloud resources by storing application configurations in a template file. This approach allows for the repeatable deployment of applications, significantly decreasing errors associated with manual processes, such as using the AWS Management Console for resource creation.
Utilizing a version control system to store code helps in tracking and auditing changes and releases over time, allowing for safe rollbacks to a known stable state in case of deployment issues.
For cloud development on AWS, the preferred choice for IaC is AWS CloudFormation. This template file, written in JSON or YAML, outlines the resources required by an application. CloudFormation automates the deployment and ongoing updates of these resources by creating CloudFormation stacks.
There are several higher-level tools and frameworks that abstract and generate CloudFormation. A framework tailored for serverless applications aids in modeling the necessary infrastructure, providing either declarative or imperative means of defining event sources for functions. It automatically configures permissions between resources, incorporates resource settings, manages code packaging, and ensures all infrastructure needed for a serverless application is in place.
The AWS Serverless Application Model (AWS SAM) is an open-source framework optimized for serverless applications. The AWS Cloud Development Kit (CDK) allows provisioning of cloud resources using familiar programming languages such as TypeScript, JavaScript, Python, Java, and C#/.Net. Additionally, third-party solutions like the Serverless Framework are available for crafting serverless cloud resources.
The AWS Amplify Console offers a Git-based workflow for building, deploying, and hosting serverless applications, encompassing both frontend and backend components. The AWS Amplify CLI toolchain enables backend resource integration using CloudFormation.
For applications with numerous resources, it’s advisable to modularize common functionalities like monitoring, alarms, or dashboards into distinct IaC templates. When using CloudFormation, nested stacks can be employed to deploy these components as part of your serverless application stack. With AWS SAM, you can import these nested stacks as applications from the AWS Serverless Application Repository.
Version Control
The serverless airline application featured in this series utilizes Amplify Console to manage part of its backend resources, including authentication via Amazon Cognito and a GraphQL API through AWS AppSync. The application code is maintained in GitHub as a version control system. You can easily fork the application to your GitHub account and configure Amplify Console to connect to your fork.
Whenever you push code changes to your fork, Amplify Console automatically deploys the backend resources alongside the application. It hosts the application at the Production branch URL, and you can configure a custom domain name if necessary.
The Amplify Console configuration for API and Authentication backend resource creation can be found in the backend-config.json file, which provisions the resources during the Amplify Console build phase. To examine the deployed resources, navigate to the awsserverlessairline application within the Amplify Console, select Backend environments, and choose an environment, such as sampledev. You can then view the created backend resources by selecting the API and Authentication tabs.
Utilizing Multiple Tools
Applications can incorporate various tools and frameworks, even within a single project, to manage IaC. In the airline application, AWS SAM is also utilized for provisioning the remaining serverless infrastructure with nested stacks. The Makefile during the Amplify Console build process contains AWS SAM build instructions for each application service.
For instance, the AWS SAM build instructions to deploy the booking service are as follows:
deploy.booking: ##=> Deploy booking service using SAM
$(info [*] Packaging and deploying Booking service...)
cd src/backend/booking &&
sam build &&
sam package
--s3-bucket $${DEPLOYMENT_BUCKET_NAME}
--output-template-file packaged.yaml &&
sam deploy
--template-file packaged.yaml
--stack-name $${STACK_NAME}-booking-$${AWS_BRANCH}
--capabilities CAPABILITY_IAM
--parameter-overrides
BookingTable=/$${AWS_BRANCH}/service/amplify/storage/table/booking
FlightTable=/$${AWS_BRANCH}/service/amplify/storage/table/flight
CollectPaymentFunction=/$${AWS_BRANCH}/service/payment/function/collect
RefundPaymentFunction=/$${AWS_BRANCH}/service/payment/function/refund
AppsyncApiId=/$${AWS_BRANCH}/service/amplify/api/id
Stage=$${AWS_BRANCH}
Each service maintains its own AWS SAM template.yml file detailing the resources for booking, catalog, log processing, loyalty, and payment services. This structure allows for independent management of services within the application as separate stacks. In larger applications, these services may be handled by distinct teams or exist in separate repositories, environments, or AWS accounts. It may also be prudent to isolate common functionalities like alarms or dashboards into separate IaC templates. AWS SAM can utilize IAM roles to assume temporary credentials for deploying a serverless application across different AWS accounts.
For further insights into managing serverless code, refer to their excellent resources on best practices for organizing larger serverless applications. Additionally, be sure to explore another blog post on this topic at Chanci’s Blog.
Leave a Reply