When you read about the Devops movement, there is generally an assumption of greenfield. Those that address change usually are addressing an organization with less than 100 IT workers or ones that are bringing less than 10 years of history with them. While devops (at least the idea behind it) is more than a fad, I think that the conversation focuses too heavily on implementation and charts, and not enough on strategy and purpose. I will try and use some illustrative examples of what I feel are the mechanics behind devops, cloud-computing, and apply them to the Enterprise.
How did we get here?
So distributed computing… Like any cool new technology, businesses flocked to Unix as a cheaper alternative to mainframes. The adoption looked like most technological adoption. It didn’t replace the mainframe for core business functionality (often times, still hasn’t), mostly due to fear of risk. But projects sprung up. Each project evaluated its needs, hired staffing, bought hardware, developed and deployed.
At this point there were dedicated developers, sysadmins, project personnel, hardware, and software, all of which were underutilized and non-portable. And the staff could not easily be reallocated since each project required learning and working with an entirely different stack: You probably had HP-UX, DB2, and C++ one place. Then Solaris, Oracle, and Java for another. And projects that matched tools, didn’t match versions or consumption patters.
From each consideration, it made sense. But as a whole it was a mess.
To address the issue, phase 2 begins. Standardize all the things! Timed with the move to commodity software/hardware, management addresses the resource sprawl by standardization. Instead of teams organized by project or business unit, teams are reorganized by function. The sysadmin team, the hardware team, the DBA team, etc. The choices available for development are reduced to Linux, Java, and a single RDBMS. Process is in place to ensure all projects follow the rules through oversight.
Now costs have been reduced, but time to market has grown. The business doesn’t understand why it takes 1-2 years to get a new application into production. More resources are dedicated to oversight than to construction. The business is frustrated, development is frustrated, operations is frustrated. Management is itchy to buy into something new and vendors smell blood.
Process as water
In the beginning of the story of distributed, a project is like a bucket of water. We just dumped it on the ground and it rand generally downhill to the destination. It took whatever path was easiest for it. So depending on each projects’ perspective and the conditions at the time, they took their own path.
Standardization meant taking each bucket and rather than pouring it and making it run, we carried each bucket to its destination. They generally followed the same path (depending on who was carrying the bucket), but it is energy intensive. The water resents being constrained by the bucket carriers, and the bucket carriers resent the weight. Many times, the next evolution of this is a bucket brigade. The person who cares about infrastructure costs passes on to the person who cares about information security, and on to the operations policy, etc. And sometimes buckets get set down along the way.
The bucket brigade, while more effective than before, is expensive and ever expansive. The number of people carrying the bucket always grows, and it always increases opportunities for projects to be slowed down. Also, oversight always depends on the overseer. Development gets frustrated by seemingly constantly changing requirements, the process managers are frustrated by development always trying to skirt the rules, and no one feels like their concerns are being addressed.
Automation, not standardization
The solution is automation instead of rules and enforcement. Stop lugging water, and start building aqueducts. This is what things like Devops, cloud computing, IaaS, and PaaS promote. You go back to the first state and you ensure that the easiest path is the “right” path. You ensure that if people conform to the desired parameters they decrease effort and time to market.
Let People Succeed
There is an easy litmus test to this: if a job is following a procedure it needs to be done by automation. This sounds harsh, but someone who only follows procedure has 0 opportunity for success. They only have the ability to fail. People’s energy needs to be spent making decisions where they can provide value.
It sounds wrong, but try not to write down how something needs to be done. Make something just do it. For those things you can’t tie together, have authoritative enforced data sources. Let the system be the documentation. Then you ensure it is never out of date. And if you thought [FILL IN THE REGULATORY CONCERN] auditors liked good documentation, they love live queryable systems. Well, except the whole reducing billable hours part.
Nothing alleviates the work.
Adopting any solution to this does not take the work out of it. It just makes the work constructive. Devops-style configuration management is a lot of work, but you only have to do it once. Standing up PaaS, tying CI/CD into it, extending it to support your business, etc. is a lot of work, but then every project that can fit in the PaaS benefits. No vendor is going to have you something that is a ready-made solution to your problem. Remember, every time it has more than one way of doing something, that’s work. And when a vendor says it can do it however you want, that means you’re building it yourself.