What Is DevOps?

The second leg of the DataOps stool is DevOps. Here is another one of those terms that people throw around but don’t really know what it means.

What is DevOps? I’ll tell you what DevOps isn’t. DevOps is not software. Not gonna lie. That was really confusing for a long time. I literally thought DevOps was learning how to use continuous delivery continuous development or CD/CI tools like Jenkins or Travis CI. It’s not that at all. I was super excited to learn DevOps. I was quite unsatisfied at the very touch feely nature of it.

DevOps is purely philosophical. It’s an intellectual outgrowth of Agile. The fundamental goal of DevOps is to get the people that build the software working closer together with the people that run the software. I’m not talking about users. I’m talking about DBAs, site reliability engineers, server admins etc. Frequently it’s the case that people that build the software, don’t release it to the wild nor manage it once it’s out there.

In the olden days of yore, there used to be a real disconnect between these two groups of people. DevOps attempts to bridge that gap. Dev. Ops. Get it?

Don’t get me wrong. DevOps is all about CD/CI. It’s about getting software out there faster on the same pace as Agile demands. It’s iterative. However, while Agile is about rapid product management, DevOps is about rapid product release. We’re talking about the physical processes of moving code from dev to test to prod.

This process of constantly releasing software, requires a butt load of automation. I mean like nine or ten butt loads worth of automation. DevOps is where you hear concepts like infrastructure as code and application management solutions like Docker come into play. This is reason number 842,559 why I’m screaming to learn to code your ETL processes. You can’t do this stuff with no code low code tools. I don’t care what the sales guy says.

But, also, like I said, there is a lot of hippy dippy warm and fuzzy stuff too like establishing DevOps values in the enterprise. Values like, encouraging teamwork, reducing silos, practicing systems thinking, embracing failure, communication, accepting feedback, and automating processes.

Does any of this sound familiar? Is it just me or is this pretty much everything I’m teaching intuitively without being a real expert on the subject matter? There is a reason for that that I’ll tell you about in a second.