DevOps has done a wonderful job of making a fully engaged, DevOps driven organization seem like nirvana. Deployments occurring every couple of minutes, automated testing, automated creation of environments, containers, all of the things that people read about in the press as being what should be done, DevOps encompasses that. There is a problem, however, in that DevOps has made the process of development so easy, so simple and “sexy” that no one sees the dark side. No one sees what it takes to make nirvana happen.
And therein lies the problem.
When I was younger, a lot younger, Visual Basic made developing applications easy. It encapsulated the Win32 API and made it easier to write applications. “Garage developers”, those that had never seen a computer before, never taken a programming course, were writing applications quickly and efficiently. They were able to create complex applications in the fraction of the time that it took a “real” developer.
As the operating system and business requirements got more complex the tools took a little bit of time, but they soon caught up. As technology increased in complexity the tools increased in abstraction, increased in capability. A ten line program now does the equivalent of hundreds or even thousands of lines of code previously. Need to do complex math? Someone’s already written the package to do it so just import it and you’re done. Need to create a web server? Already done. Access a database server and ensure that there is full transactional commit capability? So last decade.
And then came DevOps. It took it up one notch by not just trying to make a single technology simple, it tried to take a variety of technologies and, through the integration of other tools, make them all easier to use. And it’s working, Amazon would not be as successful if they had not integrated the deployment pipeline tools into a cohesive meta-tool.
It all seems so easy, so simple. And that is the dark side of DevOps.
It’s not easy. None of it has ever been easy. Wrapping the Win32 API in a cohesive, well-written package that was resilient and flexible. It took time. Adding in all the new technology as it came on stream? Subsequent developers and programmers built on the work of others. As each generation of tool came out, as each abstraction layer was put in place, there were fewer and fewer people who understood all the pieces. This makes it harder to create brand new integrations as most people survive by using other peoples work.
Trying to take an organization that has decades of experience using the tools they are comfortable with and the manual processes that have built up over decades, and then trying to integrate all of those pieces together? It’s not easy. Not in the least.
But the DevOps mystique has made it seem as simple as buying a tool and installing it and then you’re done. You’re far from done. You’ve only just started.
DevOps is the future, but the hype is making it difficult to for many organizations to realistically understand the cost of change. The angel seems to have horms.