fbpx
DevOps has become a buzzword over the last few years, meaning the integration of development and operations to remove bottlenecks in the process of implementing ideas as software. Some see this as a “Dev swallowing Ops” movement brought on by the cloud and several tools (like Continuous Integration/Delivery engines, Configuration management, etc.). The reasoning is that these tools enable development to perform the work traditionally assigned to operations.
To me, however, this seems to be condescending towards operations people, as it implies that they, as many in an increasingly computerized world, have been automated away. I’d rather see it as proof that, instead, the work of operations has matured in such a way that much of its traditional output can now be provided as a service: you no longer need to think about setting up hardware, networking or machine configuration, as these can be created for you on-demand. I emphasize need because the option is still there: many companies have valid reasons to manage their own infrastructure at the lowest level; however, you can also forget that entirely and be hugely successful, as Netflix proves.
I’d argue, though, that even when running thoroughly automated processes in the cloud, you will need an ops team, by which I mean someone that takes care of your application’s operating conditions:

  • how many machines do you need?
  • what resources do these machines need to have?
  • how are your application instances monitored?

Although the concerns, at a fundamental level, remain the same, they are elevated to a higher level of abstraction. This is similar to what happens in programming languages. As a consequence, the focus of ops has been moving to new frontiers:

  • static provisioning has become well understood and dynamic provisioning of applications (like autoscaling and Functions-as-a-Service) have begun taking the spotlight;
  • monitoring and alerting of applications have matured, so interest has shifted towards business-centric metrics and canary deployments.

From a historical point of view, companies have outsourced the development of their software products because they saw it as a cost center, then turned around to pull it back in-house when they realized it’s actually a critical part of their value stream. Ironically, the DevOps movement that seems to follow from this last trend was made possible due to the ability to “buy” a part of operations: you can now acquire a turnkey platform solution, which allows your operations to work closer to business, and thus to development.
I think it will be interesting to see what operations will look like in a few years.
Consultant @ Polarising