Over the last ten years there has been increased focus on infrastructure as code (IaC) tooling, primarily driven by the rise of Infrastructure as a Service (IaaS) and API-driven infrastructure. One of the current challenges when working within this space is the requirement to combine multiple tools in order to define, deploy and configure a full platform. InfoQ discussed the challenges of homogenising this tooling with Bart Spaans, founder of Ankyra, who is an expert in the domain of infrastructure and release engineering.
As documented by Keif Morris, a standard pattern when working with IaC is to use an infrastructure automation tool like HashiCorp Terraform or AWS CloudFormation to declare the networks, compute and storage, and then any one of the "CAPS" tooling (Chef, Ansible, Puppet, SaltStack etc) to provide bootstrapping and configuration management. Using multiple tools typically means that teams have to learn more than one technology (and configuration language), and also there can be challenges coordinating and versioning all of the configuration source files.
InfoQ recently sat down with Spaans and asked for his opinion on the current state of infrastructure and release engineering, and also discussed the motivation of creating an alternate tool "Escape", which attempts to overcome some of the shortcomings of current tooling.
InfoQ: Hi Bart, many thanks for taking time to sit down with us today. Could you briefly introduce yourself and the new Ankyra Escape project please?
Bart Spaans: Hi Daniel, thanks a lot. My name's Bart Spaans and I'm the founder of Ankyra, a company focused on automating software delivery. Escape is our Open Source release engineering toolkit that can be used to build, test, version, deploy and operate software across layers, environments and clouds.
Escape was born out of several years of working on cloud infrastructure and delivery pipelines, where we kept seeing same problem: we have all these great clouds, amazing automation tools and time-saving Softwares as a Service, that, in theory, should allow companies to focus on adding business value, but in practice a lot of expensive resources go into making it all work together.
All these layers, tools and services, whilst great on their own, need to be unified into one cohesive platform, which can be quite tricky to do. This is even more so the case when there are multiple environments (CI, perf, demo, staging, ...), microservices, data migrations or other "operationally-heavy" things in play.
What we're trying to do with Escape is tackle that release engineering, configuration and deployment complexity so that you can focus on the things that matter again.
InfoQ: I'm sure a few readers might be wondering how this tool relates to other similar tools like Terraform, Ansible, and Chef etc. Can you explain the difference please?
Spaans: Terraform, Ansible and Chef are examples of tools that target one or more layers in the software stack. For example, Terraform can be used to provision new virtual machines in a cloud environment and Ansible or Chef can be used to configure those machines. These tools are great, and if you can manage everything from within that one tool then you should. However, in modern stacks we're seeing that multiple tools and environments are usually involved in the delivery of a full platform. In this case the problem becomes: how do I orchestrate all these different tools and how do I version and promote the code across environments?
Escape makes it possible to wrap around these tools, split your platform up into logical components, and provide best practice release engineering processes around them. So for the above example you would be able to test and release your Terraform and your Chef/Ansible code separately and then combine together into one cohesive unit again and promote that all the way to your production environment.
InfoQ: Was there any inspiration for this tool taken from Cloud Foundry's BOSH or any of the Google SRE tooling?
Spaans: Absolutely. I think BOSH got a lot of things right in terms of engineering releases and managing environments, but its scope is limited to virtual machines. With Escape we wanted to create a tool that brings versioning, packaging, configuring, deploying and operating software to any layer of the stack.
What I like about Google's SRE tooling is that it's declarative and driven by strong APIs, which is something that has definitely inspired the design of Escape itself.
InfoQ: How important do you think the need for infrastructure management tooling to support multiple cloud vendors is?
Spaans: I think it's important, because it makes easier to migrate between vendors and explore hybrid solutions. Ultimately it's about staying competitive and being able to respond to changes and try new things.
I also think we're going to see some cool stuff in this space with the commoditization of compute and the advance of higher-level abstractions, as seen in Kubernetes and Serverless. The next generation of infrastructure management tools could be able to move workloads based on expected cost or expected network latency for example.
InfoQ: What is the biggest challenge for modern infrastructure and system engineers?
Spaans: The biggest challenge as I see it is managing the complexity and breadth of modern stacks. All of the tools, clouds and services that come into play when delivering an application, including the application code itself, require a certain amount of configuration.
Managing the deployment and configuration of the entire stack, especially when there is more than one environment involved can become very complex, and often results in brittle and expensive ad-hoc solutions. Steering clear of that and building a fast, reliable delivery pipeline and being able to operate these complex environments are the biggest challenges in my opinion.
InfoQ: What kind of feedback are you getting from people using Escape?
Spaans: We get everything from "the tool I've been looking for" to "I'm not sure what this is for", so that's been really interesting! We generally strike a chord with people and companies that suffer from these problems every day, but I think we still have some ways to go in explaining Escape to different audiences.
InfoQ: Thanks for your time today Bart! Is there anything else you would like to share with the InfoQ readers?
Spaans: My pleasure, Daniel. Great talking to you! We're always looking for feedback, and so we would ask that the readers check out the project on GitHub: https://github.com/Ankyra
Additional details on Escape can be found on the project's website and documentation pages.
