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.0
Lori_MacVittie
Employee
Employee
Lori_MacVittie1
Nimbostratus
Nimbostratus@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