cadence-poc

---

Architecture

Everything runs via docker-compose, using the template given by Uber. We expose 3 extra services:

• The API, a dummy API used as an exemple to trigger workflows

• The Preparer, a Cadence Worker which runs a workflow invoked by the API.

  • In theory, this workflow simply checks the data from the API is correct, upload it to vault & set a status in DB for the cronjob

• The CronJob, another Cadence Worker which runs a workflow as a cronjob.

  • This workflow picks up the keys prepared by the preparer and create a PR on GitHub to deploy the validators
  • In theory, it is essentially the gitops manager

• The cmd directory

  • Stores the mains of the 3 services

• The cadence directory

  • Provides a wrapper around Cadence to easily build clients and workers
  • Exposes our workflows & their activities
    • Each workflow has its subdirectory with its function and activities

• The api directory

  • Exposes the dummy API used to call the workflows

---

How To Run ?

docker-compose up --build should be sufficient

---

TODOs

• Make the API mock up call a workflow
  • Framework to test workflows
    • Seems fairly simple once you get the notions

---

Links

• Presentation of Cadence @Uber Open Summit 2018
• Website
• Doc
• API
• Samples
  • Mix API w/ Workflow
• Building your first Cadence Workflow
• Testing

---

Use Cases (-> do we have a use case for it?)

In summary, Cadence fills a lot of use case and could help us scale up; however, at the moment it is simply too big / complex to be worth it.

• Periodic execution -> yes
• Orchestration -> yes
• Polling -> yes
• Event driven application -> yes (does it via signals (not UNIX signals))
• Storage scan -> no?
• Batch job -> maybe?
• Infrastructure provisioning -> no?
• Deployment -> yes (gitops manager essentially become (a) workflow(s))
• Operational management -> no
• Interactive application -> no
• DSL workflows -> no
• Big data and ML -> no

---

• activities: basic unit of work
  • User defined
  • State not recovered in case of failures (shouldn't matter as they should be atomic)
  • Invoked asynchronously through a task list (queue)
• workflow: can execute activities
  • User defined
  • Controls activity exec options (timeout, retry policy, ..., see cadence/workflow.ActivityOptions)
  • Can react to events
  • Can return its internal state through queries
  • The state of the workflow code, including local variables and threads it creates, is immune to process and Cadence service failures.
  • It encapsulates state, processing threads, durable timers and event handlers.
  • How does it work internally ?
• worker: service which hosts a workflow & activities
  • User defined
  • Polls Cadence service for tasks
  • Perform them
  • Report back

---