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
docker-compose up --build should be sufficient
- Make the API mock up call a workflow
- Framework to test workflows
- Seems fairly simple once you get the notions
- Framework to test workflows
- Presentation of Cadence @Uber Open Summit 2018
- Website
- Doc
- API
- Samples
- Building your first Cadence Workflow
- Testing
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