DevOps Is Undead
The technology world moves fast, and as disciplines get disrupted we are often exhorted to consider them as dead. The most recent example of which being this elegy for DevOps. The problem with declaring DevOps — or any other field of employment, for that matter — dead is that it’s reductive to the point of meaninglessness. If DevOps is dead then what happens to the people doing DevOps? My take is that DevOps was a philosophy before it was a job title, the cloud — by way of managed services — is eating outsourcing, and because of this the DevOps team is needed now more than ever. But maybe they could simply do with a new name.
DevOps Is a Philosophy
In the bad old days of legacy IT before DevOps or the cloud if you had to deploy some software into production you’d usually have some sort of process to follow that went like so: fill out some sort of capacity request where you had to estimate how many servers you’d need, specify which of the approved production platforms you needed (Java 1.4 or Java 5?) and of course you’d have to assign a cost center for the expenditure. If it got approved, you’d have to wait until IT Ops made their quarterly bulk server buy. And then, once it came time to deploy you’d need to fill out a change management form, detailing all the actions you were planning to take to push your code into production. And all these forms were likely excel spreadsheets or worse. Or, if you were friendly with the right person on the ops side of the house, you could lay your hands on someone else’s underused gear and bypass that whole awful process.
These processes existed because the goals and alignments of the teams were fundamentally at odds. Software and product development are measured and judged on the features and quality of what they ship. IT Ops is judged on uptime and the availability of the production environment. The incentives here are at odds, hence: bureaucracy and politics. This was the world that the DevOps movement was originally trying to adjust, albeit from primarily an organizational perspective. DevOps aims to break down the silos that are seen as the cause of stymied development.
And alongside the DevOps movement came the cloud, starting in the form of AWS. AWS, and indeed all cloud products are distinct from what came before them in that they are delivered as a managed service. Managed hosting had been around for a while, of course, but the big difference with AWS was its insistence on automating the delivery of the service which had and is still having a transformative effect on how businesses consume technology.
Outsourcing in the Cloud
Outsourcing has as checkered a history of success as the legacy IT model, and for similar reasons. When a company chooses to outsource some function, it’s very easy for the company and the outsourcing firm to become misaligned in their objectives. Typically a project manager will be appointed to specify exactly what the outsourcing firm is to deliver. It’s painful and as often as not the work product won’t live up to the specifications, but even when it does those specifications are apt to be imprecise.
The cloud, and in particular any of the *aaS type of businesses, get around this by specifying what they do, up front, as an API. The API encodes the capabilities of the product and how it is to be consumed. If the customer can work with that, then perfect. If not, there’s no love lost: the customer has invested minuscule time and effort into evaluating the service.
The efficiency gained from this model is akin to the industrial revolution — existing businesses can effectively outsource non-core functions, and new businesses that get started automatically reach for cloud based solutions rather than bring extra complexity in house. This drastically lowers the amount of start up capital new businesses require.
It’s All About the Platform
The Cambrian explosion of managed services has created a great deal of noise in the marketplace. Even discounting external vendors, AWS now includes hundreds of individual services. It’s a dizzying array of options, and developers can approach them in one of two ways: they can either integrate these services in an ad hoc manner, taking what they need as they encounter problems. Or they can treat the slew of managed services as a platform that ought to be carefully considered and architected.
This is already what the DevOps team is doing — platform engineering. Done poorly, the platform becomes a morass that the development team constantly fights against. These failures of platform lead to lengthy and expensive re-architecting initiatives and endless migration. Well executed platforms enable development teams to focus on solving customer problems instead of worrying about the extrinsic concerns of repeatable and reliable code delivery. To analogize to manufacturing: if the developers are the product designers, the DevOps are the industrial engineers who build and maintain the assembly line. Only together can they enable a company to build product with the speed and quality demanded by the market today.
So DevOps isn’t dead, indeed the philosophy is what has guided us to this very point in time. And the only thing managed services are killing is wasteful misadventures in outsourcing. And to those DevOps who endlessly admonish us that DevOps isn’t a title: just call yourself Platform Engineers already.
Opsee is application monitoring designed from the ground up to work with how you build apps in AWS. We keep an eye on all your backend services, letting you get back to doing what you do best: shipping code. Sign up today.
