You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/core/event_handler/api_gateway.md
+12-15Lines changed: 12 additions & 15 deletions
Original file line number
Diff line number
Diff line change
@@ -1133,7 +1133,7 @@ Event Handler naturally leads to a single Lambda function handling multiple rout
1133
1133
1134
1134
Both single (monolithic) and multiple functions (micro) offer different set of trade-offs worth knowing.
1135
1135
1136
-
!!! tip "Start with a monolithic function and eventually break into multiple functions, if necessary."
1136
+
!!! tip "TL;DR. Start with a monolithic function, break into multiple functions, and eventually micro independent functions if necessary."
1137
1137
1138
1138
#### Monolithic function
1139
1139
@@ -1149,30 +1149,27 @@ A monolithic function means that your final code artifact will be deployed to a
1149
1149
1150
1150
**Downsides**
1151
1151
1152
-
***Cold starts**. Frequent deployments and/or high load can diminish the benefit of monolithic functions depending on your latency requirements, due to [Lambda scaling model](https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html). Always load test to pragmatically balance between your customer experience and development cognitive load.
1153
-
***Granular security permissions**. The micro function approach enables you to use fine-grained permissions, separate external dependencies & code signing at the function level. Regardless, least privilege can be applied to either approaches.
1152
+
***Cold starts**. Frequent deployments and/or high load can diminish the benefit of monolithic functions depending on your latency requirements, due to [Lambda scaling model](https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html){target="_blank"}. Always load test to pragmatically balance between your customer experience and development cognitive load.
1153
+
***Granular security permissions**. The micro function approach enables you to use fine-grained permissions, separate external dependencies & code signing at the function level. Conversely, you could have multiple functions while duplicating the final code artifact in a monolithic approach. Regardless, least privilege can be applied to either approaches.
1154
1154
***Higher risk per deployment**. A bad deployment can cause the entire service to stop working while a micro function will limit its blast radius. You can minimize risks by ensuring modules are tested in isolation, use multiple environments in your CI/CD pipeline, and optionally use linear/canary deployments to trade lead time for safety.
1155
1155
1156
1156
#### Micro function
1157
1157
1158
1158

1159
1159
1160
+
A micro function means that your final code artifact will be different to each function deployed. This is generally the approach to start if you're looking for fine-grain control and/or high load on certain parts of your service.
1160
1161
1161
-
!!! TODO "rewrite this section"
1162
-
1163
-
1164
-
!!! tip "TL;DR. Balance your latency requirements, cognitive overload, least privilege, and operational overhead to decide between one, few, or many single purpose functions."
1165
-
1166
-
Route splitting feature helps accommodate customers familiar with popular frameworks and practices found in the Python community.
1167
-
1168
-
It can help better organize your code and reason
1169
-
1170
-
This can also quickly lead to discussions whether it facilitates a monolithic vs single-purpose function. To this end, these are common trade-offs you'll encounter as you grow your Serverless service, specifically synchronous functions.
1162
+
**Benefits**
1171
1163
1172
-
**Least privilege**. Start with a monolithic function, then split them as their data access & boundaries become clearer. Treat Lambda functions as separate logical resources to more easily scope permissions.
1164
+
***Granular scaling**. A micro function can benefit from the [Lambda scaling model](https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html){target="_blank"} to scale differently depending on each part of your application. Concurrency controls and provisioned concurrency can also be used at a granular level for capacity management.
1165
+
***Discoverability**. Micro functions are easier do visualize when using distributed tracing. Their automated architectures can be self-explanatory if each function is named to the purpose it serves from a business context.
1166
+
***Package size**. An independent function can be significant smaller (KB vs MB) depending on external dependencies it require to perform its purpose. Conversely, a monolithic approach can benefit from [Lambda Layers](https://docs.aws.amazon.com/lambda/latest/dg/invocation-layers.html){target="_blank"} to optimize builds for external dependencies.
1173
1167
1174
-
**Package size**. Consider Lambda Layers for third-party dependencies and service-level shared code. Treat third-party dependencies as dev dependencies, and Lambda Layers as a mechanism to speed up build and deployments.
1168
+
**Downsides**
1175
1169
1170
+
***Upfront investment**. Python ecosystem doesn't use a bundler. This means you need a custom build tooling to ensure each function only has what it needs. External dependencies using C extensions must be built using [Amazon Linux runtime](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html){target="_blank"} for Lambda runtime compatibility reasons.
1171
+
***Harder to share code**. Shared code must be carefully evaluated to avoid unnecessary deployments when that changes. Equally, if shared code isn't a library, you need your building tool to coordinate copying them over to each code artifact prior to deployment. This leads to additional IDE, your preferred terminal and Python settings to ensure code is discoverable, testable, and that linters understand them.
1172
+
***Slower safe deployments**. Safe deployments of multiple functions require coordination, by default AWS CodeDeploy deploys and verifies each function sequentially. This can increase lead time substantially (minutes to hours) depending on the number of functions and the deployment strategy you choose. You can mitigate it by enabling safe deployments in selected environments - pre-prod, prod - and carefully analyzing the risk profile of a deployment. In either approaches, automated testing and operational reviews are essential to stability.
0 commit comments