Aneel LakhaniOperators who develop. Infrastructure as code. Automation permeating systems. Very good. As a one time sysadmin, I hold to the notion that the better an operator the more of her work she eliminates through code.
But developers operating? No. I don’t want coders, especially app coders, anywhere near infrastructure. Specialization and abstraction create a big gap from developers to infrastructure. Taking systems for granted makes them dangerous.
Enter DevOps/NoOps. Developers are responsible for their code: what it uses, where it goes, how it works, when it breaks, who it affects. All of it. All the time. They have to learn how systems that deliver and execute code function. They have to plow through the abstractions and close the distance to infrastructure.
That’s how things started anyway. Le Roi est mort, vive le Roi.
4 responses so far ↓
1 Chris Haddad May 31, 2012 at 9:24 pm
Aneel, do you see NoOps running counter to IT governance? How does one layer cost control, help desk, service catalogue standardization, and solution support in a NoOps world? I’ve authored a blog post describing a cautionary perspective to NoOps: http://blog.cobia.net/cobiacomm/2012/05/30/taming-noops-and-open-cloud-architecture-with-cloud-governance/
2 Aneel Lakhani June 1, 2012 at 12:36 am
I don’t see why NoOps would run counter to governance, unless your governance model is inflexible to the point of uselessness. Extend IT governance to include NoOps. A new operating model–ANY new operating model–shouldn’t phase a rational approach to governance.
Cost control on what? Help desk for who? Service catalog for what services?
NoOps are the folks creating and running the apps that others use.
Why would controlling the costs they incur be any different from controlling the cost any other IT function incurs?
Why does a different operating model impact end user help desk? I
Why does a different operating model impact end user service catalogs? Isn’t the whole point to abstract out the construction and operation of services used?
Solution support *improves* with NoOps because you’re removing people and layers from the process of problem identification and resolution.
3 Matt Watson - Stackify DevOps July 4, 2012 at 8:17 pm
“I don’t want coders, especially app coders, anywhere near infrastructure. Specialization and abstraction create a big gap from developers to infrastructure. ”
In response to this statement… Developers need access to servers to do application troubleshooting. They need access to log files, windows event viewer, verify deployments, check config files, run database queries, etc. A layer of abstraction is needed to give developers access to this information, without giving the developers actual server access. Check out Stackify. We are working on solving this exact problem. http://www.Stackify.com
Thanks,
Matt Watson
Founder, CEO
Stackify
4 Aneel Lakhani July 6, 2012 at 3:47 pm
@Matt
You have a point. What Stackify does is almost anti-devops: getting devs access to infrastructure-generated operational data without actually giving them purview over ops. There’s probably quite a market for that.
Taking my statement out of context in order to do some free advertising and get some linkjuice from gartner.com to your company is less good.
Leave a Comment