Pillar #3 - Management

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.

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
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.


NSX 6.2 is Available for Download!! (Evaluation)

Since this has been totally unavailable up until now (except for a select few), it is great to see that it now available for public download

As has been said a number of times before (here and here), it was not possible to get hold of NSX unless you had specifically been given access.

There were a number of reasons for this – some I agree with, some I do not.

But it seems that as of the 6.2 release it is now possible to actually download NSX and try it out for 60 days.

Here’s how I went about it.

First I tried the VMware site


But that led me to more or less a dead end. It took me to the same HOL environment where you could try it out.


So how do you get access to the bits?

I came across this when ‘cruising’ through the My VMware portal.

**Full disclosure here – I have not purchased NSX, I have note engaged with PSO, I work for Cisco who is probably seen as NSX’s biggest and worst ‘enemy’. I do have access to (AFAIK) Enterprise plus and some vCloud suite license in the portal – as a result of previous purchases and management of a decent sized VMware environment. This is not part of a vExpert freebie. **

In the portal I searched for NSX



And lo-and behold – instead of the usual greyed out download box, I got this.


Documentation can be found here.

And just to confirm – NSX can operate in evaluation mode for 60 days (from the documentation)


Personally – I see this as a welcome change by VMware – allowing access to the product to try it out before having to dish out $$$ to look at the product and the capabilities.

So thank you VMware.

And if this actually does stay this way – it remains to see how VIAdmins will react to the product and see how suitable it is (or is not) for their environment.

Again – your mileage may vary – depending on your portal access.