If your company has adopted DevOps, it could be killing your operations team, which in turn might be slowing your company?s digital transformation.
The Road to Failure is Paved With Good Intentions
If your company has adopted DevOps, it could be slowing your digital transformation. This might seem like the antithesis of your intentions and the designs behind your IT strategy, but the truth is, the way DevOps is implemented in the enterprise can be ineffective and even lead to potential damage.
DevOps, so the story goes, is the unification of Development and Operations as the two departments work together. It?s a culture of working in harmony to create faster release cycles. It follows on from and goes hand-in-hand with agile development, stand-up meetings, Scrum, Kanban, and so on. As DevOps takes off, we?re seeing a herd of technologies like Continuous Integration and infrastructure-as-code being widely adopted. Designed by developers for developers, they all support developer needs; Jenkins, Puppet, and Chef are amongst the most popular names, but literally thousands of different tools exist and each fits a niche development style or a particular environment.
It?s not hard to see a few plot holes in this narrative. Where are Operations? Yes, Developers can now provision their own environments using code, code can be used for application support, and deployments no longer require intervention. And yes, if it breaks, that?s OK. It?s part of the DevOps culture to fail fast, to break things, and to go again without notice. However, it all works if ? and only if ? many of the enterprise circumstances are removed and isolation is implemented. However, how do we implement this in the heavily constrained enterprise core environment? Clearly, a number of questions arise here: Where exactly do the Operations responsibilities (scale, resiliency, integration, security, maintenance and backup, etc.) fit in? What are the benefits of DevOps for them? Is Operations simply being replaced by tools for everything that we depend on? Who will manage these tools?
This isn?t all. Of course, it?s great that developers are given creative license to try new things and to get releases out there, but what happens when something important is on the line? When the business risks itself if an application goes down? How about a dependent application like one of your mainframe jobs? Or if your customers can stand to lose money? Someone has to be accountable for ensuring this doesn?t happen.
Thinking about DevOps can create an illusion that hints at the old ?NoOps? concept whereby an entire enterprise can be built, run, and grow using nothing but code. Only looking at one project or application at a time can mask the risks of attempting this in highly regulated and fragmented enterprise environments.
The Complex World of NoOps
Instagram in the early years, prior to its sale to Facebook, was one of the poster-children NoOps advocates followed. Here, you had a unicorn whose entire IT department consisted of a small number of developers with an interest and ability in ensuring stability and reliability for hundreds of millions of users. Clearly, if they can achieve this, then every large enterprise should be able to achieve the same, perhaps even with ease, the advocates reasoned.
The challenge for a startup whose primary purpose is to upload photos, however, is very different to that facing a multinational bank. Not only that, Instagram developers kept it simple and they didn?t have to deal with complex antiquated legacy systems. Simplification cannot be underestimated when undergoing a digital transformation.
In contrast to the situation at Instagram, a more typical DevOps implementation in the enterprise sees developers using the DevOps banner to navigate their way around the requirements and safety nets of Operations teams that they sometimes perceive as a nuisance (and sometimes correctly so), thus becoming exponentially reliant on an increasing number of tools each team chooses to use. One very large multinational organization I had worked with actually had three departments heavily reliant on three different deployment tools. This is a common scenario these days. This adds needless layers of complexity as the new tools are assimilated from project to project. There is no unity, nor is there a central management. We refer to this phenomenon as tool sprawl.
Clearly, someone needs to ensure that what?s being built actually works. This requires an Operations team to run and manage toolchains. Even if smaller companies can get away without one, the big enterprises cannot afford to take such risks. Because ultimately, Operations teams are the people who ensure everything works together. When you?re small or narrowly focused (Instagram wasn?t small), selecting a few tools to do everything in code may be efficient and save resources, but this solution is often not scalable in the long term.
If DevOps is used as an excuse for NoOps, the digital transformation objective will stall and become confined to singular projects, getting lost in a myriad of interwoven technologies and processes. If you let this spread, the complexity becomes unmanageable and the risks exponentially higher.
Agile Operations
So, how do you ensure that DevOps does not lead to chaos and unmanageable tool sprawl? Well, firstly, the Operations team needs to be trusted and given the responsibility to manage the stability of releases. This does not mean bringing someone in and just dumping the deployment work on to them, else we just create the exact silos DevOps aims to break. Indeed, the most important benefit from an Operations team is not the ability to take all the deployment work off the developers, but to provide knowledge of running systems at scale that the individual development teams do not possess.
By the same token, adding agility does not mean going down the rip-and-replace route and telling your developers to deal with the maintenance of new web-based applications. It includes bringing your outdated but powerful legacy systems in line with modern applications, which by its very nature requires significant amounts of input from Operations to ensure the stability and simplification of such a task. If left to the Development team, the project will lead to the aforementioned toolchain sprawl, without anyone to manage it.
For all of the freedoms that DevOps will afford developers, the systems and environments that they work with, once live, cannot afford to break. Ultimately, the simpler operations are kept, the more agile the development lifecycle will be.
True DevOps is achieved with a sharing of knowledge that allows developers to take responsibility for and manage their code throughout the lifecycle. This is the underlying tenet that your digital transformation requires if it is to be successful.
