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

Choreography vs Orchestration in serverless microservices (short version)

Choreography vs Orchestration in serverless microservices (short version)

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.

Ce3e7802c882fca3f9160768f57ae116?s=128

Mete Atamel

April 20, 2021
Tweet

Transcript

  1. Choreography vs Orchestration in serverless microservices Mete Atamel Developer Advocate

    at Google @meteatamel atamel.dev speakerdeck.com/meteatamel
  2. Choreography vs Orchestration

  3. 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
  4. 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?
  5. 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
  6. Imagine a more complex transaction

  7. 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?
  8. 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
  9. 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 still independent Cons ➖ A new orchestrator service to worry about ➖ Orchestrator could be a single point of failure ➖ Reliance on REST means more tight-coupling
  10. Choreography or Orchestration?

  11. It depends... Choreography Services are not closely related Services can

    exist in different bounded contexts 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?
  12. Hybrid approach Orchestrated bounded contexts communicating via events Orchestrated Bounded

    Context Message Broker Orchestrated Bounded Context Orchestrated Bounded Context
  13. Landscape

  14. 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...
  15. Orchestration AWS: Step Functions Azure: Logic Apps Google Cloud: Workflows,

    Cloud Composer Other: Apache Airflow
  16. 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
  17. Orchestration: Google Cloud Workflows

  18. Serverless Compute External API’s Google API’s etc... Workflows - orchestrate

    & integrate SaaS API’s Private API’s Other Clouds
  19. - 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
  20. 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
  21. 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
  22. 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
  23. Other useful features Subworkflows to encapsulate common reusable flows Connectors

    ßeta to connect to other Google Cloud services & APIs
  24. Deploy, execute, manage workflows # Deploy a workflow gcloud workflows

    deploy my-workflow --source=workflow.yaml # Execute a workflow gcloud workflows execute my-workflow # See the result gcloud workflows executions describe <your-execution-id> --workflow my-workflow
  25. None
  26. Case study: Pic-a-daily, A microservice-based picture sharing application

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

  28. Choreographed (event-driven) architecture

  29. Orchestrated architecture

  30. Lessons learned

  31. 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)
  32. 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
  33. Cloud Workflows cloud.google.com/workflows Pic-a-Daily Serverless Workshop g.co/codelabs/serverless-workshop Pic-a-Daily Code github.com/GoogleCloudPlatform/serverless-photosharing-workshop

    Thank you Mete Atamel @meteatamel atamel.dev speakerdeck.com/meteatamel