After Velocity came DevOpsDays in Mountain View. I was hoping to give my feet and liver a rest after two consecutive days at Velocity. When I woke up at 7:30 a.m. the next day my body was throwing lots of OutOfEnergyExceptions, and it did cross my mind whether another 2 day event on Dev and Ops might be overkill. I got out of bed, hopped on a Caltrain, and made it to the DevOpsDay just in time for John’s “State of Union” speech.
John gave a great intro into how the DevOps movement started and its progress since inception back in 2009. Within just two years, Gartner is now recognizing the movement and its relevance within IT. John then talked about agile companies like FlickR who were doing a wacky 10 deployments a day back in 2009—and more recently WealthFront, who are now up to 50-100 deployments a day. It’s becoming clear Agile Development is driving the need for Agile Infrastructure and Operations. However, whilst the Cloud concept helps organizations become more agile, the idea that Ops will simply go away or be taken over by Dev is just nonsense (John put it a bit more bluntly than that, which was well received). The Business and Dev still need Ops, no matter what.
Sessions throughout the day varied from Packaging to Orchestration right the way through to Monitoring and even QA. Open panels and mics on the floor made each session very interactive with several people speaking their mind and calling out any BS they heard. It was quite refreshing to see so much passion and energy in the room, especially after two long days at Velocity.
The metric and monitoring session gave plenty insight into the problems Dev and Ops face every day with application and systems monitoring. With so many metrics available to IT, which ones really matter? Lots of talk around graphs and dashboards and how they should be shoved in Dev’s faces so they can share the pain with Ops when it happens. “Ops have plasma TVs everywhere with what’s going on. You should start nailing up Plasma TVs in Dev rooms so THEY see what’s going on.” I thought this was a novel idea, although I can see it quickly being abused with multiplayer XBOX death matches. You can imagine Ops walking down to Dev during an outage with their plasmas, blasting gunfire and grenades instead of red flashing application alerts!
Stephan Apitz also gave a great presentation on his experiences running production support at LinkedIn. Specifically, he discussed how MTTR was bad and slow previously due to constant log file trawling. The development team at LinkedIn simply “didn’t know what production looked like” or “how their code ran in production.” The adoption of new tools and in-house monitoring has helped them open up the black box and manage performance between Dev and Ops. Dev are now actively encouraged to instrument their code in production.
Whilst many of the discussions were positive, I couldn’t help but notice the lack of references to the “business.” Everything seemed to be about infrastructure, processes, and IT metrics. That is, until a brave woman stood up and said “It’s nice to hear about IT metrics and zooming in on trees, but what about the F*#@ing business? That’s the forest surrounding all these trees!” I couldn’t have put it better myself. What role does the business play within DevOps? How do you measure the success of DevOps? For me, it’s about reporting what impact DevOps has on the business as they become more agile and deliver more change. Does business activity improve or does it decrease? More importantly, how can DevOps evangelize their success to the business in a language they understand as they become more agile?
From the two days I spent at DevOps, it’s clear there is a lot of work ahead to transform the culture, automation, measurement, and knowledge sharing within IT and the business. Agility is what everyone wants—and therefore, it’s ironic that change is the only thing that can make everyone agile.