Meet The Open-Source Startup That Wants To Automate Your Next App

Some people watch TV in their spare time. Others play basketball. Mitchell Hashimoto, overachiever that he is, started an open-source project.

And not just any project. In 2010, Hashimoto used his spare time to turn his college dorm room into Vagrant, a popular developer tool that makes it easy to build complete development environments. With a marketing plan straight out of Open Source 101 (“open source the code, blog and tweet about it and wait for word of mouth to take over”), Vagrant now generates millions of downloads, inspires a small army of contributors and boasts a bevy of big-name users, including the BBC, Nokia, Expedia and ngmoco.

See also: DevOps—The Future Of DIY IT?

Hashimoto, however, isn’t done. 

Mitchell Hashimoto

Two years ago he formed a company, HashiCorp, to give him the funding and freedom to build a suite of services to manage the full lifecycle of application development, delivery and management. Not content to be popular with the developer crowd, in other words, Hashimoto is also currying favor with operations engineers.

This places Hashicorp right at the nexus of so-called DevOps, in which developers take on more responsibility for managing the infrastructure that hosts their applications and puts them in the hands of users. Some people view DevOps as heralding the eventual extinction of IT operations as a specialized function; Hashimoto isn’t one of them, although he does think IT suffers from a fatal lack of automation. And that’s a problem he’s trying to fix.

See also: The Truth About DevOps: “IT Isn’t Dead; It’s Not Even Dying”

I sat down with Hashimoto to discuss DevOps, IT automation and how producing new tools for both developers and operations has turned into an open-source success story.

Special Delivery (For Applications)

ReadWrite: Hashicorp offers a number of different applications, from Vagrant to Consul. What’s the common thread between these seemingly disparate applications?

Mitchell Hashimoto: The common thread is application delivery in a modern datacenter.

Taking an application (or service—whichever vocabulary you choose is equivalent in this case) from development into production and iterating it is a overly complicated task right now. There are a lot of moving pieces and a lack of clarity of the capabilities of each piece. 

With our tools, we’re trying to solve the common datacenter problems: development environments, service discovery, resource provisioning, etc. These are problems that anyone with a datacenter—cloud or physical—has, and it’s silly that there isn’t a common solution to these problems.

Well, that isn’t entirely true. There are technology-specific solutions in some cases. For example, VMware claims to solve all these problems, but with a VMware-heavy skew. 

We want to build tools that are agnostic to these sorts of decisions: whether you’re using OpenStack or AWS, physical or virtual, we want our tools to apply to you to solve the common problems stated earlier.

We Serve Both Kinds—Dev And Ops

RW: Tell me a bit about the tools you provide. Who uses them and why? What do they replace, if anything?

MH: We provide a number of tools: Vagrant, Vagrant Cloud, Packer, Serf, Consul and Terraform, each designed to help streamline application delivery in the modern datacenter. 

Vagrant manages work environments; Packer builds machine images and/or containers; Serf does cluster membership; Consul is a solution for service discovery and configuration; and Terraform builds infrastructure. That is the elevator pitch for all of them. Of course, none of these “elevator pitches” really does them justice, but they’re a start.

Our primary users are developers and operations engineers. The percentage of each group varies from tool to tool (i.e. Vagrant is developer-heavy, but Consul is operations-heavy), but as a company we build solutions to problems in the DevOps space, which by its very name affects developers and operations! Our tools primarily replace non-automation-friendly predecessors, or less flexible predecessors. 

Packer moving right along

Since we’re coming at this problem space from the point of view of DevOps, our tools work well with others in that space and our tools focus on automation. 

Compared to predecessors in some categories, we focus on having a better user and operator experience, as well as bringing more flexibility where possible. For example, with Terraform, it can be compared to something like AWS CloudFormation, but Terraform supports any cloud, not just AWS. But Vagrant, for example, doesn’t replace any specific existing tool, it just makes it easier to do what was a primarily manual task before.

RWWhat are the biggest inhibitors to developer productivity today?

MH: A lack of agility brought about by a lack of automation.

There are a number of aspects of a developer’s workflow that can be improved: we can make building developer resources faster, we can improve the delivery pipeline and we can increase the mean-time-to-feedback for deploys. But I posit that each of these improvements requires better automation and tooling to safely manage this automation.

The Relevance Of IT Operations

RW: In the DevOps debate, where do you fall? Are IT operations increasingly irrelevant? 

MH: I believe IT operations will always have a place, but some job functions are shifting. Developers are increasingly taking control of their pieces of infrastructure, a realm where IT previously ruled supreme. In the future, I believe we’ll see IT teams shrunk down—but still extremely important—and we’ll see developers—or call them “operations engineers”, meaning less IT, more dev-like—having a lot of control over the datacenter.

Our technology is built for this future. We have some pieces that are more relevant to developers (Vagrant, Packer), and we have some pieces that are more relevant to IT or more sysadmin folks (Terraform, Consul). There is overlap in there, but in a traditional IT world, we see a scenario where our tools are really bridging a gap to allow them to work together more effectively.

RW: Who is your target user/customer? Do “Microsoft developers” want these tools, too, or is it the AWS crowd that primarily finds your stuff interesting?

MH: Our target user/customer is anyone deploying applications.

I’m glad you brought up Microsoft developers. I actually switched to using Windows full time earlier this year so I can better understand a certain problem space for Windows developers, and to make sure our tools worked well for them. 

There is a huge interest in our tools from the Microsoft community, and we treat them as first-class citizens in our target user base. All our tools from Vagrant to Terraform are built to support the Microsoft ecosystem, and we think its going to be a big market for us as our business grows.

I think its fair to say the “AWS crowd” found our stuff first, but as time has gone on (remember: we’ve been building these tools for five years now!), we’re relevant in the Microsoft world now, too.

Lead image by Stefan Goethals; other images courtesy of Hashicorp

Facebook Comments