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.

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