BOSH is an open source tool for release engineering, deployment, lifecycle management, and monitoring of distributed systems. As such it’s very similar in scope to Escape, but takes a different approach.

In BOSH releases are built on top of stemcells which provide a cross-cloud baseline to build on. A BOSH Director is used to track versions, deploy releases and monitor and heal deployed virtual machines. To make this all work the ecosystem prescribes various components and ways of working; it is opinionated about how things should be done.

BOSH is mainly used to work with Virtual Machines, but its release engineering capabitilies can’t be used to do Containers, Serverless, etc. Escape takes a more generic approach, which does make working on those layers possible. It does mean Escape has to forgo on some of the healthchecking and self-healing capabitilies, as they can’t be tackled in a generic way that work across all layers, but if releases do need these capabilities they can be develop as normal packages and imported (or extended) where needed.

For that same reason Escape has no built-in concept of stemcells, but once again we can achieve a similar result by building a cross-cloud base image using regular Escape releases (that use packer and ansible for example, see more below).

Chef, Ansible, Puppet and Salt (CAPS) are configuration management tools. Generally they bring existing machines into some desired state by e.g. installing packages, starting services and writing files. Some of these tools also support creating the machines and other bits of cloud infrastructure, but generally they’re best used on existing machines.

Escape is not meant to replace these tools, but can wrap around them to add packaging, versioning, dependency management, environment promotions, etc. For example, using Escape we could combine a Terraform package that creates a machine with an Ansible package that brings it into its desired state, and make it possible to manage this as one logical unit.

Some (most) of these tools also provide some sort of package and dependency management, but only for other CAPS code. For example: you could get your Ansible dependencies from the Ansible Galaxy, but not your Terraform code. Escape is able to consolidate your Infrastructure as Code behind one cohesive release process.

Terraform is a tool to write, plan, and create Infrastructure as Code and Packer is a tool to build automated machine images. Escape is not meant to replace either of these tools and at Ankyra we actually use them quite heavily. Combining Escape and Terraform/Packer makes it possible to promote images and cloud infrastructure from test environments to production, and have this be part of the regular delivery pipeline.

Terraform itself also supports modules which makes it possible to componentize Terraform code. We have however found that splitting components out into Escape releases works quite nicely as well, as this allows you to deploy, promote and manage the components as its own unit instead of one giant Terraform codebase. Although Terraform handles big code bases quite well, the deployment times start adding up. The other advantage of splitting things out is that it’s easier to enforce ACL.

Using Escape, Packer and Terraform together we can cleanly fit a virtual machine image release process into a terraform release process, which is something that usually takes some ad-hoc scripting to achieve. We can go even further and have our Packer build depend on CAPS code mentioned above, which can be nice if you’re doing multi-cloud builds (which is like building your own stemcell, as mentioned in the BOSH section).

Helm is a package manager for Kubernetes specifications providing popular software packaged for Kubernetes.

Escape can also work as a package manager for Kubernetes specifications, and in fact there’s an extension for that. When Escape is used like that, and just for that, there aren’t many differences between Helm and Escape, except that Escape doesn’t use a server process (ie. tiller) on each cluster.

Escape can also wrap around Helm and provide lifecycle management for its charts; in fact there’s an extension for that as well. This allows you to promote Helm charts from the community or your own organisation throughout your environments and relate it to the rest of your platform (e.g. Kubernetes versions, cloud configuration, etc.)

These are tradional package managers. Some of them have more overlap with Escape than others, but these are mainly used to manage files and services on a local file system; they don’t have a concept of environments or deployments, just local installations.

Escape takes a more generic view and separates deployment state from packages, enabling environments, unattended deployments, providers and consumers, etc.

You could use Escape to work with these package managers, but nowadays you’d probably use the CAPS tools mentioned above. You could, maybe, also use apt to implement cloud deployments, but at that point you’re back into ad-hoc scripting territory so you might as well Escape.