The following is a contributed article by Lucas Carlson, VP of strategy at business automation vendor Automic Software, and an author and entrepreneur
Like the first Thanksgiving, DevOps is a coming together of two distinct groups. Developers and operations, sitting together around the dinner table, sharing the same feast, right?
If you’re a developer, you’re seeing new tools coming out, sometimes one or two new ones a week. Each one more complicated than the last. Each one promising to finally solve some big operational headache for you once and for all. All without having to interact with an operations team any more.
In fact, if anything, operations is being pushed out of the Thanksgiving table these days.
It all sounds so easy at first: Use tools like Chef, Puppet, and Jenkins to configure and provision applications through software automation and then manage the underlying infrastructure through other application monitoring and performance technologies.
Easy, right? Then just smatter on some orchestration tools like Kubernetes and Mesos. And for good measure, make sure you’ve got some kind of PaaS. Don’t forget your Docker container manager, though. Oh, and lest you forget that container networking and storage solutions are not fully baked yet, make sure you have solutions for that. Sure, those solutions themselves are really just proof of concepts at this point and none of it has been tested at large enterprise scale yet.
It’s a myth. The cult of the new.
While the new generation of automated configuration tools are great starting points for treating infrastructure as code, the notion that they can be trusted to usurp the need for operations in managing datacentres is a pipe dream.
In fact, quite the opposite is true. Production environments can be very complex, made up of large interconnected systems that can’t always just be containerised. The new breed of tools are fundamentally built for developers to develop code faster. They aren’t adequately designed to address what comes next: taking agile practices into large-scale production environments.
In fact, not only is ops not getting devoured by code, its role is growing more central and vital every day. A good ops team is the only line of defence against even a few seconds of downtime that can cost a business millions of dollars and untold customer goodwill. Fail fast might be fine for development of code, but for keeping things running smoothly, that philosophy often falls short.
Yet pundits continue to push the idea that operations’ role is rapidly diminishing and that the best people to run the code are those who wrote it (which sounds eerily familiar to me like the old adage that “a man who’s his own lawyer has a fool for his client”).
“DevOps will often put more responsibility on development to do code deployments and maintain service levels,” wrote Gene Kim last year. “This merely means that development is taking over many of the IT operations and operations engineering functions. In order to support fast lead times and enable developer productivity, DevOps does require many IT operations tasks to become self-service. In other words, instead of development opening up a work ticket and waiting for IT operations to complete the work, many of these activities will be automated so that developers can do it themselves.”
But who runs the self-service systems that developers will come to depend on? What happens when those portals break? Who fixes the broken PaaS? Your web application team? I don’t think so.
Yes, operations role is changing. But it’s not going away. It’s not being “taken over” by software. That new software still has to be run and maintained by someone.
Kim has characterised the goals of DevOps as “deploy fast, fail fast, learn fast, improve fast.” In other words, speed wins and it’s better to be able to able to fix failures so quickly that it’s more efficient than preventing them.
This sounds great in theory, but if you’re a large retailer running an e-commerce system, you don’t have the luxury of failing during black Friday just because it’s trendy to do so. Don’t be a lemming. Failing fast in development is fine, as long as issues don’t find their way into production.
The assertion that operations is vanishing seems based on an ill-advised conceit that, say, running a Chef cookbook that’s able to spin up an Apache and MySQL service in five seconds is in the same league as managing a large, complex infrastructure.
It’s certainly understandable why development has adopted a rather aggressive attitude about speed to production. Too many operations teams have been slow to adapt to realities of continuous software delivery. Some operations teams have clung to command-and-control processes that are slow (on purpose), which is the very problem that produced the DevOps movement.
What organisations need is to be able to develop software as fast as possible while also empowering operations to make sure applications going into production are as reliable and scalable as possible. You can’t have one camp forcing its mentality on the other.
There’s a middle ground: two-way agility supported by more sophisticated automated tools that allow both developers and operations to work collaboratively toward the mutual goal of continuous development.
Developers get their agile tools. Operations get their own agile tools. And we make sure those tools work well with each other.
It’s time to be wary of myths. Operations isn’t going away. Both sides of the DevOps construct will be sitting at the same table for the foreseeable future and need to start finding common ground instead of pushing each other off the table.
PREVIOUS ARTICLE«Is your organisation creating the best IT leaders?
NEXT ARTICLEQuiz of the week: 24th March»
Adrian Schofield sheds light on tech in South Africa
Mark Chillingworth on IT leadership