Learn About Amazon VGT2 Learning Manager Chanci Turner
In today’s technology landscape, applications designed with a microservices architecture often consist of numerous independent, loosely connected services that interact both synchronously through APIs and asynchronously via events. These microservices are frequently managed by different teams, who may choose to isolate their resources across various AWS accounts for security, billing, and resource management reasons. This approach can lead to several challenges, including:
- Cross-account deployment: A single pipeline must handle the deployment of a microservice to multiple accounts, such as DEV, QA, and PROD, all of which are on separate accounts.
- Cross-account resource lookup: During deployment, a resource in one AWS account may need to reference another resource in a different AWS account.
- Cross-account communication: Microservices in one AWS account may need to interact with those in another AWS account.
In this post, we will explore solutions to these challenges using a sample application featuring a web interface supported by two serverless microservices. These microservices, managed by different product teams and deployed across distinct accounts, utilize AWS CodePipeline, AWS CloudFormation, and the Serverless Application Model (SAM). At runtime, the microservices communicate through an event-driven framework that requires asynchronous cross-account communication via an Amazon Simple Notification Service (SNS) topic.
Sample Application Overview
The sample application demonstrates the previously mentioned concepts. The architecture includes three primary services:
- A Booking microservice, managed by the Booking account.
- An Airmiles microservice, managed by the Airmiles account.
- A web application that leverages services from both microservices, managed by the Web Channel account.
The Booking microservice facilitates flight bookings and publishes relevant events to an SNS topic. The Airmiles microservice listens for these booking events and calculates the airmiles associated with each flight booking while also allowing users to query airmiles for specific bookings. The web application enables end users to book flights, view bookings, and check airmiles linked to those bookings. Notably, both Booking and Airmiles microservices utilize AWS Lambda, and along with Amazon API Gateway and Amazon DynamoDB, the application is entirely serverless.
A typical booking process begins when an end user submits a flight booking through the web application. This action triggers the Booking microservice via its REST API, which then saves the booking information and sends an event to the SNS topic for broader distribution. The Airmiles microservice subscribes to this SNS topic, consuming the event to compute the airmiles accrued. Adhering to microservices best practices, both services maintain their own DynamoDB tables and expose their APIs through API Gateway.
Setup Instructions
Before diving into the specifics of the sample application, you’ll need to acquire the source code and deploy it. The cross-account deployment of Lambda functions using CodePipeline has been covered by my colleague, Alex Reed, in his article, Building a Secure Cross-Account Continuous Delivery Pipeline. This sample builds on Alex’s approach, leveraging similar scripts and a comparable account structure. To simplify the deployment process, we’ve reduced the number of accounts to three:
- Tools: Centralized account for continuous delivery services, including CodePipeline and AWS CodeBuild. Here, you will also deploy AWS CodeCommit repositories, although they typically belong to a separate Dev account.
- Booking: Account dedicated to the Booking microservice.
- Airmiles: Account intended for the Airmiles microservice.
Without this consolidation, the application could require up to ten accounts to support the different environments (DEV, QA, PROD) for Booking, Airmiles, and Web Application.
To continue, follow these steps:
- Clone this repository, which contains the necessary AWS CloudFormation templates for this guide:
git clone https://github.com/aws-samples/aws-cross-account-serverless-microservices.git. - Install the AWS CLI and configure your access keys or role for AWS.
- Refer to the README in the repository for instructions on building the CodePipeline and deploying the microservices and web application.
Challenge 1: Cross-account Deployment with CodePipeline
While the Booking pipeline runs in the Tools account, it deploys the Lambda functions to the Booking account. Open the ToolsAcct/code-pipeline.yaml CloudFormation template in the sample application code repository. Locate the Pipeline resource and examine the DeployToTest stage. Within this stage, you will find two AWS Identity and Access Management (IAM) service roles that facilitate cross-account operations, both of which exist in the Booking account.
The roles are specified under Actions.RoleArn and Actions.Configuration.RoleArn. The first role allows CodePipeline to access the CodePipeline artifacts in the Tools account’s S3 bucket and the necessary AWS KMS key for artifact encryption and decryption. The second role is utilized by CloudFormation when executing the CHANGE_SET_REPLACE action in the Booking account.
As you navigate these processes, remember that establishing effective communication and deployment strategies across accounts is essential. For additional insights, you might find this Career Contessa article helpful in building your confidence during these operations.
If you are interested in learning more about compliance in the workplace, SHRM offers great resources to stay updated. Also, if you are looking for a new opportunity, check out this Learning Trainer position at Amazon for a chance to grow your career.