DevOps Isn't a Jenkins Server

I've been responsible for deployment in every job I've had. This has included not only plain-vanilla enterprise applications to a load-balanced server farm with a web tier, backend, and database, but also (and mostly) distributed systems with hundreds to thousands of remote nodes. And on multiple operating systems, from Linux, to Windows, to embedded real-time OSes.

When I was looking for a job last year, I repeatedly applied for DevOps engineering positions, because I reasoned that my deployment and software development experience were what technology departments were looking for: A senior software architect who had done the dirty work of automating the deployment pipeline in a variety of demanding environments.

For the most part, this was not the case. Again and again I would talk to the hiring manager, hit it off beautifully, and then hear, "Wow, you really get it. Unfortunately, we're looking for someone more junior. We're moving to DevOps slowly, and right now we want someone with experience in Chef and setting up a Jenkins server..."

Not surprisingly, my current job came about after my hiring manager said, "Every time I brought on a junior or mid-level sysdmin to do DevOps, we failed. It's a software architecture function."

This is perfectly reasonable - but the reality is that these organizations claim to want to move to CI/CD (Continuous Integration/Continuous Deployment) with no architectural changes to their legacy monolithic enterprise applications. It is typical to hear of build times of close to an hour, deployment and smoke tests taking another hour, and after everything runs it's a lag of two to three hours between the check-in trigger and a green (or more often red) status dashboard. In those two to three hours, there have often been dozens of other commits. When these commits take place with an overseas team, you are now effectively shot for a day while nothing works. Your best onshore engineers are going through the logs, trying to locate the error, only to find several more errors are in the queue behind it, and your integration and test teams are sitting on their hands.

Sound familiar? For many organizations, this is business-as-usual-but-we-call-it-devops-because-there's-a-Jenkins-server.

I want more technology organizations to understand that the DevOps function reaches all the way back to core architecture. If you are not able to build and test a shippable unit of code in less than ten minutes, you're not doing continuous integration or continuous deployment, and I guarantee you there are developers and test engineers sitting on their hands. A mid-level sysadmin is not going to be able to engage with your software architects to establish the changes needed to move to an effective CI/CD approach. Monolithic enterprise app builds can be broken down, but it takes an architectural vision that comes from the experience of building microservices, containerized apps, and complex integration projects -- not from managing build tools and source control systems.

The deployment landscape has changed dramatically in the last ten years. I won't repeat the thousands of articles explaining that here. What I will say is this: If you are still thinking in terms of server and tool management separate from software architecture, you are not doing DevOps. Hold your software engineers accountable for process violations, train your Operations staff in the skills needed to survive (scripting and automation), and have a fully integrated technology team.