Diving deep into the event-driven side of Serverless

ServerlessDays, Istanbul, October 3rd, 2019

Serverless computing is often described as the interaction of functions with fully-managed services. In this way, you can build applications without having to think about servers. But how do functions and fully-managed services interact? Via events! Events are important for serverless. Event-driven architectures help you adopt some of the best practices for distributed systems without even realizing it. Let’s see what events and event-driven programming can bring to the table, what we can learn to build better and easier to manage serverless applications.

Transcript

1. © 2019, Amazon Web Services, Inc. or its Affiliates. Danilo Poccia Principal Evangelist, Serverless @danilop Diving deep into the event-driven side of Serverless
2. How does Serverless work? Photo by Mervyn Chan on Unsplash
3. © 2019, Amazon Web Services, Inc. or its Affiliates. How does Serverless work? Storage Databases Analytics Machine Learning . . . Your unique business logic User uploads a picture Customer data updated Anomaly detected API call . . . Fully-managed services Events Functions
4. © 2019, Amazon Web Services, Inc. or its Affiliates. What is an “event” ? “something that happens” Events tell us a fact Immutable time-series Time What 2019 06 21 08 07 06 CustomerCreated 2019 06 21 08 07 09 OrderCreated 2019 06 21 08 07 13 PaymentSuccessful 2019 06 21 08 07 17 CustomerUpdated . . . . . .
5. © 2019, Amazon Web Services, Inc. or its Affiliates. Time is important “Modelling events forces you to have a temporal focus on what’s going on in the system. Time becomes a crucial factor of the system.” – Greg Young, A Decade of DDD, CQRS, Event Sourcing, 2016
6. © 2019, Amazon Web Services, Inc. or its Affiliates. Should you focus on the current status, or what is happening? Current status Domain model Commands Control ”CreateAccount” “AddProduct” What happens Domain events Event-driven Autonomy ”AccountCreated” “ProductAdded”
7. © 2019, Amazon Web Services, Inc. or its Affiliates. Commands Vs Events Command Has an intent Directed to a target Personal communication ”CreateAccount” “AddProduct” Event It’s a fact For others to observe Broadcast one to many ”AccountCreated” “ProductAdded”
8. © 2019, Amazon Web Services, Inc. or its Affiliates. Behavior Vs Structure “When you start modeling events, it forces you to think about the behaviour of the system. As opposed to thinking about the structure of the system.” – Greg Young, A Decade of DDD, CQRS, Event Sourcing, 2016
9. What can a function do with events? Function Service Event Service Storage / Database Event React to facts that are coming in Publish new facts for others to use Events can bring data and simplify state hydration For writes/updates, minimize reads
10. What can more functions do together? A microservice Function Service Event Service Function Function Microservice Storage / Database Event Replace commands with events to minimize coupling and increase autonomy “If this, then that…”
11. What can more functions do together? A microservice Create Customer Amazon API Gateway Create User Request Amazon SNS Get Customer Update Customer Microservice Amazon DynamoDB User Created
12. What can more functions do together? A better microservice Create Customer Amazon API Gateway Create User Request Get Customer Update Customer Microservice Amazon DynamoDB User Created Using DynamoDB Streams Using the Lambda HTTP interface (Invoke) as service boundary (Sync/Async + AAA) AWS Lambda Invoke
13. © 2019, Amazon Web Services, Inc. or its Affiliates. What about integration? Create Order Reserve Item Process Payment Start Order Delivery Payment Service Product Inventory
14. © 2019, Amazon Web Services, Inc. or its Affiliates. Keep data within the microservice Amazon Aurora Amazon DocumentDB Amazon DynamoDB Amazon Neptune Amazon Quantum Ledger Database (QLDB) Amazon RDS Amazon Timestream Amazon Elasticsearch Service Relational NoSQL Graph Time series Ledger Bonus Polyglot persistence gives database freedom!
15. © 2019, Amazon Web Services, Inc. or its Affiliates. So, again, what about integration ? Create Order Reserve Item Process Payment Start Order Delivery Payment Service Product Inventory
16. © 2019, Amazon Web Services, Inc. or its Affiliates. Introducing sagas Long lived transactions (LLT) The same idea can be applied to transactions across multiple microservices SAGAS Hector Garcaa-Molrna Kenneth Salem Department of Computer Science Princeton University Princeton, N J 08544 Abstract Long lived transactions (LLTs) hold on to database resources for relatively long periods of time, slgmficantly delaymg the termmatlon of shorter and more common transactions To alleviate these problems we propose the notion of a saga A LLT 1s a saga if it can be written as a sequence of transactions that can be interleaved with other transactions The database manage- ment system guarantees that either all the tran- sactions m a saga are successfully completed or compensatmg transactions are run to amend a partial execution Both the concept of saga and its lmplementatlon are relatively simple, but they have the potential to improve performance slgmficantly We analyze the various lmplemen- tatron issues related to sagas, including how they can be run on an exlstmg system that does not directly support them We also discuss tech- niques for database and LLT design that make it feasible to break up LLTs mto sagas 1. INTRODUCTION As its name indicates, a long lived transac- tron 1s a transactlon whose execution, even without interference from other transactions, takes a substantial amount of time, possibly on the order of hours or days A long lived transac- tion, or LLT, has a long duration compared to Permlsslon to copy wlthout fee all or part of this material IS granted provided that the copies are not made or dlstrlbuted for direct commercial advantage, the ACM copyrlght notice and the title of the pubhcatlon and Its date appear, and notlce IS given that copymg IS by permlsslon of the Assoclatlon for Computmg Machmery To copy otherwlse, or to repubhsh, requires a fee and/or specfic permisslon 0 1987 ACM O-89791-236-5/87/0005/0249 75@ the malorlty of other transactions either because it accesses many database obJects, it has lengthy computations, it pauses for inputs from the users, or a combmatlon of these factors Examples of LLTs are transactions to produce monthly account statements at a bank, transactions to process claims at an insurance company, and transactions to collect statrstlcs over an entire database [Graysla] In most cases, LLTs present serious perfor- mance problems Since they are transactions, the system must execute them as atomic actions, thus preserving the consistency of the database [DateSla,Ullm82a] To make a tran- saction atonuc, the system usually locks the objects accessed by the transaction until It com- mits, and this typically occurs at the end of the transactlon As a consequence, other transac- tions wishing to access the LLT’s objects suffer a long locking delay If LLTs are long because they access many database obJects then other transac- tions are likely to suffer from an mcreased block- mg rate as well, 1 e they are more likely to conflict with an LLT than with a shorter transac- tion Furthermore, the transaction abort rate can also be increased by LLTs As discussed m [Gray8lb], the frequency of deadlock 1s very sensitive to the “size” of transactions, that IS, to how many oblects transactions access (In the analysis of [GraySlb] the deadlock frequency grows with the fourth power of the transaction size ) Hence, since LLTs access many oblects, they may cause many deadlocks, and correspond- ingly, many abortions From the point of view of system crashes, LLTs have a higher probability of encountering a failure (because of their duration), and are thus more likely to encounter yet more delays and more likely to be aborted themselves 249
17. © 2019, Amazon Web Services, Inc. or its Affiliates. From Long lived transaction (LLT) to saga Sub-transactions for partial executions Ti , i=1…n Compensating transactions to revert partial executions Ci , i=1…n-1 T1 T2 T3 T4 C1 C2 C3 T1
18. © 2019, Amazon Web Services, Inc. or its Affiliates. Sample saga transaction Create Order Reserve Item Process Payment Start Order Delivery Payment Service Product Inventory T1 T2
19. © 2019, Amazon Web Services, Inc. or its Affiliates. Sample saga transaction Create Order Reserve Item Process Payment Start Order Delivery Payment Service Product Inventory Unreserve Item T1 T2 C1
20. © 2019, Amazon Web Services, Inc. or its Affiliates. Event-driven saga transaction Create Order Reserve Item Process Payment Start Order Delivery Payment Service Product Inventory New Order Payment Confirmed Item Reserved Unreserve Item Item Unreserved Cancel Order Error / D LQ
21. © 2019, Amazon Web Services, Inc. or its Affiliates. Distributed Sagas Distributed Sagas McCa↵rey, Caitie Sporty Tights, Inc Kingsbury, Kyle The SF Eagle Narula, Neha That’s DOCTOR Narula to you! May 20, 2015 1 Introduction The saga paper outlines a technique for long-lived transactions which provide atomicity and durability without isolation (what about consistency? Preserved outside saga scope, not within, right?). In this work, we generalize sagas to a distributed system, where processes communicate via an asynchronous network, and discover new constraints on saga sub-transactions. We are especially interested in the problem of writing sagas which inter- act with third-party services, where we control the Saga Execution Coordinator (SEC) and its storage, but not the downstream Transaction Execution Coordi- nators (TECs) themselves. Communication between the SEC and TEC(s) takes place over an asynchronous network (e.g. TCP) which is allowed to drop, delay, or reorder messages, but not to duplicate them. We assume a high-availability SEC service running on multiple nodes for fault-tolerance, where multiple SECs may run concurrently. They coordinate their actions through a linearizable data store, which ensures saga transactions proceed sequentially. 1 Choreography Event-driven Orchestration Commands Saga Execution Coordinator
22. © 2019, Amazon Web Services, Inc. or its Affiliates. Distributed Sagas – Saga Execution Coordinator Distributed Sagas McCa↵rey, Caitie Sporty Tights, Inc Kingsbury, Kyle The SF Eagle Narula, Neha That’s DOCTOR Narula to you! May 20, 2015 1 Introduction The saga paper outlines a technique for long-lived transactions which provide atomicity and durability without isolation (what about consistency? Preserved outside saga scope, not within, right?). In this work, we generalize sagas to a distributed system, where processes communicate via an asynchronous network, and discover new constraints on saga sub-transactions. We are especially interested in the problem of writing sagas which inter- act with third-party services, where we control the Saga Execution Coordinator (SEC) and its storage, but not the downstream Transaction Execution Coordi- nators (TECs) themselves. Communication between the SEC and TEC(s) takes place over an asynchronous network (e.g. TCP) which is allowed to drop, delay, or reorder messages, but not to duplicate them. We assume a high-availability SEC service running on multiple nodes for fault-tolerance, where multiple SECs may run concurrently. They coordinate their actions through a linearizable data store, which ensures saga transactions proceed sequentially. 1 2 The Saga Execution Coordinator Start Log saga start clean Log saga abort incomplete saga Saga abort aborted saga Saga start Let i = 0 Log Ti start i++ Request Ti Await Ti Log Ti done ok error i = n? more Log saga done done Let i = last logged value of i Log Ci start i-- Request Ci Await Ci error Log Ci done ok i = 0? more done Saga done 2
23. © 2019, Amazon Web Services, Inc. or its Affiliates. Distributed Sagas – Saga Execution Coordinator Directed acyclic graph . . . State machine 2 The Saga Execution Coordinator Start Log saga start clean Log saga abort incomplete saga Saga abort aborted saga Saga start Let i = 0 Log Ti start i++ Request Ti Await Ti Log Ti done ok error i = n? more Log saga done done Let i = last logged value of i Log Ci start i-- Request Ci Await Ci error Log Ci done ok i = 0? more done Saga done 2
24. © 2019, Amazon Web Services, Inc. or its Affiliates. Distributed Sagas – State Machine T1 T2 C1 AWS Step Functions
25. © 2019, Amazon Web Services, Inc. or its Affiliates. “Update-in-place strikes many systems designers as a cardinal sin: it violates traditional accounting practices that have been observed for hundreds of years.” – Jim Gray, The Transaction Concept, 1981 Tandem TR 81.3 The Transaction Concept: Virtues and Limitations Jim Gray Tandem Computers Incorporated 19333 Vallco Parkway, Cupertino CA 95014 June 1981 ABSTRACT: A transaction is a transformation of state which has the properties of atomicity (all or nothing), durability (effects survive failures) and consistency (a correct transformation). The transaction concept is key to the structuring of data management applications. The concept may have applicability to programming systems in general. This paper restates the transaction concepts and attempts to put several implementation approaches in perspective. It then describes some areas which require further study: (1) the integration of the transaction concept with the notion of abstract data type, (2) some techniques to allow transactions to be composed of sub- transactions, and (3) handling transactions which last for extremely long times (days or months). _________________________________ Appeared in Proceedings of Seventh International Conference on Very Large Databases, Sept. 1981. Published by Tandem Computers Incorporated.
26. © 2019, Amazon Web Services, Inc. or its Affiliates. It’s an immutable time-series – You can build an event store Time Who What 2019 06 21 08 07 06 Customer-123 CustomerCreated 2019 06 21 08 07 09 Order-234 OrderCreated 2019 06 21 08 07 13 Order-234 PaymentSuccessful 2019 06 21 08 07 17 Customer-123 CustomerUpdated . . . . . . . . .
27. © 2019, Amazon Web Services, Inc. or its Affiliates. Event sourcing Create Order Get Order Event Store Events ?
28. © 2019, Amazon Web Services, Inc. or its Affiliates. Event sourcing + CQRS Create Order Get Order Event Store Projection Commands Queries Events Reserve Item Process Payment Start Order Delivery Cancel Order *Command Query Responsibility Segregation *
29. © 2019, Amazon Web Services, Inc. or its Affiliates. © 2019, Amazon Web Services, Inc. or its Affiliates. How can we simplify event processing? Photo by Adam Jang on Unsplash
30. © 2019, Amazon Web Services, Inc. or its Affiliates. TweetSource: Type: AWS::Serverless::Application Properties: Location: ApplicationId: arn:aws:serverlessrepo:... SemanticVersion: 2.0.0 Parameters: TweetProcessorFunctionName: !Ref MyFunction SearchText: '#serverless -filter:nativeretweets' Nested apps to simplify solving recurring problems Standard Component Custom Business Logic aws-serverless-twitter-event-source app Polling schedule (CloudWatch Events rule) trigger TwitterProcessor SearchCheckpoint TwitterSearchPoller Twitter Search API
31. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS Event Fork Pipelines https://github.com/aws-samples/aws-serverless-event-fork-pipelines Amazon SNS topic Event storage & backup pipeline Event search & analytics pipeline Event replay pipeline Your event processing pipeline filtered events events to replay all events Standard Components Custom Business Logic
32. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS Event Fork Pipelines – Event Storage & Backup Pipeline sns-fork-storage-backup app Amazon S3 backup bucket fan out filtered events Amazon SNS topic Amazon SQS queue AWS Lambda function
33. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS Event Fork Pipelines – Event Search & Analytics Pipeline sns-fork-search-analytics app Amazon S3 dead-letter bucket fan out filtered events Amazon SNS topic Amazon SQS queue AWS Lambda function Kibana dashboard Store dead-letter events
34. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS Event Fork Pipelines – Event Replay Pipeline sns-fork-message-replay app fan out filtered events Amazon SNS topic Amazon SQS replay queue AWS Lambda replay function Your regular event processing pipeline Amazon SQS processing queue enqueue events to replay Your operators enable/disable replay reprocess events…
35. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS Event Fork Pipelines – E-Commerce Example
36. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS Event Fork Pipelines in the Serverless Application Repository
37. Photo by J W on Unsplash Can we help more?
38. © 2019, Amazon Web Services, Inc. or its Affiliates. Amazon EventBridge A serverless event bus service for SaaS and AWS services • Fully managed, pay-as-you-go • Native integration with SaaS providers • 15 target services • Easily build event-driven architectures N ew
39. © 2019, Amazon Web Services, Inc. or its Affiliates. Amazon EventBridge Event source SaaS event bus Custom event bus Default event bus Rules AWS Lambda Amazon Kinesis AWS Step Functions Additional targets
40. © 2019, Amazon Web Services, Inc. or its Affiliates. Amazon EventBridge AWS services Custom events SaaS apps Event source SaaS event bus Custom event bus Default event bus Rules AWS Lambda Amazon Kinesis AWS Step Functions Additional targets "detail-type": "source": "aws.partner/example.com/123", "detail": "ticketId": "department": "creator":
41. © 2019, Amazon Web Services, Inc. or its Affiliates. Amazon EventBridge AWS services Custom events SaaS apps Event source SaaS event bus Custom event bus Default event bus Rules AWS Lambda Amazon Kinesis AWS Step Functions Additional targets "detail-type": "source": "aws.partner/example.com/123" "detail": "ticketId": "department": "creator": "source":
42. © 2019, Amazon Web Services, Inc. or its Affiliates. Amazon EventBridge AWS services Custom events SaaS apps Event source SaaS event bus Custom event bus Default event bus Rules AWS Lambda Amazon Kinesis AWS Step Functions Additional targets "detail-type": "source": "aws.partner/example.com/123", "detail": "ticketId": "department": "billing" "creator": "detail": "department": ["billing", "fulfillment"]
43. © 2019, Amazon Web Services, Inc. or its Affiliates. Amazon EventBridge AWS services Custom events SaaS apps Event source SaaS event bus Custom event bus Default event bus Rules AWS Lambda Amazon Kinesis AWS Step Functions Additional targets "detail-type": "Ticket Created" "source": "aws.partner/example.com/123", "detail": "ticketId": "department": "billing", "creator": "detail-type": ["Ticket Resolved"]
44. © 2019, Amazon Web Services, Inc. or its Affiliates. Common use cases
45. © 2019, Amazon Web Services, Inc. or its Affiliates. Common use cases
46. © 2019, Amazon Web Services, Inc. or its Affiliates. Amazon EventBridge integration partners
47. © 2019, Amazon Web Services, Inc. or its Affiliates. Takeaways Events give a time series of immutable facts Commands change structure, events broadcast behavior Events minimize coupling and increase autonomy Be asynchronous and embrace eventual consistency Simplify distributed transactions with sagas and state machines Compose serverless apps, quickly plug in event fork pipelines Use events to bridge internal and external applications
48. © 2019, Amazon Web Services, Inc. or its Affiliates. © 2019, Amazon Web Services, Inc. or its Affiliates. Thank you! @danilop Please give me your feedback