Skip to main content

Atmos is a workflow automation tool

Atmos is a workflow automation tool for DevOps that makes it more manageable to operate very large environments with DRY configuration.

Get Started      Live Demo

Why Atmos?​

With so many of these tools today, why does the world need another "workflow" automation tool?

That's simple. None of them pull off what you can do with Atmos.

To fully understand why, it may be helpful to understand some background. Atmos is a tool created by Cloud Posse. We are DevOps Accelerator for Startups (typically venture-backed, later-stage series A-D companies) and enterprises. We help our customers own their infrastructure using our reference architecture blueprints and implement it with their teams while showing them the ropes. We needed to scratch our own itch. After trying everything, we realized it would not be possible to achieve the outcome we wanted for our customers using a mashup of existing off-the-shelf tools. That's why we created Atmos.

TL;DR​

  • Businesses need to capture their processes as workflows
  • Terraform configuration is difficult to manage at scale
  • Terraform by itself is not enough to be successful
  • Atmos makes managing those configurations easier

Use Cases​

Atmos is ideally suited for these use-cases.

  • Terraform Automation and Collaboration (TACOs)
  • Large Multi-Account Environments
  • Resilient Multi-Region Cloud Deployments
  • Implement Guardrails with Policy as Code (ideal for enterprise environments!)
  • Enable Team Autonomy with Self-Service with Infrastructure as Code
  • Provide Service Catalogs, Landing Zones and Architectural Blueprints

Don't see your use-case listed? Ask us in the #atmos slack channel.

Atmos Gives Terraform Super Powers​

Businesses succeed because of their processes. Those processes need to be captured through workflows.

The reason is that workflows give teams superpowers without needing to be superheroes. Let's face it: human error is the number one risk businesses face. It's the root cause of most outages and can strike anytime.

The best workflows enable anyone, anywhere, to run them. They are easily understood, self-documenting and ensure fewer mistakes get made. When workflows are written down, they can be iterated upon and optimized.

  • Write components (root modules) once, reuse any number of times
  • Vanilla HCL without customizations
  • Use our terraform provider to read YAML configurations from anywhere
  • Easily deploy across any number of regions without touching a line of HCL
  • Duplicate entire stacks by just copying a single YAML file
  • Generate YAML configurations e.g. Cookie Cutter, Service Now

We Built Atmos to Solve Our Problems​

Cloud Posse works with many customers who have a diverse set of requirements. We couldn't consistently deliver the outcomes we wanted using the existing tools on the market. Since everything we build at Cloud Posse is designed to be reusable across organizations, we needed something that allowed us to replicate configurations without repetitive steps and editing.

Here are some of the problems we needed to solve...

  • How to support many teams concurrently across multiple organizations.
  • How to automate our deliverables so that teams could own them.
  • How to engineer an extensible tool that could handle unknown-unknown requirements.
  • How to design an easy to use tool that was stable and consistent (aka testable)

Atmos Differentiators​

Zero Vendor Lock-in for Terraform​

When you use Atmos there is zero vendor lock-in. This is because Atmos does not require changing (harming) any Terraform code in order to run. Every terraform component is just a vanilla HCL terraform "root" module. Atmos is simply handling the complexity associated with managing hierarchical configurations.

info

By running a single command, you can eject from Atmos and never touch it again.


Why not give Atmos a try?

Designed for Configuration @ Scale​

Most tools suffer when configurations get large and complex. They are not optimized for this; Terraform is a prime example.

Atmos solves this by introducing powerful capabilities most tools lack.

  • Hierarchical configurations to reduce complexity
  • DRYness with inheritance and imports
  • Team collaboration with reusable service catalogs
  • Reusable workflows that run anywhere
  • Consistent command line interface that can combine multiple tools into one command (atmos)
  • A single binary, cross-compiled for every architecture (golang) and easily installed.

YAML Configuration​

So, why did we choose YAML? That's simple: everyone knows YAML.

YAML is an extensible markup language. It's ideal for defining a declarative DSL.

Using YAML, atmos is easily able to support features like imports, inheritance, deep merging, and policies.

YAML is also "tool agnostic" (unlike HCL); it's not tied to Terraform or explicitly associated with HashiCorp products.

  • Every language can read it (e.g. from python or node. Even read it remotely, e.g. via http)
  • Every language can write it (e.g. generate it from a web UI)

There are other cool things we get "for free" by adopting YAML.

The possibilities are endless.

Supports Guardrails Out-of-the-box​

Configuration "at scale" requires policies and validation. To err is human. No one reads all the docs. We must clarify expectations using "policies as code" and "shift left" to raise errors early.

Atmos supports OPA to lay down the law and enforce it.

For example, here are some things that are possible:

  • Never allow some value in a particular environment
  • Never allow two types of things to be deployed concurrent in staging
  • Never allow a team to deploy some component
  • Never allow production to use unstable versions of components

The possibilities are endless.

Supports Multiple Inheritance​

  • Make configuration hierarchical with imports and deep merging.
  • Organize it anyway that make sense for your organization.
  • Define logical groups of configuration
  • Define something once and reuse it.
  • Know exactly where configuration differs.

The Problems with Tools​

Generalized Tools Always Suffer​

A generalized tool will always suffer for a specialized use case, even Atmos and its custom workflows. That’s why we wrote it all in Golang, and implemented opinionated workflows for the tools we use like terraform and helmfile. We also acknowledged that not everyone knows Golang, so we created a porcelain-style plugin interface (inspired by Helm, which itself is partially modeled on Git's plugin model). This enables you to write your commands in any language, but expose them through the Atmos CLI interface for a standard CLI UX. Or better yet, it's possible to combine both the built-in workflows for terraform and helmfile with the custom workflows.

We like to think this tool gives us superpowers. It’s definitely attributable to our meteoric success of the past couple years and we want that to be yours too.

Terraform by itself does not scale​

There are many problems encountered by teams working with Terraform at scale.

  • Terraform GitOps (CI/CD) for teams is non-trivial
  • Terraform configuration is not DRY
  • Terraliths are a terraform anti-pattern, yet…
  • Terraform “root modules” are not easily shared
  • Terraform has no native support for multiple root modules (dependency ordering)
  • Terraform backend configurations cannot be parameterized
  • Terraform lacks built-in guardrails & policy controls that enterprises need

The Solution​

Use Atmos​

Atmos is part of the solution because:

  • Opinionated workflows for terraform
  • Established conventions and patterns to manage terraform @ scale
  • Break terraliths into smaller pieces (“components”)
  • Enable team collaboration with catalogs and libraries
  • Enforce guardrails with OPA and JSON Schema
  • Zero Vendor Lock-in

Established Conventions​

Part of the benefit of working with Atmos is we have many established conventions that you can adopt.

Here are some of the examples:

  • Components: these are the fundamental building blocks. For terraform, these are opinionated terraform “root modules”.
  • Stacks: these are the combination of components into an architecture.
  • Catalogs: these are collections of reusable stack configurations.

It's All Open Source (APACHE2)​

Best of all Atmos is open-source with an active community supporting it. There are no strings attached, and it's under active development with hundreds of stars.

There's also an ecosystem of tools that it works with, and Terraform modules downloaded tens of millions of times.

We invite you to join us in the larger movement and impact the industry at large.

What Atmos is Not...​

It might help to also understand what Atmos is not attempting to replace:

  • Atmos is not an alternative to tools like terraform, kubectl, chef, puppet, or ansible. Instead, atmos is the type of tool that would orchestrate these tools.
  • Atmos is not an alternative to CI/CD systems. If anything, those systems will still call Atmos.

Live Demo of Atmos​

Here's a live demo we did on our weekly "Office Hours".


Next Steps​