Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

Danilo Poccia

June 21, 2019
Tweet

More Decks by Danilo Poccia

Other Decks in Programming

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

    View full-size slide

  2. How does
    Serverless
    work?
    Photo by Mervyn Chan on Unsplash

    View full-size slide

  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

    View full-size slide

  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
    . . . . . .

    View full-size slide

  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

    View full-size slide

  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”

    View full-size slide

  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”

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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…”

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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!

    View full-size slide

  15. CAP theorem
    Consistency
    Partition
    Tolerance
    Availability
    CA CP
    AP

    View full-size slide

  16. CAP theorem
    Consistency
    Partition
    Tolerance
    Availability
    CA CP
    AP

    View full-size slide

  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" }

    View full-size slide

  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" }

    View full-size slide

  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" }

    View full-size slide

  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" }

    View full-size slide

  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" }

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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”

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  34. © 2019, Amazon Web Services, Inc. or its Affiliates.
    Distributed Sagas – State Machine
    AWS Step
    Functions
    T1
    T2
    C1

    View full-size slide

  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.

    View full-size slide

  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
    . . . . . . . . .

    View full-size slide

  37. © 2019, Amazon Web Services, Inc. or its Affiliates.
    Event sourcing
    Create
    Order
    Get
    Order
    Event
    Store
    Events
    ?

    View full-size slide

  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
    *

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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…

    View full-size slide

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

    View full-size slide

  46. © 2019, Amazon Web Services, Inc. or its Affiliates.
    AWS Event Fork Pipelines in the Serverless Application Repository

    View full-size slide

  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

    View full-size slide

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

    View full-size slide