Last night at the Geek Whisperers meetup, John Troyer and I had a discussion around DevOps, The Phoenix Project, and how much of it was pertinent to Enterprise IT and “big harness” applications like SAP and Siebel where incremental releases aren’t possible. Most well-ran enterprises already have an existing release management methodology - the problem becomes ‘how do you implement more agile devops processes without compromising rigor?’ Trying to map large applications into a more agile release management system is almost destined to fail - rather it is necessary to insulate the “legacy enterprise crapplications” from agile releases, maintain separate release windows, and endeavor to take different release philosophies based on what makes sense.
Which was interesting to me, but not particularly post worthy - until I came across this post from Maish on the currently recommended VMware upgrade sequence. If you’re running your enterprise release schedule even weekly, you’re looking at 5-8 weeks for a full rollout if its supported to stagger the rollout (or increase the risk of the deployment and try to forklift all the components in one release window). Multiply that by the number of clusters and environments that you need to upgrade, and it becomes a fairly complicated exercise. I’m not picking on VMware- OpenStack and other large OSS platforms are equally difficult to upgrade. Complex software leads to complex upgrades.
Developing, testing, and implementing these upgrades takes a large amount of un-recoverable internal engineering hours - hours that could likely be used on more business-beneficial efforts. This shows the real value of converged, fully supported stacks such as Vblock - they manage the development, testing, and implementation of the stack that your business critical applications run on. This frees up internal resource time to focus on projects that provide a greater business benefit.
The benefit of Vblock over reference architectures such as VSPEX and Flexpod is a greater amount of testing, and greater familiarity the the actual configuration deployed. Many reference architectures require the VAR to perform the testing at a much smaller scale than VCE. How much risk is acceptable, even with reference architecture? Each enterprise needs to answer this on their own (and many still prefer the riskiest and most resource intensive model - rolling their own).
How does this tie back to release management and DevOps? It is a third mechanism to reduce the risk of upgrades / promotions to production.

