This is third 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 Part 5 – Bringing it all together

In this post we will dive in to the third pillar – Management.

Being part of the Pillar

1. DevOps is a cultural change

   Most people do not like change. Personally, I do not have an easy time adapting to change, it makes me nervous, uncertain, unsure. Different people take to change in different ways. Adoption of a DevOps way of working is not a small thing.
   
   Boundaries are no longer clear.
   Who is in charge of what?
   Why do we have to take care of this?
   I have no idea of what this means.
   
   With any big change you should understand what this will do to your organization. See where you will have problems. Where people will need help. Expect that things are going to change. Over time.

2. Support both of the other pillars on the journey

   
   In continuation on the previous point. Help your developers with education. They are no longer responsible for a small part, but rather the big picture.
   
   Help your Operations Engineers with the world of code, again training, courses, books, seminars, pair programming there are a more than a number of ways.
   
   Bring in someone to help and coach your teams throughout the journey, going from waterfall to Agile is a huge change, even more so such a culture change. Help them in the beginning, through the ups and downs, and how they can continuously improve themselves and the way they work.
   

3. Have patience

   This is going to take time. Quite a lot of time. Give the teams the leeway to adapt and learn along the jurney. Let them learn from their mistakes, pave their own path. Your productivity will probably go down in the short term, which also mean that the bottom line might drop as well.
   
   Be prepared for this. Remember, if you are in it for the short term, the quick win, then this is the wrong reason. And it will most probably fail. Almost definitely. Your are here for the long term, even if it means losing in the short term.

Not being part of the Pillar (or being Samson)

1. We should start doing DevOps! Now!

   I went to this interesting seminar where they showed how they are delivering code 10-20 times a day. I want us to start do the same. Next week. Let’s just make some quick changes, merge some teams, get the Devs working together with the Ops, and we should be able to deliver even more often with better quality.
    

2. My employees can do double the work, in less time

   So now that we are ‘doing DevOps’ I don’t need so many people on my teams because they are doing the work on both sides of the fence. They can get their work done and also support the applications they are writing from start to finish with less people, and because they are more efficient probably in less time.

3. There is only one way to get this done.

   Agile, Extreme Programming, Kanban. Rally. We need one tool to monitor and rule it all. One process that everyone has to follow. Everyone has to fit into the box we create. That is the only way we can maintain control.
   
   The groups have to adapt to the way I want it to work. My way or the highway.

Next up we will look at Part 5 of this series – Bringing it all together.

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 Part 5 – Bringing it all together

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.

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 Part 5 – Bringing it all together

In this post we will dive in to the first pillar – Developers.

I apologize in advance – but I will be using a number of stereotypes in this series – on purpose. I will probably exaggerate – also on purpose – but this is in order to get a point across.
I do have the utmost respect for all people in all three pillars – and I promise you, I will dump on each and every single one of the pillars (hopefully equally).

Whenever I hear someone say developers – the first thing that comes to mind is the famous Steve Ballmer dance.

But these people are not as crazy as Steve on stage.
They are probably the people that work with you side by side. They create the things you use – daily.

For example – I can guarantee you that no Operations Engineer or management director was the one who wrote the applications and the functionality built into something that each and every one of us use every single day.

Be it your:

• Web browser
• Mail Client
• Facebook application
• Phone

All of these things need to be written in code. And I have the utmost respect for people who have the capability to create something from scratch and build it into something like the examples above.

Being part of the Pillar

1. Understand what you know how to do best (and learn what you don’t)

   
   I do not know everything, I don’t think anyone can, and if they say they do – then don’t believe them. You know how to write code, you know how create an interface and I could go on with examples all day. But there are also things you don’t understand, such as Operating system security, firewalls, resource usage, network traffic, databases – and again I can go on and on and on…
   
   There are people who have been doing this – just as long as you have been writing code – so use them, consult with them – learn from them.
   

2. Build with the broader picture in mind

   
   Applications do not run in a vacuum – they are part of a complete solution – they need to run in parallel or on top of other applications – so take that into account.
   
   Think about how you will interact with other parts of the solution – because it happen – you will interact with other pieces – all the time.
   

3. Take full responsibility for what you produce

   
   You created it, it is your baby. The same way you bring a child into this world – you worry and care for it. You send them to day care (where someone looks after them) but if there your kid has a fever – you will come and get them – and nurture them back to health.
   

4. Assume the worst will happen (eventually it will!)

   
   Nothing is perfect (and again if someone says it is – don’t believe them). Thinking out of the box and out of your comfort zone, not cutting corners and hoping for the best – but rather planning for the worst case scenario – will make the product you are creating a better one – and you a better developer as well (by the way).

Not being part of the Pillar (or being Samson)

1. The Operations Engineers job cant be that hard

   
   I mean how hard can it be to spin up a server, create a DNS record, run a Load balancer in front and have 5 million people hit the site at the same time. What could possibly go wrong?
   
   This is a quote I just saw yesterday on Twitter.
   
   

   "We don't need an ops person" ... shortly followed by ... "How does DNS work? What's a CIDR? Can't you do it for us?"

   — Colin Panisset (@nonspecialist) August 26, 2015

2. My application is the only one that counts

   
   I am writing something that will change the world. And I heard that this new fangled database will help me out – so that is what I will use, for a number of reasons. It is quicker for me to produce like this, the performance is very good, and I like trying the new stuff of course. I don’t care that every other application is using another database – because adapting to that standard is boring and more difficult. And of course I don’t care about what kind of resources my application needs – just give me whatever you have. I need it all!
   

3. It worked in Vagrant, in DevStack, on my laptop

   
   I tested it, I ran it and I got it to work. My unit tests passed. My acceptance tests passed. I got green on my dashboard. So obviously it is not something wrong with the application. It is the “other guy”.
   
   I also don’t care how the application is maintained over time, my job was to get it work, so obviously that when you upgrade – you will need to restart services – but hey – they was not part of the original specs and requirements.
   

4. My application works perfectly – and never fails

   
   I invested time in writing this baby, and I made sure that everything is perfect, runs like well oiled engine, purrs like a kitten, a masterpiece. I checked that everything works, and every possible scenario was covered (at least those that I thought of).
   
   And of course the assumptions that I took will always be true (such as – hardware never fails, networks are always available, I have an unlimited amount of resources available to me, all the time)

Next Up we will look at Pillar #2 – Operations Engineers.

I apologize for plagiarizing the holy concept of The Three Pillars, but I do think that a foundation needs to be laid down for a healthy DevOps culture to thrive and even survive. And I would like to share with you some of my thought on this.

To be true to the agile methodology it would only be appropriate that instead of talking about pillars I prefer to talk about personas.

These three personas are:

1. Developers
2. Operations Engineers
3. Management

If I was going to have to lay it out in a graphical form – I guess it would be something like this.

In order for a healthy DevOps culture ALL three of these need to exist – and work in sync.

In the upcoming posts – I will go through each of these pillars and how they should play a part
(but also more importantly – how they should not) in this highly abused and misused term…

DevOps.

Follow the rest of this series here:

Part 1 – The Three Pillars of DevOps Part 2 – Pillar #1 - Developers Part 3 – Pillar #2 - Operations Engineers Part 4 – Pillar #3 - Management Part 5 – Bringing it all together