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

Choreography vs Orchestration in serverless microservices

Choreography vs Orchestration in serverless microservices

We went from a single monolith to a set of microservices that are small, lightweight, and easy to implement. Microservices enable reusability, make it easier to change and scale apps on demand but they also introduce new problems. How do microservices interact with each other toward a common goal? How do you figure out what went wrong when a business process composed of several microservices fails? Should there be a central orchestrator controlling all interactions between services or should each service work independently, in a loosely coupled way, and only interact through shared events? In this talk, we’ll explore the Choreography vs Orchestration question and see demos of some of the tools that can help.

Mete Atamel

January 29, 2021
Tweet

More Decks by Mete Atamel

Other Decks in Programming

Transcript

  1. Choreography vs Orchestration
    in serverless microservices
    Mete Atamel
    Developer Advocate at Google
    @meteatamel
    atamel.dev
    speakerdeck.com/meteatamel
    Guillaume Laforge
    Developer Advocate at Google
    @glaforge
    glaforge.appspot.com

    View Slide

  2. Choreography vs Orchestration

    View Slide

  3. CHOREOGRAPHY ORCHESTRATION

    View Slide

  4. Imagine a simple e-commerce transaction
    Services calling each other directly
    Frontend
    App Engine
    Order request
    Payment Processor
    Cloud Run
    Authorize & charge CC
    Shipper
    Cloud Functions
    Prepare & ship items
    Notifier
    Cloud Run
    Notify user

    View Slide

  5. Simple REST: Pros and Cons
    Pros
    ➕ Better than a single monolith
    ➕ Easy to implement: Services
    simply call each other
    Cons
    ➖ Too much coupling between all
    the services
    ➖ Each service can be a SPOF
    ➖ Each service needs its own error /
    retry / timeout logic
    ➖ Who ensures the whole
    transaction is successful?

    View Slide

  6. Choreography (event-driven)
    Event-driven services
    Frontend
    App Engine
    Order request
    Payment Processor
    Cloud Run
    Authorize & charge CC
    Shipper
    Cloud Functions
    Prepare & ship items
    Notifier
    Cloud Run
    Notify user
    Message Broker

    View Slide

  7. Imagine a more complex transaction

    View Slide

  8. Choreography: Pros and Cons
    Pros
    ➕ Services are loosely coupled,
    ➕ Services can be changed
    independently
    ➕ Services can be scaled
    independently
    ➕ No single point of failure
    ➕ Events are useful to extend the
    system beyond the current domain
    Cons
    ➖ Difficult to monitor the whole system
    ➖ Errors / retries / timeouts are
    problematic
    ➖ The business flow is not captured
    explicitly
    ➖ Who ensures the whole transaction is
    successful?

    View Slide

  9. Orchestration
    Orchestrated services
    Frontend
    App Engine
    Order request
    Payment Processor
    Cloud Run
    Authorize & charge CC
    Shipper
    Cloud Functions
    Prepare & ship items
    Notifier
    Cloud Run
    Notify user
    Orchestrator

    View Slide

  10. Orchestration: Pros and Cons
    Pros
    ➕ Business flow captured centrally
    and source controlled
    ➕ Each step can be monitored
    ➕ Errors / retries / timeouts are
    centralized
    ➕ Use simple REST, no need for
    events
    ➕ Services are independent
    Cons
    ➖ A new orchestrator service to worry
    about
    ➖ Orchestrator could be a single point
    of failure
    ➖ Reliance on REST means more
    tight-coupling

    View Slide

  11. Which one is better?
    Choreography or
    Orchestration?

    View Slide

  12. It depends...
    Choreography
    Services are not closely related
    Services can exist in different
    bounded contexts
    Multiple bounded contexts
    communicating via events
    Orchestration
    Can you describe the business logic
    in a flow chart?
    Are services closely related in a
    bounded context?
    Do you want to stay in REST?

    View Slide

  13. Hybrid approach
    Orchestrated bounded contexts communicating via events
    Orchestrated
    Bounded
    Context
    Message Broker
    Orchestrated
    Bounded
    Context
    Orchestrated
    Bounded
    Context

    View Slide

  14. Landscape

    View Slide

  15. Choreography (event-driven)
    AWS: SQS, SNS, EventBridge
    Azure: Event Grid, Event Hubs, Service Bus
    Google Cloud: Pub/Sub, Eventarc
    Other: Kafka, Pulsar, Solace PubSub+, RabbitMQ, NATS...

    View Slide

  16. Orchestration
    AWS: Step Functions
    Azure: Logic Functions
    Google Cloud: Workflows, Cloud Composer
    Other: Apache Airflow

    View Slide

  17. Serverless Workflow Specification
    serverlessworkflow.io
    A sandbox-level project at CNCF for a specification
    Defines a declarative and domain-specific workflow
    language for orchestrating events and services

    View Slide

  18. Serverless Workflow Specification
    serverlessworkflow.io
    Workflow projects need to implement & support the spec
    Spec doesn’t necessarily cover all aspects of a product and
    not all products cover the whole specification
    Services need to be described with OpenAPI

    View Slide

  19. Orchestration:
    Google Cloud Workflows

    View Slide

  20. Serverless
    Compute
    External
    API’s
    Google
    API’s
    etc...
    Workflows - orchestrate & integrate
    SaaS
    API’s
    Private
    API’s
    Other
    Clouds

    View Slide

  21. - processPayment:
    params: [paymentDetails]
    call: http.post
    args:
    url: https://payment-processor.run.app/...
    body:
    input: ${paymentDetails}
    result: processResult
    - shipItems:
    call: http.post
    args:
    url: https://.../cloudfunctions.net/ship
    body:
    input: ${processResult.body}
    result: shipResult
    - notifyUser:
    call: http.post
    ...
    Payment Processor
    Cloud Run
    Authorize & charge CC
    Notifier
    Cloud Run
    Notify user
    Shipper
    Cloud Functions
    Prepare & ship items
    YAML or JSON syntax

    View Slide

  22. Payment Processor
    Cloud Run
    Authorize & charge CC
    Notifier
    Cloud Run
    Notify user
    Shipper
    Cloud Functions
    Prepare & ship items
    Payment Processor
    Cloud Run
    Authorize & charge CC
    Notifier
    Cloud Run
    Notify user
    Shipper
    Cloud Functions
    Prepare & ship items
    WAIT
    Payment Processor
    Cloud Run
    Authorize & charge CC
    Notifier
    Cloud Run
    Notify user
    Shipper
    Cloud Functions
    Prepare & ship items
    shipmentDetails
    userDetails
    Step Sequencing Serverless Pause
    Variable passing
    JSON Parsing
    Steps

    View Slide

  23. Errors and retries
    Payment Processor
    Cloud Run
    Authorize & charge CC
    Notifier
    Cloud Run
    Notify user
    Shipper
    Cloud Functions
    Prepare & ship items
    MAX: 5 times
    BACKOFF
    Payment Processor
    Cloud Run
    Authorize & charge CC
    Notifier
    Cloud Run
    Notify user
    Shipper
    Cloud Functions
    Prepare & ship items
    Pager
    Cloud Run
    Escalate to support
    SUCCESS ERROR
    Configurable retries Configurable exception handling

    View Slide

  24. Conditionals and 3rd party calls
    Notifier
    Cloud Run
    Notify user
    Shipper
    Cloud Functions
    Prepare & ship items
    Pager
    Cloud Run
    Escalate to support
    SUCCESS
    ERROR
    Out of
    Stock?
    No
    Request from the
    supplier
    Yes
    Read inventory
    Inventory DB
    Update inventory
    Inventory DB
    Supplier API

    View Slide

  25. Other useful features
    Subworkflows
    to encapsulate common reusable flows
    Connectors ßeta
    to connect to other Google Cloud APIs

    View Slide

  26. Deploy, execute, manage workflows
    # Deploy a workflow
    # Execute a workflow
    # See the result

    View Slide

  27. View Slide

  28. Case study: Pic-a-daily,
    A microservice-based
    picture sharing application

    View Slide

  29. Pic-a-daily: A photo sharing application
    g.co/codelabs/serverless-workshop

    View Slide

  30. Choreographed (event-driven) architecture

    View Slide

  31. 3 different event handling approaches

    View Slide

  32. Orchestrated architecture

    View Slide

  33. Lessons learned

    View Slide

  34. Lessons Learned
    ➕ Simple REST was refreshing (vs. 3 eventing formats)
    ➕ Less code (eg. no event parsing, no Image Analysis &
    Garbage Collector functions)
    ➕ Less setup (eg. no Pub/Sub, no Scheduler, no Eventarc)
    ➕ Easier error handling (eg. the whole chain stops on error)

    View Slide

  35. Lessons Learned
    ➖ New service to learn with its quirks and limited docs
    ➖ Code vs. YAML, in a single YAML file
    (code is easier to write and test than YAML!)
    ➖ Debugging / testing / logging is not mature, no IDE support
    ➖ Lost parallelism
    ➖ Loss of eventing flexibility

    View Slide

  36. Cloud Workflows Cloud Workflows tips
    cloud.google.com/workflows bit.ly/gcw-tips
    Quickstart
    cloud.google.com/workflows/docs/quickstarts
    Codelab: Intro to serverless orchestration with Workflows
    codelabs.developers.google.com/codelabs/cloud-workflows-intro
    Thank you
    Mete Atamel
    @meteatamel
    atamel.dev
    speakerdeck.com/meteatamel
    Guillaume Laforge
    @glaforge
    glaforge.appspot.com

    View Slide