Michael Delzer Updated by Michael Delzer

Automation Hub

Enables toolset-agnostic automation of software stack components and cloud services. Provides good modularity and reduced complexity of assembling & supporting stacks of components.

Cloud Service

Platform service provided by a third party (e.g. S3, EBS, EFS, RDS, GitHub, PagerDuty, Splunk, Evident.io).

Control Plane

Web-based administration UI and API that provides end users with the ability to monitor and manage stacks, stack instances, environments, cloud accounts.

Domain Model

Stack domain model provides the basis for deep understanding of components, containers, connectivity, cost, and function. This gives its customers the ability to create customized stacks from best-of-breed components, and to substitute components as necessary. Components are auto-configured for deploy, upgrade, rollback, promote, clone, backup, test script generation, merging, load testing, security testing and functional testing.


A set of components that work together to give base services for some functionality that is complete in being secure, fault-tolerant, self-healing.

We base our name and the value we bring to customers by allowing them to operate at this higher conceptual level of related components. Stacks are platforms on which other software can be built. We allow companies to pick the components and cloud services they want, and then automatically create the automation scripts that are required to execute them. These software stacks can then be monitored and managed through a web-based Control Plane.

We allow automated operations on stacks such as compose, clone, deploy, rollback, test functional, test security, test performance and others. We allow people to look at their usage of a component, aggregated components across stacks, or stacks and other ways.

Stack Template

A set of automation scripts based on selected stack components and additional user-defined automation tasks. Stack template allows the User to define an architecture – including built-in management, security best practices, architecture governance.

Once the user selects a stack, she might want to customize it. As a result she will create a copy of the stack with some specifics that can be instantiated multiple times (see Stack Instance).

We store “Infrastructure as Code” stack template baseline in a Git repository. This allows the user to trace all changes and create instances of a stack form any revision.

Stack Instance

A stack that has been configured and deployed or referred to an environment. Stack instance is often implemented as a cluster of virtual machines or physical servers and provides a platform on which other software can be deployed.

Stack instance has been created from a stack template with configuration parameters applied.

Stack has the following high-level states:

  • unconfigured
  • configured
  • deploying
  • deployed
  • degraded
  • repairing
  • destroying
  • destroyed

Additionally, a number of lifecycle operations could be in-flight, like check, repair, component replace, etc.

Stack Component

Building block of a stack (e.g. Jenkins, Traefik, etcd, SSL).

Platform Stack

A stack with Kubernetes services which can be used as a platform on which Application Stack is deployed. stack-k8s-aws is an example of Platform Stack. We also want to import external implementations (instances) of Kubernetes as Platform - GKE, EKS, bare-metal.

Adapter Stack

A Stack Template to adapt specific Kubernetes implementation to common Platform contract, ie. provide a well defined set of outputs, install required services, bind DNS, etc.

Application Stack

A stack that relies on Platform Stack to provide baseline capabilities: currently Kubernetes, Ingress (Traefik) with DNS, and Tiller (Helm). Specific Platform Stack outputs: kubernetes.api.*, component.ingress.*, etc. become input parameters for Application Stack to serve as a binding between the stacks.


While Stack address vertical integration of components, Applications are meant to be pushed through Environments - Dev, QA, Prod - by CI / CD pipeline (currently Jenkins) to address horizontal development flow. Application itself is a stack from Hub CLI lifecycle perspective and can contain additional components.

For example, if we start from a bare-metal cluster, we first import it by deploying Adapter Stack to provide Platform Stack contract. Then Application Stack (or stacks) could be deployed to provide application specific services, like security, messaging and persistence. Then Applications are deployed. Applications are leafs of the deployment tree and communicate / bind to each other - if necessary - through messaging / API and Service Mesh.

Application Template

Provides a building basis for application. Application Template defines a scenario for application. Example scenario for HTML5 application:

Scenario: create S3 bucket, new Git repository, and CI/CD pipeline that will automate build and deploy from git to S3 bucket. Application Template has number of components that will do the following:

  • Create a new repository (requires git)
  • Push application code to the repository (requires git)
  • Create S3 bucket with Route53 (requires aws)
  • Create Jenkins CI/CD pipeline (requires jenkins)
  • Start build process (requires jenkins). Jenkinsfile will do build, test and deploy.

Service Mesh

An infrastructure service to provide binding and communication between independently deployed Applications. We're currently looking onto Istio.

Community Version

A version with all open source components – free of charge, and no support other than posting to community support lists is provided. These versions are billed based on cloud usage costs. This kind of stack will be missing some advanced control plane or DevOps functions, possibly. For instance, we may offer only simple deployments, not canary or other. It may not have high security options.

Enterprise Version

A version of a stack with full functionality. Enterprises would need including better security options and the possibility of buying the enterprise rather than community versions of components. Support licenses can also be purchased optionally. These stacks are charged as a fixed fee per instance or with bundles of dev/test/prod instances in a single price.

Stack Reactor

Service of Control Plane to generate Stack Templates.

Super Template

Internals of the reactor. This is the source based on which Stack Reactor will generate stack templates. The user will make a series of choices that will impact how Terraform code (for instance) will look like.

In the future, Enterprise customers will be able to define their own Super Templates and make them part of the Reactor.


Action (or automation task) that has been triggered by the Automation Hub and handled by a Stack Component:

  • deploy - deploy a new component or stack.
  • undeploy - undeploy the component or stack. Once this process has started there is no going back.
  • clone - create a copy of a stack instance with slightly different attributes (for example in a different region or with different VM sizes).
  • status - return currently known status of the stack, like deployed, possibly performing component=specific actions to inspect stack internals.
  • check and repair - perform checks to diagnose stack problems, optionally repairing it (by triggering component replace).
  • upgrade, update the stack template version of individual component to the desired version
  • rollback, reverse update operation back to the previous version of stack template or component
  • backup - backup stack data, so that a new instance could be provisioned from the saved state.
  • restore - deploy with data snapshot.


Environment is a group of resources that has been shared between multiple stacks. Environment contains everything that the user cares about ("pets") and will be upset if she will lose it. While we presume that Stack Instance lifetime is relatively short ("cattle", Stacks are created and destroyed at will), some things should persist:

  • Name: for example, "DEV01", "DEVTEST", "Staging", "StressTest", etc.
  • Cloud Account (one or multiple). This is specific to a given environment. A user is able to enroll one or multiple cloud accounts (AWS Access, Secret keys, Shared IAM roles, GCE account etc).
  • Secrets: a secret can be something as simple as an SSH key for EC2 access, however this can be more complex: SSL certificate, DB password, etc. Secrets have a rotation policy.
  • Domain names: a user should be able to associate one or many domain names with one environment.
  • User Teams and permissions: A user should be able to associate one or multiple teams of users with one concrete environment. She also can specify permissions and access rights. ("Full access", "Can create stack instances", "Can access stack instance", etc)
  • Client VPN connectivity
  • Other attributes (key-value pairs)
  • Tags

How did we do?

Create a Cloud Account