Commentary from 451’s Peter ffoulkes:

The transformation of IT to a ‘client service’ model is notable and gaining momentum. While this is occurring in many forms, cloud-oriented projects are consolidating in an activity level at three times the level of other supporting projects, with internal private cloud projects leading the pack at 37%. Over the last year of the Cloud Computing Study there has been some pullback of public cloud activity. While these projects still outweigh traditional IT or ‘cloud-readiness’ projects at a similar level, there has been a small but noticeable shift toward private cloud project activity.

(via http://theinfopro.blogs.451research.com/index.php/2014/02/moving-beyond-hype-is-cloud-becoming-an-addiction/)

[T]here will be classes of developers that go after Git and they’ll love Git for what it allows them to do which is to stay off the radar until their tiered promotion gets it ultimately to visibility, but there will be other shops that want to have that visibility the entire time and their compliance or governance or whatever the management driven stuff that is required will keep it around.

Chris Clarke, CollabNet

Commentary from 451’s Peter ffoulkes:

The transformation of IT to a ‘client service’ model is notable and gaining momentum. While this is occurring in many forms, cloud-oriented projects are consolidating in an activity level at three times the level of other supporting projects, with internal private cloud projects leading the pack at 37%. Over the last year of the Cloud Computing Study there has been some pullback of public cloud activity. While these projects still outweigh traditional IT or ‘cloud-readiness’ projects at a similar level, there has been a small but noticeable shift toward private cloud project activity.

(via http://theinfopro.blogs.451research.com/index.php/2014/02/moving-beyond-hype-is-cloud-becoming-an-addiction/)

[T]here will be classes of developers that go after Git and they’ll love Git for what it allows them to do which is to stay off the radar until their tiered promotion gets it ultimately to visibility, but there will be other shops that want to have that visibility the entire time and their compliance or governance or whatever the management driven stuff that is required will keep it around.

Chris Clarke, CollabNet

Secondly, when evaluating new IT hardware and software assets for potential adoption, you need to institute a much stronger requirement for programmability and open APIs. Complete automation of your infrastructure requires programmatic access, and it’s simply insufficient to only have control via graphical interfaces. This isn’t just about provisioning and configuration support via such APIs, you also need to ensure that vendors are providing reliable APIs to get sufficiently detailed status. A core tenet of DevOps is the ability to measure the state of your infrastructure for future improvement and this really needs to be automated programmatically. Ideally these APIs for automation and measurement are simple, easy to adopt, and accessible to people who aren’t full-time software engineers. Thus, beware of complex, language-specific APIs, and strongly lean towards vendors using simple HTTP or REST APIs and standard, easily parsable data formats like JSON.

–Nigel Kersten, Puppet Lab’s CIO. Also, see this interview I did with Nigel way back in 2008 when Nigel was using Puppet to manage the Mac desktops (!) at Google.

Secondly, when evaluating new IT hardware and software assets for potential adoption, you need to institute a much stronger requirement for programmability and open APIs. Complete automation of your infrastructure requires programmatic access, and it’s simply insufficient to only have control via graphical interfaces. This isn’t just about provisioning and configuration support via such APIs, you also need to ensure that vendors are providing reliable APIs to get sufficiently detailed status. A core tenet of DevOps is the ability to measure the state of your infrastructure for future improvement and this really needs to be automated programmatically. Ideally these APIs for automation and measurement are simple, easy to adopt, and accessible to people who aren’t full-time software engineers. Thus, beware of complex, language-specific APIs, and strongly lean towards vendors using simple HTTP or REST APIs and standard, easily parsable data formats like JSON.

–Nigel Kersten, Puppet Lab’s CIO. Also, see this interview I did with Nigel way back in 2008 when Nigel was using Puppet to manage the Mac desktops (!) at Google.

Secondly, when evaluating new IT hardware and software assets for potential adoption, you need to institute a much stronger requirement for programmability and open APIs. Complete automation of your infrastructure requires programmatic access, and it’s simply insufficient to only have control via graphical interfaces. This isn’t just about provisioning and configuration support via such APIs, you also need to ensure that vendors are providing reliable APIs to get sufficiently detailed status. A core tenet of DevOps is the ability to measure the state of your infrastructure for future improvement and this really needs to be automated programmatically. Ideally these APIs for automation and measurement are simple, easy to adopt, and accessible to people who aren’t full-time software engineers. Thus, beware of complex, language-specific APIs, and strongly lean towards vendors using simple HTTP or REST APIs and standard, easily parsable data formats like JSON.

–Nigel Kersten, Puppet Lab’s CIO. Also, see this interview I did with Nigel way back in 2008 when Nigel was using Puppet to manage the Mac desktops (!) at Google.