Opscode helps companies develop fully automated server infrastructures through their flagship product, Chef. Adam Jacob, one of the founders of Opscode, shares his insights into the business benefits of automation, where the infrastructure automation industry is headed, and how Chef and Opscode fit into that landscape.
I think the elevator version of the mission is that we want to automate the world’s infrastructure. When you break that down, what it really means is that we believe that there’s a fundamental shift happening in terms of how people relate to the systems that they manage. More and more, you start talking about those systems as source code, which then means that the systems themselves will configure themselves to do the right thing in the world. Our belief is that by creating a series of primitives, software developers, business administrators, and those sorts of people can use them to automate their own very complicated infrastructure.
We started a consulting company that did infrastructure automation for a living. The goal for our consulting company was to try to increase our own margins on what we sold by becoming really efficient at reusing the same code over and over again. Once we automated a thing, the idea was that we could then just reuse that on lots of different customers, and the time to deploy would get lower. The truth was, that didn’t happen, and it’s because the way that the tool talked about automation didn’t think about how to automate problems at the scale of lots of different, complicated problems.
We needed the right tool; if it was flexible enough, it had to be able to fit no matter what problem we encountered with the end customer. And that’s really why Opscode was born. As a consulting company, we just couldn’t get it over the line to a place where we could deliver enough value to our customers fast enough and without writing a new product. And so, we wrote Chef, and it turned out that what we wrote was really good, and far beyond just enabling our individual consulting company. From there, the history of Opscode as an entity really begins. We hooked up with Jesse Robbins, who had a long background of doing infrastructure automation and outside evangelism and all those other things; founded a company; raised money; turned it into a product.
Chris Brown also is essential to that story in that we were a bunch of systems administrators–smart guys, lots of expertise, building demand-specific tools. Chris is the one that really brought in that DNA of really professional software engineering and professional service development that led to the entirety of our product outline.
All we do all day is spend time building tools to help people get the right level of extraction so that they can solve their problems. Automation is awesome, and it’s fun, and if you’re nerdy about the thing you’re automating, it’s good in its own right, do you know what I mean?
But in reality, when the rubber meets the metaphorical road, you really do wind up with a situation where you have a person who is working in a business with real problems they have to solve right now. And what’s great about what we do is that we provide tools that are as unopinionated as we can make them about how you solve your problems. We give you a road map. We give you a framework. We can give you best practices. But at the end of the day, we enable people to bring their expertise to bear on solving their very real fundamental problems in their day-to-day life.
At the end of the day, anybody can put together stuff and call it a product. What matters is how your customers feel about you, and what your customers say about what you do. So, the way Opscode stands out from our competitors is that we have more customers who are willing to stand up and talk about what happens in their day-to-day life than our competitors do.
We just had our first annual user conference. It was packed full of people. We had a couple of days’ worth of content–all customer driven, all delivered by people who had built new stuff with Chef and were sharing with other people what they had done, and why they had done it. They were passionate enough about it that they were going to take time out of their life to show up and talk to other people about it. At the end of the day, if you want to build a company that really lasts and that is actually transforming an industry, that’s where your focus has to be. If your focus is anywhere else, then your product is going to suffer, and people know.
The truth is we have more of a psychographic than a demographic. There’s a classic person who understands what their business does for a living, understands the role that technology plays in it, and understands how the increase in efficiency that can be brought to bear by automation has an impact on the bottom line of those businesses. Those are the people who love Chef. Most often, those people turn out to be software developers; they turn out to be systems administrators; sometimes they’re business leaders. It depends on who has the revelation first.
But at the end of the day, you don’t see a lot of different customer lines for us between a systems administrator or a software developer, because at the core of what they share is that same passion around the value automation can bring to the business – those transformative things – and also the value that automation brings to their day-to-day life. In many ways, that’s almost more important.
I think when you start looking out into the future, what you start to see is that there is this generational shift happening in the level of required efficiency within a business. In the same way that GE revolutionized Six Sigma and that idea that you could streamline manufacturing and that you could streamline operations, that same revolutionary shift is happening in the way that people deliver infrastructure. When you talk about cloud infrastructure automation, one of the reasons why it’s happening there first is that a lot of that infrastructure is new. You’re seeing a lot of people who aren’t necessarily that leading edge who are coming around very quickly to this kind of automation as an environment. And the reason is that it provides this incredible business differentiator, especially early.
So, in the next five years, what you’re going to see is the leaders in our market segment figuring out that there is competitive advantage to be had here. They’re going to be the ones to go out and lead that charge, automating what you would think would be very traditional businesses, like insurance, health care–all sorts of those sectors where you’ll find one of these companies that realizes the competitive differentiator, grabs onto it early, and drives it really hard throughout the organization. And the result will be that they will start out-innovating and out-competing their competitors, which will drive, of course, those competitors to adopt the next feed.
Anytime you’re talking about wide, broad scale business process transformation, it will take a while to adopt. But Opscode is positioned there pretty strongly. What we do is provide the framework that is most valuable for the people who have to actually implement that business transformation.
So, you have to answer two questions. One is, “Where is the business entity? Where is the organization at in its desire to embrace this efficiency?” There’s a cultural and business process problem there that needs to get aligned. And then on the flip side of that, you have to ask, “How does this automation help the people who have to actually run the infrastructure technology orbit?” For those guys, it’s pretty easy to convince them, because if you talk to them about what they do every day and you talk to them about the value of how much faster and how much easier and how much more pleasant your day-to-day job gets by using this technology, it’s not a hard sell.
When you start talking about how to transition the business from one to the next, at that point you’re really having conversations about, “How do I drive more productivity out of your resources? How do I get faster time to market? How do I ship more features?” Those conversations can take longer, because it often takes a little while for people’s heads to shift from the way that they’ve been doing business on a regular basis that’s comfortable and produces visible results to a little bit of a shaken-up world that’s moving a lot faster and a lot more agilely.
Part of what you have in that conversation is getting people to an understanding of what’s possible, and then you start stepping them through the process of showing incremental transitions. They’re like, “Okay, within this segment of your business, what could happen to this B-Metric when we put automation?” And you do it again and again and again, and at some point the problem flips from, “How can I convince people that they should use this kind of automation?” to, “How do I slow down people from just grabbing into automation because they’re running ahead of what the business can actually sustain in terms of pace of change?” There’s a very interesting flip that happens where in the beginning it’s like, “Can I convince you?” And then after that it’s like, “Whoa, slow down, step by step.”
I’m a systems administrator, so I’m the kind of person who uses the product. That’s why I care so much about it. What makes me excited about it is that it’s the first tool that I’ve ever had in my professional life that I felt like was actually focused on solving my real problems without trying to tell me how I’m doing it wrong. Most of the tools in this space started with this supposition that everything you’ve been doing is false, and that you need to relearn the entire universe. Chef starts with a different supposition, which is that there’s a set of primitives you haven’t been using that can help you model the solutions to the problems you already have.
But the important part there is that you already know the solution to your problem, and that’s a very unique and different approach to the software, and it’s a very unique approach culturally to the people who need to adopt it.
There’s a long history of tools in the space, and Chef shares a lineage with lots of them. You can draw a straight line of evolution from previous tools in the space to Chef. It started out with a different name that was much longer and it was called Marionette. But it turns out “Marionette” is really long to type, right? When you’re typing code and you have to type Marionette before you do anything, it’s just a bummer, honestly. And so, I wanted a shortened word that made sense, so that I wouldn’t have to type Marionette ever again in my life.
Chef was a four-letter word whose metaphor fit what we do in that writing infrastructure as code is a lot like writing a cookbook. You have a bunch of recipes with ingredients that you put together to make a cake. But the cake is the metaphor for your infrastructure, and all the stuff you mix in – the ingredients are servers, and switches, and routers, and the recipe is the actual code. So, honestly, the first criterion for the name was, “Is it short?” And that was blessedly true. And then, once it was both short and had a metaphor that fit, that was the magic moment.
I think for me, the most interesting companies in the market segment right now are the startups. You are at this revolutionary shift in the way people manage infrastructure. Obviously, I think Opscode is the most interesting
I think the guys at CFEngine are also interesting. I don’t think you can realistically have a conversation about what it means to be doing configuration management–and the science and philosophy that goes into doing it well–without talking about Mark Burgess, who is the founder of CFEngine. It is a privilege in every way that he both knows my name and likes me. I think he’s a great guy, and his contribution to the field of what we do is incredibly strong.
And the other common player in the space is Puppet Labs. They built a product called Puppet. I think what’s interesting about them is – and like I said, there’s an evolution between CFEngine, Puppet, Chef – that when you look at what they do, the big leap forward for Puppet in many ways was the way you talked about the abstraction of the system. So, the utility of the language that was specifically designed around this resource abstraction was interesting.
When you look at the companies that the three of us are building, they all come at it from very different market angles, and very different groups of people gravitate towards the tooling. So, depending on which angle you find your way in, one of those companies tends to feel most appealing to you.
There’s a couple of things. One would be agile software development and the idea that you can shift features in a product much sooner and much faster than you used to be able to. The open source movement: the idea that not only should you be able to use code, but you should be able to open it up and explore it. You should be able to fix bugs if you need to. You don’t have to wait for a vendor.
Cloud computing and virtualization: the idea that I would be able to take a single piece of hardware and get multiple isolated systems on it gave me a much greater level of density. It was faster to spin up an individual system, but it also dramatically increased the total number of managed systems, which creates a very interesting problem as well. So, what used to be a couple thousand typical servers is now 20,000 virtual boxes.
You then wrap that problem up into an API and expose it over the network. That removes the burden and gives you five minute turnaround times. What used to take 45 days now takes 5 minutes.
Those are the technical forces at play. There’s a business force in play here too, which is you look at what Amazon.com has done internally, the way that they’ve structured themselves, the pace at which they ship new features, and the incredible competitor they have turned themselves into on a number of different fronts and a number of different industries. You look at existing large businesses and you have to know they want in on that game. So the question for them is, how quickly can you transform your internal operation to move in a way that allows you to compete with some other competitor who is really great at shipping software, really great at shipping services, really great at doing this kind of core infrastructure automation? And you put all that stuff together on the technical end and on the business end; what pops out the other side is in fact this revolutionary shift in the way we manage our infrastructure. It’s not just one thing. You have to have all of those forces coming together in a single confluence of change. It pushes out what is really a fundamental shift in the market force.
We’re looking at more features inside of Chef, including more infrastructural orchestration, where you’re talking about higher level abstractions about the workflows that happen inside of a business. There’s much better reporting functionality that’s going to come out–you get way better insight to how things are actually behaving out in the world. There’s a bunch of stuff that’s happening up the stack.
One great thing about Opscode is we have this huge community of users that are constantly talking to each other and sharing what they’re doing. So, one of the things that Opscode gets to do from that is listen and absorb and turn that back out as best practices. So, you’ll see a lot of that stuff happening that we’re pretty excited about. And part of what we’re going to keep doing is helping people understand how they use what we’ve built to solve their day-to-day problems.
It’s a little less sexy than shipping new features, but in terms of the most important things Opscode does day-to-day, the most important thing is communicating with people, talking to them about how we can help them, and then showing them how to actually help themselves.
Want to read more Business-Software.com exclusive interviews with CEOs and company founders? Head over to the Behind the Software Q&A section of the blog to browse the complete collection.