OP + NT = VEOP

The title of this blog represents a concept I have been battling for more than three decades. For this reason, it did not surprise me when it popped up in cyberspace a few weeks ago.
I was cruising the web for comments on CD and CI when I ran into a thread in which folks were commenting about tools. As I was perusing the posts, I realized where it was going. When developers who are into devops start talking about tools, at some point the comments invariably turn to the subject of Jenkins.

In my opinion, Jenkins is clearly an extremely good tool when used for what it was intended – the automation of Continuous Integration in individual teams. It’s no surprise why development teams in small, medium and large organizations adopt the tool – it’s relatively easy to set up and use, and for that reason it enjoys support the likes of which is only seen in cult religions and Grateful Dead fan clubs.
However, the reality is that when a small organization grows into an enterprise, the limitations of Jenkins can become a roadblock to the goals of that enterprise. The same can happen in enterprises where team members bring with them the tools they used in their earlier experiences at smaller organizations. Of course, normal human behavior is to repeat what works. In the case of Jenkins, what happens is that individual instances of the tool begin to pop-up all over the enterprise.
Still, what works for a team will not necessarily work for the enterprise, where the goals of governance and the information needed to exercise it require centralized reporting and control. The toughest challenge to making good decisions is having good information! There is a name for this proliferation of isolated Jenkins instances – “Jenkins Sprawl .” Jenkins falls short in this environment. It doesn't scale up into an enterprise because the instances cannot easily talk to each other, and the only centralized control and metrics that exist is what you put together with your own resources.
This brings us to the point of this story. One of the participants in the discussion thread confidently pointed out that there are companies offering virtualization of Jenkins, and claiming that by virtualizing Jenkins you can get rid of Jenkins Sprawl.
That, in my humble opinion, is very wishful thinking. It demonstrates a classic misunderstanding of the concept of “The Cloud.” The “cloud” is a marketing term used to describe a collection of mirrors and smoke used to “hide” what is and has always been there – an IT infrastructure that must be maintained and operated in order to provide value in the form of services. Trying to hide the Jenkins Sprawl in a cloud, public or private, is an exercise in futility. The end result will always be that it’s still there and will continue to cause the same problems for your organization as if you operated the instances of the tool in a physical infrastructure.
Essentially, the poster was trying to make the case that:
Jenkins + Cloud = Enterprise CI Solution
If we were to follow that logic, the following should also be true:
MS Access + AWS = Enterprise DB Solution
(You DBA's can take a break from reading this until you stop laughing.) The reality is that a simple application of algebra shows that:
Jenkins Sprawl + Virtualization = Virtualized Jenkins Sprawl
It’s still sprawl. Putting on horse blinders or throwing up a smoke screen won’t make the problem go away. Which brings us back full circle to the title of this blog…
OP + NT = VEOP
**** Take an Old Process, throw New Technology at it, and the only result you will get is a Very Expensive Old Process.

To learn more on overcoming the challenges of Jenkins sprawl, and how you can move from CI to CD - check out our free guide.