Pillar 2 - Operations Engineers

This is second post in the The Three Pillars of DevOps series

Part 1 – The Three Pillars of DevOps
Part 2 – Pillar #1 - Developers
Part 3 – Pillar #2 - Operations Engineers
Part 4 – Pillar #3 - Management

In this post we will dive in to the second pillar – Operations Engineers.

Being part of the Pillar

1. Allow everyone to consume your infrastructure

   Infrastructure is there to be used. You are there to allow your business to create revenue, as much as possible, and in as short a time as possible.

   They will need resources in order to do that. You have probably been working with cloud and virtualization – long before they have, and have a decent amount of expertise and infrastructure already in place.

   In order to allow development teams to do their work, they will need resources, for a number of solutions, be it Continuous Integration, Continuous Delivery – or just plain old sandboxes for development purposes.

   Help them use what you have, help them build their own if they need it.

2. Become a trusted broker for your development teams

   Developers need your help. They have deadlines and problems that they are dealing with and will have a very difficult time learning all you know in a short time.

   Explain to them what the benefits are of using different kinds of infrastructure, when they should go to the cloud, and when they should stay in house. What are the security implications of choosing a cloud solution, what they need to be aware of. They are also on a journey and need to adapt to this new world.

3. Make it as easy as possible

   Again, infrastructure is there to be used. The same way that you take for granted that when you flip the light switch in your room you expect the lights to go on, that is what developers and the organization expect to happen when they need to turn on a server.

   Of course we all know that when you flip on a switch – there are so many things that happen, so much infrastructure is needed, from wiring to circuit boards, to light fixtures, to metering, to electric company.. (and so on..), but all of that is transparent to end user.

   You should aspire to make your infrastructure as easy to consume as the electricity in the building. No-one is saying that it is easy, but that should be your end goal.

4. Work with the development teams to help produce quality products

   The development teams have a way of doing things, not necessarily is this best way, and you probably no longer have a number of grey hairs that you pulled out over the years trying to solve problems created by your development teams.

   Explain to them what does work, what does not, and why. Work with them together to find a solution that acceptable and will work for all sides.

   Don’t expect that things will be perfect the first time around, because they won’t. Iterate and make improvements in stages, small steps until you get to Nirvana.

   Go through deployment models with them, explain to them what scaling is, how high availability is achievable in this new world, and what they need to change in order to get there.

Not being part of the Pillar (or being Samson)

1. Be an infrastructure hugger

   We paid for it. We installed it. I know more about this infrastructure than any of these developers think they know.

   They cannot use what we have already because:

   • We have no capacity
   • The environment is not suitable for their needs
   • They will make a huge mess

   Let them go and buy their own, learn what we have for the past 5-10 years and then we will talk.

2. Create workarounds to accommodate badly written software

   Software is not perfect, sometimes it is just really crappy. And over the years you have learned to deal with that. Creating cron jobs to restart processes on a regular basis due to a memory leak, or creating cluster mechanisms to to solve high availability issues.

   These workarounds make your life more livable, manageable, but do not solve the underlying issue, just work as a band-aid until they get their stuff together and fix the junk they wrote.

   And since the development teams don’t care about these things any way – you never relayed back to them that these issues exist.

3. Let them go and use AWS if they want to, and hang themselves..

   We cannot provide the developers the kind of cloud experience that the demand. It is too difficult for us to make these changes, due to budget constraints, manpower or perhaps time constraints as well.

   If they need these things – let them go the where it is available, and pay for it themselves, and let them worry about their own issues of security, administration etc..

Next up we will look at Pillar #3 – Management.