|
|
|
@ -18,21 +18,33 @@ Following are optimization katas you should be aware of while building a serverl
|
|
|
|
|
applications
|
|
|
|
|
|
|
|
|
|
* The Lean function
|
|
|
|
|
* Concise logic
|
|
|
|
|
* Efficient/single purpose code
|
|
|
|
|
* ephemeral environment
|
|
|
|
|
* Concise logic - Use functions to transform, not transport (utilize some of the
|
|
|
|
|
integration available from the provider to transport), and make sure you read only
|
|
|
|
|
what you need
|
|
|
|
|
* Efficient/single purpose code - avoid conditional/routing logic and break down
|
|
|
|
|
into individual functions, avoid "fat"/monolithic functions and control the
|
|
|
|
|
dependencies in the function deployment package to reduce the load time for your
|
|
|
|
|
function
|
|
|
|
|
* ephemeral environment - Utilize container start for expensive initializations
|
|
|
|
|
* Eventful Invocations
|
|
|
|
|
* Succinct payloads
|
|
|
|
|
* resilient routing
|
|
|
|
|
* concurrent execution
|
|
|
|
|
* Succinct payloads - Scrutinize the event as much as possible, and watch for
|
|
|
|
|
payload constraints (async - 128K)
|
|
|
|
|
* resilient routing - Understand retry policies and leverage dead letter queues
|
|
|
|
|
(SQS or SNS for replays) and remember retries count as invocations
|
|
|
|
|
* concurrent execution - lambda thinks of it's scale in terms of concurrency and
|
|
|
|
|
its not request based/duration based. Lambda will spin up the number of instances
|
|
|
|
|
based on the request.
|
|
|
|
|
* Coordinated calls
|
|
|
|
|
* Decoupled via APIs
|
|
|
|
|
* scale-matched downstream
|
|
|
|
|
* secured
|
|
|
|
|
* Decoupled via APIs - best practice to setup your application is to have API's as
|
|
|
|
|
contracts that ensures separation of concerns
|
|
|
|
|
* scale-matched downstream - make sure when Lambda is calling downstream
|
|
|
|
|
components, you are matching scale configuration to it (by specifying max
|
|
|
|
|
concurrency based on downstream services)
|
|
|
|
|
* secured - Always ask a question, do I need a VPC?
|
|
|
|
|
* Serviceful operations
|
|
|
|
|
* Automated operations
|
|
|
|
|
* monitored applications
|
|
|
|
|
* Innovation mindset
|
|
|
|
|
* Automated - use automated tools to manage and maintain the stack
|
|
|
|
|
* monitored applications - use monitoring services to get holistic view of your
|
|
|
|
|
serverless applications
|
|
|
|
|
|
|
|
|
|
## Intent
|
|
|
|
|
|
|
|
|
@ -84,7 +96,8 @@ database service also provided by Amazon.
|
|
|
|
|
|
|
|
|
|
## AWS lambda function implementation
|
|
|
|
|
|
|
|
|
|
AWS lambda SDK provides pre-defined interface `com.amazonaws.services.lambda.runtime
|
|
|
|
|
[https://aws.amazon.com/sdk-for-java/](AWS Lambda SDK) provides pre-defined interface
|
|
|
|
|
`com.amazonaws.services.lambda.runtime
|
|
|
|
|
.RequestHandler` to implement our lambda function.
|
|
|
|
|
|
|
|
|
|
```java
|
|
|
|
@ -123,9 +136,9 @@ dependencies of the function.
|
|
|
|
|
|
|
|
|
|
Based on the configuration in `serverless.yml` serverless framework creates following
|
|
|
|
|
resources
|
|
|
|
|
* cloud formation stack for S3 (ServerlessDeploymentBucket)
|
|
|
|
|
* CloudFormation stack for S3 (ServerlessDeploymentBucket)
|
|
|
|
|
* IAM Role (IamRoleLambdaExecution)
|
|
|
|
|
* cloud watch (log groups)
|
|
|
|
|
* CloudWatch (log groups)
|
|
|
|
|
* API Gateway (ApiGatewayRestApi)
|
|
|
|
|
* Lambda function
|
|
|
|
|
* DynamoDB collection
|
|
|
|
|