At container-oriented conferences, whenever a vendor or an open source contributor demonstrates the ease with which developers deploy containers to production, usually there are cheers. But in large enterprises, especially those that maintain strict compliance guidelines, it’s IT that makes the decisions about what gets moved from development to production, and how it is done.
This is what you might call the anti-RedMonk stance. In reality, nothing is as cut and dry as developers XOR operators being king. I’ve been in many strategy discussions over the past 5 years where the people involved would love for just one of them to be rulers of the roost. It’s make setting strategy so much easier than catering to both.
In my experience, it’s more like this: developers have a tremendous amount of influence and devilish-steering over long-term IT department purchases, while IT people control the gates and money.
- Developers can also just subvert IT and totally ignore them. You get speed and flexiblity, but the trade-off is inefficiencies in the long-term: everyone is doing something slightly different so there’s no economies of scale with respect to knowledge, culture, or costs. (There’s a loop-hole where you all decide, for example, to run on AWS and “bottoms-up” decide to start collaborating and “work together” and all that – I’m not sure that pans out in donkey-land without a lot of centralized change management, though see below on DevOps.)
- Operators can set orginization wide standards but have to “force” developers to follow their dictates. So, if you want orginization-wide standardization and “someone else” to pay the bill and help run it, you have to go through IT. Here, you have ultimate control and “governance”, but you sacrifice flexiblity and speed. (There’s a loop-hole here where IT establishes a centralized “cloud platform” [to use my work’s parlance] and lets the developers do whatever they want in the confines/contract on that box/platform.)
Of course, many of us have been trying to reuinite this “house divided” for several years, cf. DevOps. Hopefully that’ll pan out because what we really need are both those functions working together to not build boxes or subvert corporate best practices, but to focus on building good products and IT services. Good luck!