Skip to main content

Terminology

Before you start on your Stack Automation journey, please take a moment to familiarize yourself with Stack Automation's key concepts and infrastructure components. This article lists the main concepts you will come across in Stack Automation, while the Architecture article that follows provides a diagram of the Stack Automation architecture and its main components.

  • Blueprint - An offline plan (template) for a deployment that defines the applications, cloud infrastructure, networking and policies that make up the deployment. Blueprints are defined in source-controlled YAML files and contain grains. Each grain represents a specific workload (for example, a Terraform module or a Helm chart). The blueprint defines the orchestration between the grains (order, dependency, etc.), and provisions a whole deployment, from infrastructure to application. You can have Stack Automation discover (or create) blueprints out of your Terraform, Helm, or other supported IaC assets, or write more complex ones that deploy several assets. For details, see Blueprint Quickstart Guide.

    • Grain - The Stack Automation representation of an asset (e.g. Terraform module or Helm chart). Each grain contains all the information required to deploy the asset, such as inputs and versions, as well as a reference to the location of the asset's code (repository).

    • Deployment - A deployment is a live instance of a blueprint. It contains the cloud infrastructure and application(s) that were deployed from the blueprint. The deployment has a defined duration that can be manually extended or ended, as well as links to its applications, automation commands to run on the different cloud resources.

    • Repository - A git-based folder containing the IaC assets, container files and multi-asset blueprints that make up the Stack Automation self-service catalog, and are consumed by your end-users. For details, see Architecture.

  • Policies - Stack Automation policies allow setting an additional layer of governance on top of blueprints and the active deployments. These include:

    • Blueprint consumption policies allow blueprint designers to set maximum duration guardrails (for high-cost deployments perhaps).
    • Policies allow the Stack Automation account admin to set account-level limitations on AWS-created deployments.

  • Space - A logically separate area that contains an association to one or more Management Servers, asset repositories, a blueprint repository and Ci/CD plugins. Spaces can be used to logically separate between teams, projects, or even development lifecycle stages and allow the relevant end-users, administrators and blueprint designers to access only the relevant blueprints and deployments.

  • Tag - A key-value pairing that is set by Stack Automation to all of the resources and infrastructure entities provisioned in a deployment (example: Owner = John.D@somecompany.com). There are 2 types of tags: System tags and custom tags. System tags are tags that are defined by Stack Automation (for example, deployment id, space name, etc) while the users define the custom tags according to their needs.

  • Management Server - A Stack Automation Management Server that runs as a pod inside your designated Kubernetes cluster. This Management Server communicates with the Stack Automation backend and is permitted to perform certain actions on your Kubernetes cluster. For more details, see Architecture.