Use Lambda Powertools
The open source Lambda Powertools initiative provides an indispensable set of tools to use when developing Lambda functions. There are implementations in a variety of languages, including Python, Node.js/TypeScript, Java, and .NET.
The libraries are predominantly focused on observability and provide three core utilities: a logger, a tracer, and a custom metrics collector. However, more features are continually being added to the various libraries, such as tools to support idempotency and integration with parameter stores like AWS SSM Parameter Store and AWS AppConfig.
Minimize deploy-time dependencies
As your serverless application grows, so will the number of microservices it is com‐ posed of. During this period of growth there will inevitably come a point where two or more services require access to a single resource. Without properly planning for the sharing of resources, you can inadvertently introduce tight coupling between resources and make it difficult to iterate on the connected components or introduce new connections.
In a serverless architecture it is common to have components such as S3 buckets, DynamoDB tables, or EventBridge event buses with multiple actors reading from or writing to these resources across distinct microservices. These can be referred to as shared resources, as they are used by more than one microservice.
The key to maintaining relationships between shared resources and the actors inter‐ acting with them is to avoid coupling them in delivery pipelines at deployment time. Interdependent resources should not be coupled between CloudFormation stacks that describe separate services. For example, let’s say you have two microservices: Service A defines an EventBridge event bus that Service B consumes events from. Service B defines the EventBridge rule that matches event patterns and triggers a target. To attach the rule to the bus defined in Service A, Service B must make reference to the bus (e.g., via an ARN). For Service B’s reference to Service A’s bus to be resolvable to a resource deployed to AWS, Service A’s CloudFormation stack must be deployed. This creates a deployment dependency in Service B on Service A.
Amazon Resource Names (ARNs) are unique identifi‐
ers for your AWS resources. They use a format
similar to this: arn:<partition>:<service>:<region>:<account-id>:<resource-type>/<resource-id>. For example, the event bus my-bus in the Frankfurt region would have the ARN arn:aws:events:eu-central-1:012345678901:event-bus/ my-bus. ARNs can be used to obtain references to your resources and used in CloudFormation templates.
Whenever a CloudFormation stack depends on a resource defined in another stack, you will need to consider how to discover and reference the resource. A common approach to service discovery is to broadcast the ARNs of shared resources via CloudFormation outputs or SSM parameters so that they can be imported by any consuming stacks.
That single dependency may not seem too problematic, but as more services begin to depend on the central event bus in Service A it becomes harder and harder to main‐ tain, evolve, or even decommission Service A. Deployment of Service B could also now be blocked unnecessarily by any issues with Service A (see Figure 6-6). The two services have now become tightly coupled and must be aware—and considerate—of each other.
Generally, it is advisable to keep shared resources to a minimum. When the need to share a resource across multiple microservices arises, a best practice is to place the shared resource in a separate stack; not a single stack for all shared resources but a stack per shared resource.
Figure 6-6. Sharing resources across decoupled microservices