Ben Rockwood Interview

One of the benefits of being the "Blog Team Lead" is that I get to pick who I want to interview. The first person I selected was Ben Rockwood, long time blogger at Cuddletech and DevOps guru / practitioner. I've admired his writing for a long time, and I jumped at the chance to speak with him about his keynote address and DevOps in general.

 


 

Matt Simmons: Lots of people have disagreed on the meaning of the term "DevOps". So that we're all on the same page, how do you define it, and what do you think differentiates a shop from operating according to DevOp principles from one that doesn't?

Ben Rockwood: DevOps is a cultural movement. It is a philosophy with its roots in Agile and LEAN. Its most prominently identifiable feature is that of collaboration and continuous improvement.

A DevOps shop is one which fosters an environment of collaboration. In most environments today, developers are engineering software which operations then engineers into a service to address customer needs.

Whats important is the services we, as a business, provide to our customers (whether they are internal or external). DevOps shops allow cross pollination of ideas, methods, and tools, between these two. The intended result is a service that is easier to develop, deploy, operate, observe, and improve; not to mention more capable than either team could achieve separately.

For some people, "DevOps" is just another way of saying "Configuration Management". Infrastructure as Code is a core belief of DevOps because, among other things, it bridges the gap between different teams. Just using Chef or Puppet doesn't make you a DevOps shop, seeing these tools as a means for collaboration (for instance, enabling Dev or QA to use something like Vagrant to replicate the production environment on their laptops) does.


MS:The talk abstract mentions the three transformational phases of DevOps. What are those?
BR: DevOps can be a difficult thing to discuss with others because we're all on our own journeys. In my experience that journey can be divided into 3 phases. They are:

 

  1. dev>Ops: Dev into Ops.
  2. The journey typically starts in Operations, where its clear that the old methods aren't scaling to new technologies, such as cloud. Developers with access to IaaS cloud offerings can now bypass operations completely in many instances, which means modernization of tools and practices needs to be untaken. If that is the case, operations will start by looking at what developers need and try to learn how to address those concerns in a more integrated workflow.

    In general, we're talking about a comprehensive re-evaluation of the status quo within operations. This is where a new generation of tools are being embraced, such as Configuration Management (CFengine, Puppet, Chef, etc) to enable infrastructure as code, converged logging systems (Greylog2, Logstash, Splunk, etc), distributed command & control or orchestration (RunDeck, mcollective, etc), converged metrics collection and graphing (Graphite, OpenTSDB, Reconnoiter, etc) and on and on.

  3. Dev<Ops: Ops into Dev.
  4. Once the stage is set, Development can begin learning from operations by taking advantage of the new metrics frameworks, monitoring/alerting frameworks, logging, etc. In this phase development starts to gel with ops. This is where continuous integration testing, development environments which are built from the same source as the production environments, etc, all come into play.

  5. Dev<>Ops: Ops & Dev at Tenagra.
  6. This is the utopian stage of continuous improvement. Once both teams (and those in between) are working on the same page, we want to keep up that momentum and strive to get better all the time.

This model is perhaps overly simplified, but it provides a framework by which to tease the various parts of the transformation apart to better address them.

 


 

MS: What kinds of benefits are there in doing things according to DevOp principles for a company in which someone may get pushback when trying to implement new techniques?
BR: Collectively, IT is typically seen by executives as both the most strategically important part of a company and at the same time the most difficult to control. If you don't believe me, pick up CIO Magazine or Harvard Business Review. DevOps is a grassroots cultural movement, all the tools advocated are Open Source, and the goal is collaboration which improves the individuals pride of workmanship and the end customers quality of service. Furthermore, DevOps embraces LEAN principles which most C Level Executives are already preaching or trying to adopt.

DevOps is about collaboration, about visibility, about increasing the rate of improvement. The only reason you should get pushback is if you either work in a "don't fix what ain't broken" environment which is allergic to continuous improvement, or because your interested in implementing tools for yourself without sharing that benefit with others.

Metrics are key here, because all the business rags are abuzz about visibility. Down in the trenches we have all that data floating around us all the time, if we can organize it and present is properly - which tools like Graphite make it easy to do - we can win friends throughout the business quickly.

 


MS: You work at Joyent, a cloud services provider - have they always done things the "DevOp" way, or was there a conversion process?
BR: I think any reasonable shop would say that these DevOps principles aren't new and that "we've always done this". Lets be truthful in agreeing that "DevOps" is something of a fad.... but an incredibly useful one.

With all the buzz about DevOps it has sparked a conversation that makes improvement easier and also made the flow of code from ops back into dev much easier. Whereas previously some people would be a little confused by collaboration ("That's not an ops thing.") now its welcomed and even solicited. Everyone is driven even more to find new ways to collaborate.


MS: The LISA'11 slogan is "The Past, Present, and Future of System Administration" - Is DevOps the future? Are we all going to end up doing DevOps?
BR: DevOps is the future. "Better, faster, cheaper" doesn't go out of style, and collaboration certainly doesn't. But there is a lot in the past that's brought us to this point and will continue to shape our future. DevOps is really known today for its shiny tools, but now thats giving way to the changes in governance they facilitate, so "old" things like ITIL, CobiT, and LEAN (which comes from the Toyota Production System, which came from the teachings of Deming and the Ford Production System, which are based on Shewhart and Taylor) are now converging around us.

Systems Administration is changing, a change that we've seen coming for a long time now. "One day we'll all manage hundreds of nodes!", "One day we'll manage petabytes of storage!", "One day you won't even buy servers! You'll just create them out of thin air!"... all that has come true. Welcome to the future! But the methods we've used to manage our environments really haven't changed much in 10+ years. We have to mature and adapt as engineers and that transformation is occurring under the name "DevOps".


MS: What kinds of resources could you point system administrators to in order to learn more about DevOps, and how they can implement it in their own companies?
BR: There is a lot of information out there, enough to make your brain bleed. Start by looking at the proceedings of the Velocity Conference (all the sessions can be viewed on Safari), check out the various DevOps Days events occurring around the world, and listen through the archive of DevOps Cafe podcasts. There is a huge amount of energy on Twitter
so start following people like @patrickdebois, @botchagalupe@damonedwards, @allspaw, @RealGeneKim, @jordansissel, @portertech@lusis and a whole world of DevOps excitement will unfold before you as
well as various blogs, tools, and books.

    For companies that want a fa$t track to what its all about, companies like DTO Solutions (http://www.dtosolutions.com/) can do a top to bottom evaluation and guide you on your way.
     

    [Editor's note: You can find Ben Rockwood himself on twitter: @benr]

     


     

    I want to express my thanks to Ben Rockwood for his time and consideration. You can attend his Keynote Address The DevOps Transformation on Wednesday, December 7th at LISA'11 in Boston.