A few weeks ago James sent me an e-mail saying that he’d been coming across this thing called ‘DevOps’ a lot lately and it seemed like it might be the closest thing yet to our Platform Architect role, outside of EMC Consulting.
The Platform Architect team is a small, and mostly merry, band of technical consultants who typically started out their careers on the Infrastructure side of IT and have evolved to straddle the fence that divides the Infrastructure and Development worlds - if you read Grace’s blogs, then you’ll already have a fair idea of the types of things we get up to.
So getting back to my introduction to the DevOps world, I was intrigued by it not least because I often struggle to define what we as PA’s do when talking to Clients without getting bogged-down in details; such is the breadth of what we have to cover. Hence why coming across a term with a defined understanding in the outside world was of such interest to me, both in terms of talking to Clients as well as how we find and recruit new PA’s.
Hunting around for some further reading, one of the first articles I came across, was a guest post by Stephen Nelson-Smith on the rather coolly-named jedi.be blog (Just Enough Developed Infrastructure – nice!) which resonated with me hugely. As consultants, clearly we’re not sysadmins in the purest sense, but we are invariably the sysadmins for those projects that we’re involved with and as such the same pain points and desire to make things better still ring true. However, one of the benefits of operating within the team at EMC Consulting is that the typical barriers between disciplines that Stephen mentions are far less prevalent, as is the siloisation, mainly due to working in small to medium-sized project teams. That said, we will often collaborate with the Client’s various teams and it is here that we regularly see exactly the tensions between them that Stephen highlights, and in that respect our role is very much a bridging one too.
One thing that seems notably absent from what I’ve read about DevOps (to-date) is any mention of Application Lifecycle Management (ALM) – this forms a fairly large part of the PA role here and I’m keen to learn whether ALM is indeed considered outside of DevOps, or whether I just haven’t been looking in the right places. On the surface, much of what is talked about seems relevant to different parts of ALM but no-one seems to be making any explicit references to it. I’d be really interested to hear from anyone who can shed some light on this, one way or the other.
Configuration Management seems, understandably, to be a key topic in the DevOps world so in my next post I want to discuss an approach for tackling application configuration management that I’ve been working on lately. I use a lowercase C & M on purpose, as it is very much a lightweight approach that aims to remove as much friction as possible from the task of making application configuration files environment-agnostic (e.g. not hard-coding server names, credentials, paths etc.) whilst at the same time ensuring that the need for this activity is still very much front-and-centre in the development team’s mind.