Flows

In Kardinal, a flow is an ephemeral environment that developers can use for development, testing, or QA.

The default flow in Kardinal is called baseline, and typically contains the latest versions of each service that you have in your staging cluster, i.e. the latest changes that are about to be promoted to production.

When Kardinal creates a flow, it will deploy the set of services that encompass the changes being made for a given feature. Kardinal will also create an ingress point for the developer to use.

Any communication made through the ingress point will be routed to the versions of the services that are a part of the flow. Any services that are a part of the application, but aren't being changed as a part of the feature, will still be available from the baseline flow.

As your team onboards to Kardinal, you will be able to create flows with escalating levels of configurability:

  1. Single-service flows: deploy a single service to test a new version of a service, sharing application state with all other flows
  2. Multi-service flows: deploy a set of services together to test a larger feature change involving multiple services, sharing application state with all other flows
  3. State-isolated flows: deploy a set of services together with new, isolated state (dbs, caches, queues) to test database migrations or other state-layer changes
  4. Full application flows: deploy an independent, full application with its own state layer for completely isolated end-to-end testing

Getting more advanced flows requires defining more of your application's topology in Kardinal:

Flow TypeOnboarding Requirements
Single-service flowsYour service implements distributed tracing
Multi-service flowsA subset of your services implement distributed tracing
State-isolated flowsA subset of your services implement distributed tracing, explicitly define their service dependencies, and you use state isolation plugins for all state and managed services
Full application flowsAll of your services implement distributed tracing, explicitly define their service dependencies, and you use state isolation plugins for all state and managed services

The cost savings of the final two use cases (isolating state between flows) can reach into the millions of dollars for large organizations who use isolated dev sandboxes for ephemeral environments.

To see how, and to calculate savings for your own organization, check out our cost savings dashboard hosted on Streamlit. (If the dashboard is "sleeping", just click to wake it up!)