It was back in October of 2009 that the first DevOps Days event was held in Ghent, Belgium. While I did not personally attend that first gathering, I was lucky enough to be at another conference called CITCON the year before (September 2008 in Amsterdam) where I came across some of the same people involved in the early days of DevOps. I bring this up now to reflect on the mindset of the time, reflect on how the movement has progressed and call for a renewed commitment to collaboration and teamwork in the pursuit of DevOps.
As I look across the landscape of DevOps adoption today (and Agile for that matter), I can’t help but think we are still in some intermediate, chrysalis state. I see a lot of “silo mentality” around even as DevOps has gone mainstream. I realize the irony of this statement given how I have carved out a professional niche for myself as a so-called “DevOps subject matter expert (SME)” but bear with me for a moment.
My recollection of the zeitgeist of that 2008/2009 period is that it was very much about enabling the adoption of Agile practices across IT teams as much as it was about finding better ways of working with Environments and Operations teams — “sysadmins”. It was bringing Agile practices like Test Driven Development, frequent releases and creating feedback loops to the world of Operations. Cooperation between Development and Operations teams was at the center of the discussion. As Development teams were working at faster speeds and experimenting with, say, automated deployments into test environments, the availability of those environments (usually shared) was the first obstacle to the flow of value along the software delivery pipeline. Operations teams were having to react to a constant drumbeat of requests for more reliable environments to accommodate those smaller, more frequent Development iterations.
Those early adopters of DevOps were mostly Operations people who bought in to the principles of Agile and who sought to work with, rather than against, Developers to maximize the efficiency of the entire delivery apparatus—from idea to running in Production in the most fluid way. An explosion in the availability of Continuous Integration software, Infrastructure as Code scripting and Infrastructure Orchestration tooling from the open source world, helped those early adopters revolutionize their software delivery practices in meaningful ways. Refactoring your release pipeline became cheap and fun (if you loved coding). Writing code for provisioning environments gave Development and Operations a common language with which to relate better to each other. Not to mention cutting provisioning times for new environments by many factors of magnitude. The mythical “multi-skilled Agile team” with Development and Operations working closely together became very much attainable! And with the arrival of cloud, the argument for which way of working was most effective was closed.
Before DevOps, you often saw a “release” or “environments” team wedged in the middle between Development and Operations. They were often responsible for wrangling code and configuration from the Development side and bringing it across ever closer to Production on the Operations side—sanitizing and standardizing things along the way. As the DevOps movement gained popularity, it was only natural that a lot of these “glue” teams began morphing into a “DevOps Team”. Rather than continue working as code couriers, they began specializing in tooling and automation and began providing Agility-as-a-service to the growing population of Agile teams.
Today, that pattern of DevOps specialization has given rise, in some places, to an approach where automation and tooling expertise is germinated centrally and then parceled out as needed across the rest of an organization. Creating a people dichotomy of those teams “in” DevOps and those “out” of DevOps.
Now, because of the way you sometimes have to bootstrap transformation, I think this centralization is a necessary step in the beginning. It is easier to inject investment into building new capabilities into a catalyst like a dedicated “DevOps Team”, than trying to transform the whole of your delivery organization all at once. But I can’t help but think that now, 7 to 8 years later, we may have to move past that intermediate state and liberate the DevOps “mindset” to permeate everything we do along the software delivery lifecycle—agility and “New Tech” becoming the new normal.
I can see how some may think that the DevOps approach isn’t for them and how silos provide needed structure. For me, DevOps is the best way I know for how to build highly-engaged, highly-effective IT teams with or without the constraints of silos. But I guess I see DevOps as a bridge-building approach and not a toolbelt. I’ve always liked the idea of bringing together not just Development and Operations but Testing, DBAs, Security, Architecture and many others!
So… if you consider yourself on the inside of the DevOps movement, I encourage you to look around and look for someone to connect with who might feel on the outside. If you’re on the outside looking in, come on in, there’s no secret handshake required to join! I welcome your contribution and expertise to the evolution of Rotating to the New.