Every great movement has its weaknesses, be the movement social, technical, or political, there are always ways in which it falls short and steps must be taken. DevOps is not some special case that is pure, and if you’ve worked in it, you know how very true that statement is. From meetings that are a tug-of-war to failures that aren’t readily traceable or automation that spawns problems across a datacenter, there are definitely weaknesses in the process.
But like any good movement, the benefits are perceived to be worth the work to minimize the weaknesses. If stability, agility, and security can be served by the standardization and improved communication of DevOps, the perception is accurate.
While it takes a commitment of man-hours, the meetings can be gotten through with disparate interests being satisfied, failures can be traced and changes made to make certain it doesn’t happen again, and cascading errors can be prevented with careful analysis and planning. Even if such a cascading error does crop up, once it has occurred you can take steps to keep it from recurring.
The problem that is the bane of DevOps is not one of these things, it is a simple problem encountered in every IT shop. Complexity. The volume of complexity in IT is astounding, and it is difficult to take complex systems and effectively automate them without a massive investment in man-hours and possibly budget also.
While there are plenty of readily available examples of the levels IT complexity, I will draw upon my recent experience at F5 Networks to offer one single example. F5’s BIG-IP is a stellar platform for all types of traffic optimization and more. From security to image minification, BIG-IP can do it. The thing is, offering the breadth of possibilities that BIG-IP does introduces complexity. The number of configuration objects and the number of parameters that can be configured for those objects is daunting.
But F5 saw that this was a problem (real or perceived), and invested the man-hours to make life easier for customers. Of course they’re a business, so it wasn’t some great altruistic move, but that’s not the point. When they released version 1.0 of iApps, their deployment automation and configuration streamlining solution, the time to deploy the network resources for a typical app was reduced to a fraction of manual deployment man-hours.
The idea is to set some defaults for all of those parameters and provide a UI to ask how to configure the remaining elements. This allows IT to set the parameters that are predefined policies and less flexible application-to-application, while allowing the more adaptable parameters to be defined at deployment. It also allows easy replication of existing deployments.
The only drawback to the original deployment scenarios was its lack of true automation. Over time F5 has added API interfaces to build and deploy iApps, easing that crucial issue.
The benefit is that F5 gear is easier to use – particularly with their selection of pre-built iApps that you can use out of the box – but it came at a cost in man-hours. Simply put, the complexity was removed via iApps, but when you need it, you can always dip back to the traditional way of implementing cascading objects.
Am I selling you F5 gear? No. I’m simply offering one example of extreme complexity created by adaptability that was overcome and the result was a huge positive. And pointing out it took effort to get there. Dedicated effort. Complexity is just another surmountable obstacle, if you address it correctly.
It takes investment. You have to set the time aside. This stuff doesn’t happen on its own, and too many enterprises try to do DevOps in their spare time. Yes, everyone is crazy busy, but peeling off some hours today to dedicate can reduce man-hour overhead of your systems moving forward. You need to look at complex processes and break them down to the smallest chunks you think you’ll need, then automate those.
This approach has the added benefit of making management of devops implementation easier. Meetings are much shorter if the part you are talking about is focused on a single task, utilizing a subset of the infrastructure.
If you’re going to do it, set aside the time. Do it right, and reap the benefits.