Putting the Dev in DevOps

I recently attended devopsdays Rome.  This was my first time at a devopsdays conference and I enjoyed the mix of talks and open spaces sessions.  It was obvious that the presenters and the attendees have felt the pain of trying to introduce continuous delivery in their organizations and were there to share stories and seek advice to help.

The theme for this conference was “Culture”.  If DevOps is a “culture thing”, then surely we need to involve both Dev and Ops.  The surprising part was that there did not seem to be anyone from the Dev side of things.  In fact, there were topics like “getting Dev to think in terms of DevOps”.  The goal being to entice developers to think about the infrastructure of their applications including the operational concerns such as: scalability, redundancy, performance, monitoring, and feedback.

Monitoring was a very big topic, being covered by some 70% of the talks.  For this crowd, Puppet, Chef, and CFEngine define configuration management.  But it stopped there. Adding all of the discussions about stacks, tools, and cloud together yields something that looks like PaaS.  It allows them to provision and configure machines or virtual machines to provide well-managed and monitored services on which applications can sit.  However, at that point, Dev has no skin in the game.

Application delivery is needed to get Dev thinking in terms of DevOps.  Specifically, if while developing application components, developers need to concern themselves with how their components will be deployed to an environment and in a state where they can deliver value.

uDeploy deploys complex, multi-component applications.  For example, a simple web site consists of a web component (WAR file) and a database component (DDL).   Continue reading