Tasks to be done with a product can be thought of as points on a circular graph. That graph is a series of concentric bands, where each band is constituted of the people who can (have the ability and the permission to) do the task for the product. At the core of the graph, we see the product vendor’s developers. As the people who built and maintain the engine, they are most clearly able to perform tasks that change the engine’s capabilities. Surrounding that ring, the vendor’s field engineers are able to make supporting tools, scripts, and packages. Surrounding that, the customer’s product administrators range in capability from “field engineer with less support” to “user with extra support”. Finally, the customer’s product users, who have little interest in committing changes but just want to get results.
There are fewer developers than field engineers. There are fewer field engineers than administrators. There are fewer administrators than users. New versions of the product are therefore harder to get than glue code, which is harder to get than flipping an already built configuration switch.
As a user, if I can do a task myself, I am happy. If I need to ask the vendor but the first person I talk to (my field engineer) can help me, I am satisfied. If I have to file an enhancement request so a product manager can argue with me about whether I really need this and a developer can argue with that product manager about what I really need and eventually something happens but it’s not what I asked for… less happy.
Infrastructure as Code (IaC) divides the customer administrator set into two sets: “those who can use IaC tools” and “those who cannot”. This is true of the field engineering team as well, but the product vendor can simply make IaC use a condition of employment and fire the engineers who don’t learn the technology. That approach is suboptimal for handling customer administrators, but it’s not impossible to find Silicon Valley startups that don’t have support for customers who don’t have IaC. Effectively, these companies decrease the size of the administrator ring and increase the size of the customer’s product users ring by treating the administrators as super users. If you can’t do DevOps, you’re just a user when the IaC model is in place. In other words, more tasks to be done with your product fall closer to the center of the graph than towards the edges.
This is taking the product in the wrong direction, or at least moving prematurely, by assuming that the future is one of IaC and therefore all administrators will eventually use those techniques. To the degree that this is not presently true, the product’s administrative, maintenance, integration, and capability expansion tasks must be done by the smaller groups of people closer to the center. Fewer people able to do a thing means less of that thing getting done, more slowly.
Assuming that the future is IaC, this situation is temporary and someday everyone will do tasks the same way. When anyone who needs to implement any change does so by checking pull requests into source code repositories for peer review and automated implementation, truly we will live in the best of all possible worlds. I do have some doubt that we’ll get there. That world assumes a pretty high level of uniformity of tooling and process, a thing that has yet to occur despite the very best efforts.
Once upon a time, I presented a very clever process automation solution to a very large company who already owned a lot of our process automation engines. The conversation should have been a relatively quick one about how to migrate scripts between formats. Instead, they politely listened to our presentation, and then told us the truth. All the process automation software they’d bought was sitting on the shelf, unused, and they had no need for our new stuff either. Why? Because the Internet had made it cheaper to just lob tickets at an inexpensive overseas tech center where a human would remotely perform the task. Software can be fast, but it’s not perfect (to be fair, software also doesn’t go on strike for better working conditions). No software engine running clever content can ever beat the flexibility and contextual awareness of a human administrator that’s been working with and is familiar with the system to be managed.
So, IaC: moving tasks from flexible humans to inflexible code, increasing cost of implementation, and decreasing the number of people in the pool of easy solution providers. That sucks.
Monkeynoodle.Org 