A lot of companies look at what the major cloud and XaaS providers are doing with their operations and develop some form of cloud envy. They dream of a highly automated infrastructure capable of making lots of changes at a moment’s notice. Their CFOs envision a lean workforce capable of supporting thousands of devices with a small number of generalist resources. Indeed, the vision of a more efficient, more agile IT is quite enticing.
In plotting their course to this operational nirvana, many people look first to the tools. They view the transition as primarily technical. Of course, these kinds of major transformations are rarely so simple.
Start with culture
There is a ton of writing out in the blogosphere on the role of culture in IT, and there is little need to offer a fresh take on a fairly noncontroversial point of view. So let me just assert that if you think that your company will execute a transition without accounting for cultural elements of change management, you are likely going to be in for a disappointing transition.
In short, culture is going to matter, which means you need to spend time getting beyond the tooling to understand where your opportunities and bottlenecks are going to reside.
I have spent a lot of time over the last 10 years talking to networking customers about automation, and over the last few years, DevNetOps (the networking instantiation of DevOps). More often than not, when people come in wanting to talk DevOps, they really actually want an automation discussion. What’s the difference?
I think of automation as primarily focused on workflows. You identify workflows, and then you take steps to make them execute automatically.
But automation is more than scripting. If your view of automation is that you are going to write a script to run a sequence of steps for you, chances are that you have used scripting skills to develop a solid approach to abstraction. Reducing 134 steps to a single command is abstracting those 134 steps and providing some set of inputs to execute them in sequence. This is a hugely useful thing to do, but it doesn’t get to the heart of automation.
Automation is more about collaboration. When two things (people, systems, organizations) need to work together, there is a requirement that they share information. Put simply, the currency of automation is data. And this means that automation is primarily an exercise in figuring out how to make to things talk (data distribution) and speak the same language (data normalization). This is why you see a lot of message bus and translation layers (API brokers) in many automation discussions.
Where automation is about workflows, DevOps is more about treating infrastructure as code. It’s about how you make changes to your code (infrastructure), test those changes, and then deploy them. This is why you hear continuous integration and continuous delivery used in many DevOps discussions.
For the vast majority of enterprises, moving straight from ITIL to DevNetOps is a bridge too far (and frequently an unnecessary objective). Most companies are just looking for ways to automate their infrastructure to some degree. And the evolution from CLI-driven to something more event-driven or even machine-driven is a fairly substantial step.