More reInvent: Microservices and Serverless
Today’s writeup cover two talks, both on serverless.
Thinking Microservices as Workflows
This session was next door to one on “Blockchain in the Enterprise”. That one was completely full with a line out the door……
The presentation was part of the AWS Partner Summit and given by three AWS Partner Solutions Architects. It was a “Chalk Talk” interactive session with lots of questions, so not the easiest thing to blog.
They defined Microservices as a small system done by a two pizza team with it’s own data store and with all interaction with other services (in or out) being via an API.
Problem: When dealing with large numbers of Lambdas all talking to each other, APIs must be immutable for any given version and the service must support previous versions. This creates problems as things change over time so have central orchestrator and then services can be unaware of their peers. Idea of the talk is to use StepFunctions as the orchestrator.
Another motivation: All calls from one service to another must be async. This leads to complexity when handling errors (including backoff and fallback) directly within the calling service and becomes unmaintainable as number of services increases. (It also adds cost in Lambda as caller waits for errors and retries).
Traditional solution: use a queue and pub/sub
New solution: use StepFunction workflow. StepFunctions can handle errors, retries and backoff and it’s all built in, defined in JSON. Can also bypass Lambda by having API gateway trigger a StepFunction, integrate with S3 by having Lambda trigger StepFunction on file upload etc.
Many questions from the audience:
Q: How do you use StepFunctions in production?
A: Use CloudFormation to create and deploy with code in version control etc
Q: How do StepFunctions handle async calls or ones that run longer than a Lambda can execute?
A: Use StepFunction TaskMap to a state which works like a queue. Then need to trigger poll to see if event has completed
Q: Should I use StepFunctions or Simple Work Flow?
A: For new projects, use StepFunctions
Q: How to handle/track errors in the StepFunction itself?
A: Can trigger SNS to generate events at each stage or track state by execution ID in DynamoDB and then query.
Q: Can I do manual approval in a workflows?
A:Yes. See Manual approval workflows with StepFunctions
Q: Can I use one lambda at multiple stage in the workflow?
A: Use environment variables to trigger different actions. But use many lambdas as they are cheap.
Another example mentioned was using a workflow to drive a ML training job where the workflow launches P3 EC2 instances, copies in the data, waits for notification of completion etc.
Deploying and developing at the speed of light: Automating Serverless deployments
Another talk from four Partner Solutions Architects and another Chalk Talk in the Global Partners Summit. Clearly this is a topic on people’s mind as the session was full.
AWS Serverless Application Model (SAM) is extension to CloudFormation. Released on Github and simplifies defining CloudFormation
Talk based on deploying an app, with details in a README. Demo used AWS services, but can use Github and Jenkins instead.
The pipeline for deployments is:
SAM template committed to CodeCommit -> AWS CodeBuild -> Teststack and Beta Stack (both using CloudFormation)
Integration test runs a lambda as part of the test stack, and this must pass before deploying to prod.
CodePipeline drives all the pieces and ties it all together.
Can get this to work across multiple accounts (dev -> prod) but is more work. Multiple accounts is the recommended setup
Q: Any timelimits on how long a stage can take?
A: 60 mins
Q: What about long running integration tests that take longer than this?
A: Not really sure
Q: Can CodeBuild talk to repos in a VPC?
A: Yes. Added fairly recently
