DevOps Mind Map

In the last couple of years I’ve become very interested in the interactions and collaboration between development and operations teams, the ‘last mile’ of delivering working software into production, and keeping that software healthy and sustainable in production. I’ve had some satisfying experiences working in teams that have bridged part of the divide between development and ops.

Conveniently in the last few months the ‘DevOps’ movement has arrived and a lot of very smart and interesting people have been sharing their ideas. DevOps resonates incredibly loudly with me – bringing focus to both the people and incentive problems that can hinder collaboration between development and ops, with some interesting technical problems around faster delivery and the necessary investment in automation and configuration management.

I find the DevOps landscape very complex to visualise – many of the pieces are interdependant. To get some sense of the breadth, I drew the mind map below. It’s a big mix of different levels of abstraction, and later I’ll try to draw out some themes.

(click through for a full-size image)

I’m sure I’ve missed some major areas of concern, so if you can be bothered looking at the image and it prompts a thought – please do make a comment.

6 thoughts on “DevOps Mind Map”

  1. Great post. Its nice to finally see those of us who have been juggling development and sysadmin work getting cred with the ‘devops’ movement 😉 Additionally I have found a great deal of use for mind-mapping for practically anything where collaboration is required. Its the perfect ‘agile diagram’.

  2. “More frequent app deployments” and “Continuous deployment” need a line to a new concept named “App designed for hot/quick deploys”.

    Applications can be designed in a way to allow for minimal/no down-time (eg. reference data with start/end times, property file listeners to automatically reload configuration changes, redundancy to allow for live deployments).

  3. Thanks Gede – great input. I think that those things are important (live reloading of settings etc) but should not be designed in from the outset (but then I’m an emergent design guy). Frameworks like OSGi are compelling, but charge a very high complexity tax. Allowing for fast (and automated) rolling restarts including re-deployment of externalised settings is most important – and as you say this requires redundancy and a simple architecture.

Leave a Reply

Your email address will not be published. Required fields are marked *