Diving deep into the event-driven side of Serverless

Diving deep into the event-driven side of Serverless

ServerlessDays, Milan, June 21st, 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 to 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.

7c9b8b368924556d8642bdaed3ded1f5?s=128

Danilo Poccia

June 21, 2019
Tweet

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 ”CreateUser” “AddProduct” What happens Domain events Event-driven Autonomy ”UserCreated” “ProductAdded”
  7. © 2019, Amazon Web Services, Inc. or its Affiliates. Commands

    Vs Events Commands Has an intent Directed to a target Personal communication ”CreateUser” “AddProduct” Events It’s a fact For others to observe Broadcast one to many ”UserCreated” “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
  10. What can more functions do together? A microservice Function Service

    Event Service Function Function Microservice Storage / Database Event Replacing 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. CAP theorem Consistency Partition Tolerance Availability CA CP AP

  16. CAP theorem Consistency Partition Tolerance Availability CA CP AP

  17. CAP theorem – Partition Tolerance Consistency Partition Tolerance Availability CA

    CP AP Node failure affects data in a single partition { id: 123, version: 3, data: "Hello" } { id: 123, version: 3, data: "Hello" }
  18. CAP theorem – Partition Tolerance Consistency Partition Tolerance Availability CA

    CP AP Network is partitioned, all messages sent from one partition to another are lost { id: 123, version: 3, data: "Hello" } { id: 123, version: 3, data: "Hello" }
  19. CAP theorem – Availability Consistency Partition Tolerance Availability CA CP

    AP { id: 123, version: 1, data: "Bonjour" } { id: 123, version: 3, data: "Hello" } { id: 123, version: 2, data: "Ciao" }
  20. CAP theorem – Consistency Consistency Partition Tolerance Availability CA CP

    AP { id: 123, version: 3, data: "Hello" } { id: 123, version: 3, data: "Hello" } { id: 123, version: 2, data: "Ciao" }
  21. CAP theorem – Consistency Consistency Partition Tolerance Availability CA CP

    AP { id: 123, version: 3, data: "Hello" } { id: 123, version: 3, data: "Hello" } { id: 123, version: 3, data: "Hello" }
  22. © 2019, Amazon Web Services, Inc. or its Affiliates. CAP

    theorem We need Partition Tolerance to protect our data We need Availability to serve our customers . . . Consistency Partition Tolerance Availability CA CP AP
  23. © 2019, Amazon Web Services, Inc. or its Affiliates. CA

    CP CAP theorem We have to compromise on Consistency 2 Phase Commits? No, thanks! Welcome Eventual Consistency Idempotency at our rescue Consistency Partition Tolerance Availability AP
  24. Werner Vogels, ACM QUEUE October 2008 “the storage system guarantees

    that if no new updates are made to the object, eventually all accesses will return the last updated value”
  25. © 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
  26. © 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
  27. © 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
  28. © 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
  29. © 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
  30. © 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 D LQ
  31. © 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
  32. © 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
  33. © 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
  34. © 2019, Amazon Web Services, Inc. or its Affiliates. Distributed

    Sagas – State Machine AWS Step Functions T1 T2 C1
  35. © 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.
  36. © 2019, Amazon Web Services, Inc. or its Affiliates. 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 . . . . . . . . .
  37. © 2019, Amazon Web Services, Inc. or its Affiliates. Event

    sourcing Create Order Get Order Event Store Events ?
  38. © 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 Undo Events *Command Query Responsibility Segregation *
  39. © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. How to simplify event processing? Photo by Adam Jang on Unsplash
  40. © 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
  41. © 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
  42. © 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
  43. © 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
  44. © 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…
  45. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS

    Event Fork Pipelines – E-Commerce Example
  46. © 2019, Amazon Web Services, Inc. or its Affiliates. AWS

    Event Fork Pipelines in the Serverless Application Repository
  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
  48. © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. Thank you! @danilop