Gartner released their 2011 Hype Cycle for Cloud (original at gartner.com, other analysis at Software Strategies Blog) today. No big surprises if you’re following the market, but I was amused to see DevOps listed as a transformational technology in the 5-10 year window. Maybe it’s the crowds I hang out with, but I see DevOps as being a methodology that that has reached a level of maturity amongst those who have adopted it.
The bigger question is who else is going to adopt it.
Anyone that has shipped an API with their product knows that the population of API adopters is actually quite low despite initial feedback to the contrary. When we launched the SOAP API for NetScaler back in 2005, I was astounded at the number of people that were downright giddy with anticipation that they would get programmatic access to the system. Since then, the API has matured with a wide array of development tools available, including PowerShell hooks. The API has also kept up with the times with a RESTful version as well.
Those that have adopted the API have generally adopted DevOps methodologies in their infrastructure. They automate everything and the impact is astounding. One customer I recently had lunch with has 1 admin for 4,000 servers. Everything is a script and developer visibility into the process is complete. A long time friend working at a major gaming company shared that they have no dedicated IT staff despite having millions of players driving their hardware 24/7 — developers take turns with the “IT Phone” and when faults occur, the person that wrote the bug takes the on-call person to lunch to apologize for having to deal with the error. Their site is one of the most available on the Internet.
But after the initial excitement wears off, the number of people who actually do DevOps is a lot lower. Following up with someone that was giddy at the prospect of using our APIs often reveals that programming and script automation isn’t a priority because the staff to maintain it isn’t part of the team. In the end, it’s all off the shelf.
It makes sense, really. Most IT teams are not equipped to write software with the necessary caliber to operate 24/7 while coping with all kinds of errors. Developers are usually part of a separate team with a separate agenda and thus don’t participate in the system upkeep in any form.
The root of the problem is the team — it is necessary to have strong systems programmers that are comfortable with both IT and software design/development. This kind of talent is expensive, but does have the impact of holding the value of multiple hands-on server support admins in the level of automation they can bring to the team as a whole. It is a top-down decision that has to originate with management — we are going to automate and we are going to build the right team and leadership to make it happen. Without the right talent mix, the team simply lacks the skills required for a DevOps orientation to succeed and sure enough, the best of intentions fall back to old ways.
Broadly speaking, making DevOps a priority isn’t on the radar for most CIOs. This is not necessarily a mistake. Most of the CIOs I meet are smart capable people that have aligned themselves to the business. In their minds, DevOps level of automation will happen as part of pushing infrastructure to the cloud. Once that is done, the ROI for automating the remaining bits doesn’t make sense. (I, for the record, usually disagree on this point.)
So is DevOps doomed? No, far from it. Is it transformational? Yes. But I would argue that the slope of transformation is steep and we’re rising much faster than a 5-10 year horizon. We just have to fess up that maybe there are less folks on this ship than we’d like there to be and many have already climbed aboard. In, I expect those that climb aboard will be the ones speaking at conferences about IT to server ratios in high growth environments. The rest won’t hear as they go trace a wire from one rack to another.