DevOps Journey

Introduction

Few years ago I was approached to go for a short term contract for an online retailer, nothing unusual there for me, but during the preamble with the recruitment consultant he was talking about what sort of contracts I would normally go for.  I explained that I normally ended up being a bridge between the development team and operations team, he exclaimed you do DevOps that is perfect I have a different role you might be interested in.

I was bemused, I do what?  having worked in many companies small and large I was able to talk with operations people and understand where they were coming from, seemingly this was a rare skill.  Having never heard of DevOps I went and looked at what this meant and was intrigues.  This was in the early days of DevOps, and I liked I could never imagine though, but should of guessed, that over the years I saw more articles talking about how DevOps was going to change the world, how this product or that product would when implemented solve your DevOps problem.  Yea as we all know this is the typical cycle of new, we saw the same when Agile broke out into more mainstream products.

So what your asking, how does this affect me?

What does it mean?

So What Is It

First off, DevOps is no magic bullet, there is not one.  Sorry all what we are trying to do is hard, what we are trying to achieve is hard.  There is no on methodology that we can say do and everything will be ok.  The reasons for this are myriad but it basically comes down to the fact that business do not know exactly what they want, but they want it now and will scream if it is not working as expected.  This is not a dig at our colleagues on the business side of an organisation, try it yourself.  Try to specify a compiler or a web environment and see if you get it exactly right first time, go on try it I dare you.  Now try and assemble a team who can take your specs, convert to a working system and test with no changes and get it right first time.  I doubt anyone can actually do this.

DevOps is not about technology, it should be about people working together to remove friction between two competing desires.  The developers want their shiny new code released and to be used the operations want stability and to minimize change as each change is a point of potential instability.  By working together we can find ways to bring the two sides together, technology can help but if a developer writes bad code then no amount of technology will stop the instability sneaking in.  A large part of my working life is trying to explain to developers that having hundreds of configuration settings, yes I have seen this, is not a good idea and why its not a good idea.  Some developers understand this some don’t, the ones that do ask how can we store settings so that its easier to traverse environments.  Of course the operations guys will go change configuration settings and not tell the development team, and then complain that the configuration files they get are incorrect and need changing for each release, the better ones soon realise they need to work with the development teams if they are going to do this.  This is just one example of how life can be made easier, and seriously it should not need a technology / methodology to enable this its just communication.