The Tough Task Of Making DevOps Automation Mainstream
February 10, 2016 Timothy Prickett Morgan
Getting the hyperscalers and cloud builders and startups on board with any new technology is fairly easy, largely because they are out there on the cutting edge by definition and are much less risk averse than established enterprises. But here’s the funny bit about this information technology market. If you want a company to grow and be profitable, then sooner or later, you have to appeal to those enterprises and get them to buy – and to use – your product.
This is not an easy task, for quite a number of reasons. When it comes to DevOps tools, it is even more challenging to get enterprises to adopt because they have their established ways and the very system and network administrators that can benefit from more automation are the ones who can resist their implementation. For some, they like their ways of doing things, which evolved over decades of experience in datacenters where real business has to get done, where replicated and redundant systems are not generally the rule, and downtime is a disaster – not just an inconvenience. For others, this is true and they are also hesitant to change because it gives them a sense of job security, too.
But, the increasing complexity in the datacenter, from hardware and operating system configuration all the way up to application deployment, is growing and this will only be exacerbated as enterprises move from a few hundred to a few thousand relatively monolithic applications that get tweaked a few times a year to container-encapsulated microservices by the many thousands that stack up to build the underlying platform and the applications that run on them.
Just because something is inevitable, however, doesn’t mean it will move fast. HPC centers moved from shared memory machines running Unix to distributed clusters running Linux in what seems like a lightning flash in hindsight in the late 1990s. This was just as Google was being founded and just as the hyperscalers were set to explode. It took Google until 2005 to have workload management issues that were so large for its applications that it needed to create its own software containers, and it took another decade for these ideas to take off in the outside world among cutting-edge companies that are embracing LXC, Docker, and other containers as a means of managing their software and while still abstracting themselves away from their underlying hardware. Our point is, while we are all probably sick of the hype surrounding DevOps and containers, these technologies are still largely untried and untested in all but the largest and most sophisticated enterprises.
These things take time, and Luke Kanies, CEO and co-founder at Puppet Labs, the maker of the Puppet configuration tool that is becoming embedded in the modern platform stack, is taking a long view on this. And we mean a very long view.
“The most interesting thing in my opinion is that just how few companies use automation at all,” Kanies tells The Next Platform. “Several times a week, I run into a company that has five, ten, twenty, or even fifty thousand servers that are maintained pretty much manually. And it is not like they are the exceptions, they are the default. Companies that are completely automated are the exception. That is the big opportunity and the most compelling thing that we are trying to do with Puppet.”
There are tens of thousands of large enterprises and millions of midrange enterprises, all of whom wrestle with infrastructure configuration and management every day, all day long. While growth has been good for Puppet Labs, which has over 30,000 companies using its open source tools and over 1,000 enterprises using the commercially supported Puppet Enterprise wares, the target is much, much larger.
“We need to be targeting the Fortune 50,000 companies in the world, and that is my definition of success and we are pushing hard for it,” says Kanies, and by the way, that is a key constituency that just so happens to be the target of a publication called The Next Platform, too. “The one thing that we can be superconfident of is that the world will continue changing, and not just over the next five to ten years, but I really think over the next fifty years. I think that the rate of change that we are seeing is not going to go down in our lifetime.”
On the one hand, Kanies elaborates, that means any individual year is less important, and the wider time horizon means that companies can – and should – shift their thinking. Everything in DevOps will not actually happen in the next five years, so there is no pressure to get it all done this year. Enterprises will take a more measured approach than hyperscalers, who hit scale a long time ago and absolutely needed automation to cope with it. For enterprises, they have complexity more than scale, and they need automation to cope with it, but the gatekeepers of administration will need to be convinced of that.
Our suggestion is to become a Puppet master and not unemployed, although if Kanies is right, there will be plenty of jobs available in enterprises that do not heavily automate their system and application management for years to come. Still, it would be better to be a pollinator of this new breed of automation tools, including Puppet, Chef, Ansible, SaltStack, and many others, than fall victim to them.
But on the other side, we have a long way to go, as Kanies points out, and in a way, he is happy about that because it means there is a lot of work for Puppet Labs to do and a lot of customers to chase. “We have a scale of how far we have to go. Think about how much time will it take before the world of software is as tightly run as the world of manufacturing smartphones. The supply chain that Apple is able to rely on to build high quality, high volume smartphones – that’s some tip-top work. We wonder what it looks like to do that with software. I think it will take a long time.”
It has taken more than a decade for Puppet Labs to get this far. Kanies started the company in 2005, and thus far it has grown to 420 employees, with about 135 of them in software engineering, and has raised a total of $87.6 million in five rounds of venture capital to fuel its growth, including investors Cisco Systems and VMware. Of the $40 million raised in the fifth round back in June 2014, more than half of that cash is still in the bank, and Puppet Labs just closed $22 million in debt financing that he says the company has no intention of spending but, as Kanies correctly points out, when you don’t need money, that is when banks and investors want most to give it to you. Puppet Labs just finished its fiscal year on February 1, and it has an annual revenue run rate approaching $100 million, says Kanies, and the goal is to become cash flow positive this fiscal year.
The company has development centers in the United States and the United Kingdom, with satellite offices in Canada, Germany, Belgium, Australia, and the Czech Republic. The headcount is another good indicator of how Puppet Labs is growing and how it is exercising cost and growth controls as it transitions from a startup itself to a profitable and sizeable software company. The headcount doubled every year for a while, but Kanies thinks it will add somewhere between 100 and 150 people to the workforce in 2016, or a 25 percent to 30 percent increase.
“If you continue to grow your costs as quickly as you grow your revenues, then the lines will never cross,” he says. “But we realized that the closer you get, the harder it is. You can’t just sweat the dollars. You need to get the pennies right, too. Being cash flow positive is learning about being disciplined with cash, and you know where to spend your time and money and the whole world looks different. I could go out and raise money for growth, but at this point, I think that what we are doing with the business is so healthy that I am excited to see the changes that are going to result.”
This is a lesson many startups could learn, and often don’t because the money seems easy at the front end and they think they can just grow their way out of the problem.
Teaching Puppet Masters Of Automation
Looking ahead to this year, Kanies says that he is focused on “the land war,” which is to just get people to realize they need to automate system and application configuration management, and getting feet on the street to peddle Puppet Enterprise and training for companies who are newbies. Such automation as embodied in DevOps tools like Puppet completely disrupts the IT organization, and admitting that is something that tool makers and their users have to admit upfront – one CEO, one CIO, and one developer at a time, as Kanies puts it. That is millions of people to convince.
Puppet Labs also knows that its own tools will have to change to adapt to the enterprise customers it is now pursuing to support its own growth initiatives. “We recognize that we have gotten really far with the business and the toolchain that we have solving the problems that we think are critical to solve. But we also realize that the next tranche of customers that we get are not going to look like the early adopters that we built our business on. The mainstream users will have a different set of incentives and drivers. All of these things have gotten us to where we are, but just like an individual, we have to ask ourselves what happens if we remove our attachment to what we think is great about ourselves and look at it objectively. So we have to find a balance in our business between solving our current customer needs and also not being so attached to those things that we lose sight of the opportunity in front of us.”
This is less about products than attitude, and creating a place to rethink about the definition of success. For early adopters, the definition of success was using a tool to solve a problem, pretty much by their lonesome and often by hacking it together with other open source software. The early adopters understand their problems, they help make the tools better, and they are willing to do the work themselves to implement the tool. But for mainstream, enterprise customers, the definition of success is different, and they do not want to start from scratch and solve the problem themselves, but rather jump straight to the part where the problem is solved and they do not have to do much to get there. The addition of the Application Orchestration add-on to Puppet Enterprise last fall, moving Puppet one layer higher in the platform stack, is but one step in this direction.
“It is really about being more aggressive about how we solve problems for more people, and we are in a great position to do that now,” says Kanies.