How to Build a Silo Faster: Not Enough Ops in your Devops
We need to remember that operations isn’t just about deploying applications, it’s about deploying applications within a much larger, interdependent ecosystem. One of the key focuses of devops – tha...
Published Mar 02, 2011
Version 1.0Lori_MacVittie
Employee
Joined October 17, 2006
Lori_MacVittie
Employee
Joined October 17, 2006
Lori_MacVittie1
Mar 02, 2011Nimbostratus
@Patrick
In general I agree. Many of the practical tools are not open, abstracted, or in some cases even available to include the network/application network in devops.
In cases where they are - they're often focused either on (a) config or (b) run-time, but rarely both. And both are necessary in the long run. Provisioning on-demand and reacting to changes require run-time configuration - combination of both. So you're not off the mark at all to say that vendors need to pay more attention to the needs of devops if we're going to successfully move forward toward an automated data center.
So here's the question I have - who is (or should be) responsible for integration? Chef and Puppet are very popular, for example, in achieving the integration and automation necessary. When an appropriate set of tools (we have iControl for run-time and configuration-time as well as TMSH, a remote capable scripting language that's very object-oriented in nature) are available, should the vendor be responsible for integrating into existing systems or should that be left to the devops folks?
Lori