So we just finished up DevOps days here in Austin, TX and it was a great success from all accounts. This being my first DevOps days, I wasn’t sure what to expect. If this is the first time you’ve heard of DevOps, let me warn you of one thing: If you think you can search the web for a definition of DevOps, you will be sorely disappointed. The first rule of DevOps: you do not talk about DevOps. I know, bad joke. But seriously, you will not find one definition that can outline just what DevOps is and that is just fine with the core DevOps folks. In their opinion, this allows DevOps to grow and adapt to change. This is a very hard thing for people to understand who are new to this movement.
John Willis (aka old SOB),VP enStratus, provided the closest definition for DevOps he could find:
DevOps is a cultural and professional movement.
John went on to say that DevOps is a human problem, though some would like to say it’s actually a management problem (and I would tend to agree with them). Tools like Zenoss, WebEx and Google Docs can help facilitate DevOps, but in the end it’s the people using them that matter.
Too many times, Development and Operation managers are singularly focused on the numbers. Either the number of features completed or the total system uptime. These are good metrics to gauge team performance on but are only a result of other team factors.
While walking around the conference, I overheard one conference member talking about a large software company that was about to release a huge product update. This update had the potential to drive the company to the next level with a single deployment. When the Operation and Development teams met to overview the deployment, a huge problem was found with scalability. If they moved forward with the deployment, the expected traffic from the popularity of the update would crash the system. Thusly, they would risk losing investor funding. On the other hand the development team had a target delivery date to meet that was expected by both investors and customers and would be seen as a major failure if delayed.
This company decided to move forward with the update, discounting the Operation team’s warning. As predicted, the update was hugely popular and the entire development team attended the launch party to celebrate the company’s success. And like clockwork, the site crashed as expected; the entire Operations team was busy working to recover the system and could not attend the celebration.
To add insult to injury, at the end of year reviews, the development team received bonuses for meeting all deadlines and the operations team was penalized for not meeting uptime requirements.
This was a epic failure of the management team and more than likely drove all the key Operations people from the organization. Not to mention the fact that now the development team was not expected to deliver quality but only meet timelines. The bar was lowered for both teams in one single deployment.
DevOps is not about Operations and it’s not about Development. Rather, it’s about bringing these two teams together as one to help the business succeed at its goals. It’s the culture management creates and supports that will help the teams succeed. The tools will help get things done, but without the correct culture in place the tools are impotent. I am by no means defining DevOps, but merely suggesting that this is a crucial aspect of space that should be embodied and understood. Any if all else fails, you can always turn to Borat.
