Serverless Microservices
•
24 likes•9,547 views
Serverless microservices allow building scalable and resilient applications from small, isolated services using AWS Lambda and API Gateway. Each microservice owns its own data in a decentralized data store like DynamoDB. API Gateway acts as a front door and handles authentication, authorization, and throttling. Lambda provides immutable function versions and aliases for deployments. While this makes applications highly available and scalable, it introduces challenges around transactions and data consistency. The document proposes using techniques like correlation IDs, rollback functions, DynamoDB streams, and a transaction manager to handle errors and rollbacks in a serverless environment.
Report
Share
Serverless Microservices
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Olivier Klein – Emerging Technologies Solutions Architect, Asia Pacific September 2016 Serverless Microservices Build Scalable, Fault-Tolerant and Transaction-Safe Microservices on AWS
- 2. Microservices advocate creating a system from a collection of small, isolated services, each of which owns their data, scalable and resilient to failure
- 3. How to Build Application Backends? Back-end logic DatabaseBrowser /Mobile
- 4. How to Build Serverless Microservices? AWS Lambda Amazon API Gateway Amazon DynamoDB Microservice
- 5. How to Build Serverless Microservices? AWS Lambda Amazon API Gateway Amazon DynamoDB Microservice 1 Microservice 2 Microservice N ...
- 6. Amazon API Gateway • Create, publish, maintain, monitor and secure RESTful APIs • Powered by our content delivery network via 61 global edge locations • Provides DDoS protection and throttling capabilities • Multiple API stages which you define (e.g. dev, test, prod) AWS Lambda Amazon API Gateway Amazon EC2 AWS API On-prem Server
- 7. Amazon API Gateway: Authorisation Amazon API Gateway • Allows unauthenticated requests, or authorises via AWS IAM • Amazon Cognito or AWS STS for temporary credential generation • API Keys available to monitor individual app calls • You can create API Key specific throttling and usage plans Basic – 5 TPS Premium – 100 TPS Power – No throttling API Keys – Usage Plans Amazon Cognito AWS IAM
- 9. AWS Lambda: Versioning • Immutable versions of functions • Per version configuration • Per version Cloudwatch metrics • Cloudwatch Logs contain version attribute • Aliases to “label” a version release • $LATEST contains latest code
- 10. $LATEST(95) STABLE TESTING 94 X 93 X 92 Update Alias to Deploy
- 11. $LATEST(95) STABLE TESTING 94 X X 93 92 Update Alias to Deploy
- 12. API Stages
- 13. API Gateway Stage Variables
- 14. API Gateway Stage Variables
- 15. API Gateway Lambda Custom Domain /prod/Resources FunctionName:stable https://api.example.com /dev/Resources FunctionName:$LATEST https://dev.example.com /qa/Resources FunctionName:qa https://qa.example.com Pin your Environment with Stage Variables
- 16. Serverless Microservices AWS Lambda Amazon API Gateway • Highly available • Scalable • Fault tolerant • Cost effective • Secure • BUT: Stateless! Microservice ?
- 17. Challenge: Centralised Database user-svc account-svccart-svc DB • Applications often have a monolithic data store • Difficult to make schema changes • Technology lock-in • Vertical scaling • Single point of failure
- 18. Centralised Database – Anti-pattern • Applications often have a monolithic data store • Difficult to make schema changes • Technology lock-in • Vertical scaling • Single point of failure user-svc account-svccart-svc DB
- 19. Decentralised Data Stores account-svccart-svc DynamoDB RDS user-svc ElastiCache RDS • Polyglot persistence • Each service chooses it’s data store technology • Low impact schema changes • Independent scalability • Data is gated through the service API
- 20. CAP Theorem It is impossible for a distributed computer system to simultaneously provide all 3 of the following guarantees: • Consistency • Availability • Partition Tolerance à In the presence of network partition we need to choose between consistency and availability
- 21. Challenge: Transactional Integrity • Polyglot persistence generally translates into eventual consistency • Asynchronous calls allow non- blocking, but returns need to be handled properly • How about transactional integrity? • Event-sourcing – Capture changes as sequence of events • Staged commit • Rollback on failure ERROR STATE? ROLLBACK?
- 22. Let’s try a Demo – Online Commerce • Online commerce with microservices to • Checkout a cart • Collect payment • Warehouse Management • Shipment • High volume site, out of stock errors, credit card payments with risk cut-off (< 100 USD) • Demonstrate successful and failing transactions with graceful rollback
- 23. Best Practice: Use Correlation IDs 09-02-2015 15:03:24 ui-svc INFO [uuid-123] …… 09-02-2015 15:03:25 catalog-svc INFO [uuid-123] …… 09-02-2015 15:03:26 checkout-svc ERROR [uuid-123] …… 09-02-2015 15:03:27 payment-svc INFO [uuid-123] …… 09-02-2015 15:03:27 shipping-svc INFO [uuid-123] …… ui-svc catalog- svc checkout- svc shipping- svc payment- svc request correlation id: “uuid-123” correlation id: “uuid-123”
- 24. Best Practice: Microservice Owns Rollback • Every microservice should expose it’s own “rollback” method • This method could just rollback changes, or trigger subsequent actions (e.g. send notification) • If you implement staged commit, also expose a commit function Microservice Function 1 Rollback Commit (optional)
- 25. Event-Driven: DynamoDB Streams • If async, consider event-driven approach with DynamoDB Streams • Don’t need to manage function execution failure, DDB Streams automatically retries until successful • “Attach” yourself to the data of interest • Kinesis, SQS, SNS also possible Microservice
- 26. Challenge: Report Errors / Rollback • What if functions fail? (business logic failure, not code failure) • Create a “Transaction Manager” microservice that notifies all relevant microservices to rollback or take action • DynamoDB is the trigger for the clean-up function (could be SQS, Kinesis etc.) • Use Correlation ID to identify relations mm-svc Transaction Manager Function DDB Streams API Call Error Table
- 27. Challenge: Report Errors / Rollback ERROR DynamoDB Error Table Transaction Manager Function Kinesis Error Stream SQS Error Queue Rollback(co rrelation-id) Rollback(co rrelation-id) Rollback(co rrelation-id) Rollback(co rrelation-id)
- 28. Challenge: Code Error • Lambda execution error because of faulty / erroneous code • Leverage Cloudwatch Logs to process error message and call transaction manager • Set Cloudwatch Logs metric filter to look for error/exception and call Lambda handler upon alarm state ui-svc Cloudwatch Logs Cloudwatch Alarm Transaction Manager Function
- 29. Beware: Stream Model with AWS Lambda • DynamoDB Streams and Kinesis streams directly work with AWS Lambda, however AWS Lambda needs to acknowledge processing the message correctly • If Lambda fails to process the message, the stream horizon will not be moved forward, creating a “jam” • Solution: Monitor AWS Lambda Error Cloudwatch Metric and react when error rate of same “Correlation ID” keeps increasing
- 30. MDM – Keep Data Consistent Databases AWS Lambda “Cleanup” Function Cloudwatch Scheduled Event • Perform Master Data Management (MDM) to keep data consistent • Create AWS Lambda function to check consistencies across microservices and “cleanup” • Create Cloudwatch Event to schedule the function (e.g. hourly basis)
- 31. Final Thoughts • Use Amazon API Gateway to build a front-door to all your microservices (AWS Lambda, Docker, EC2 etc.) • Use polyglot persistence to avoid bottlenecks, schema issues and allow independent scalability (and cache) • Embrace eventual consistency and design fault-tolerant business processes which can recover • Monitor your environment and cleanup whenever necessary (automation is your friend!)
- 32. Thank You!