DevOps Days – Silicon Valley 2013

I let the whole journaling thing go for a while, so I think I should fill a few key things back in.

Most of my work of late has centered around the DevOps movement and related technologies. In many ways, it’s providing terms and frameworks for stuff that I have long know was “the right way” to do things.

A big turning point in understanding was when I attended the local DevOps days conference back in September.

I work as a professional services consultant, and we tend to share knowledge a lot. After the conference, I wrote several emails back to my team explaining the conference. (There were aimed at an audience included both tech and non-tech folks.)

It gives a neat mental snapshot of me walking in on this whole movement:

Email #1

This last Friday and Saturday, a few of us (Russell, Andre, Joe and myself) attended a short conference at the Santa Clara Convention Center called “DevOps” days.

For those of you familiar with how the DevOps movement got started, this is the grass-roots meetup and convention path that has been generated by the community at large. There is more info over here: as well as a history of the movement here:

The focus of the convention was the evangelization of DevOps and discussion of tools and techniques. You can mentally think of DevOps as an equivalent framework to “Agile” but for the operations side of the house, as opposed to development. Its focus is on Continuous Integration and high levels of operational automation.

All the main room presentations were streamed. I’m keeping an eye out for when they and the ignite talks are posted on line. Some of them are very interesting and applicable. I will be sharing those as I find them.

Some old and new friends were present with booths and staffed with a lot of the engineers developing the product. The usual knuckleheads like VMware, Citrix ITSM academy, BMC, HP and CA were there.

There were also new technologies present that were interesting to check in with and might be useful to partner with or suggest if the discussion comes up.

Pagerduty – Monitoring and paging as a service. API to tie into your system. “We wake you up when sh*&$ breaks.” is their motto. These guys seem to be heavily used by many people present.

Datadog – statistics and monitoring as a service. Their goal is to create really good visualizations and support visual metrics for a wide variety of technologies. Conceptually you could smash together VCOPS and Splunk and this is what Datadog is. These guys might be good for a presentation locally in our office, as the “dashboard and metrics” need comes up occasionally in discussion.

mongodb – Had some good staff presence. Picked up some books and chatted shop with these guys. Got some pointers for direction on RMS.

There are several products trying to ease into either the IDE, host or framework for continuous integration. I’ve gotten info on all these and will spend my spare (hahahah!) time looking up where any of these might fall or help us. The top of the stack guys seem to be: Stakato, UC4, Zero turnaround.

There are also a few products trying to squeeze into the network side of things: boundry, etc. These guys all seem to be focused on EC2 monitoring, but everyone when I asked about VMware had the “we’re working on it” answer at hand.

A GREAT opportunity was both of the companies behind chef (opscode) and puppet (puppetlabs) were present. And I was able to corner and ask them to differentiate their product from the other in strength and weaknesses. It confirmed a lot of my own assumptions and experiences, but it’s useful to have the knowledge out there.

The really short version: Both chef and puppet do package management using Ruby as a core language. Puppet has a simpler config setup to where your end ops guys don’t HAVE to know Ruby to get basic work done. Chef lets you get into customizing earlier and easier. Both do some change tracking, and logical inheritance of package structure. By default puppet will do it’s best to get as much done on a configuration run as possible. For chef, you need to make sure you write your recipes that way. Both projects are heavily used: puppet runs google. chef runs facebook. So it really comes down to what is pre-configured in one or the other for your needs, and if you have strong Ruby programming knowledge on staff.

Just to confuse things, there is yet another player in this argument: salt. Yet more to read up on.

In discussion and presentations it was confirmed to me I need to look more into:

crowbar / razor – this is bare-metal-up-to-app extensions onto chef and puppet. Also, a simple version called PXE-dust.

gauntlet – automatic security add-ons to a jenkins-style build process.

I think that’s a starting mental dump for now.

I’ve joined up several meetup groups and will let folks know as events happen. I was also invited to give an ignite talk in the future. I’ll let you know where that goes.

– Phil

Email #2

Video of all the main talks and the ignites are online now.

Some of my favorites were:

– The keynote: “Devops+Agile = Business Transformation – Jesse Robins: –

– The two analytics talks:
– Beer Pineapples and Bottlenecks – Adrian Cockcroft (ignite) –
– Beyond Pretty Charts … Analytics for the rest of us – Toufic Boubez –

– Gauntlt – Before you trust your code make it run the Gauntlt – James Wickett (ignite) –

– General talks
– DevOps Do’s and Dont’s – Dave Mangot (ignite) –
– 8 mistakes that prevent DevOps success – Jonathan Thorpe (ignite) –
– From Monitoring With Love – Peco Karayanev (ignite) –

– And maybe an odd/fun one:
– The Positive Powers of Negative Thinking – David Hatten (ignite) –

The “ignites” are 5 minutes long. The others go 30-45 mins.

– Phil

Email #3

This is the last one, I swear 🙂 But this is really awesome data.

This presentation was glossed over in an ignite talk, but the slides are now up for perusal. It is a survey of various organizations, and data on how many of them are trying to implement what projects and what tools.

Naturally, there will be self-selection bias in the audience. But the data is still quite useful:

– Part II (slides 11-15) – A comparison, with numbers, how how a “DevOps” (continuous integration) organization crashes less often and recovers faster.

– Slide #18 – Numbers on cloud adoption and types of languages and OSes in the field.
– Slide #19 – Stats on Puppet vs Chef vs other configuration management, also numbers on adoption of “infrastructure as code.”*
– Slide #20 – Stats on automated testing
– Slide #21 – Stats on monitoring

– Slide #26 and related data – statistical breakdown of the release speed improvement of CI.

The whole presentation is worth reading, but these numbers are great for reenforcing what we know is a best practice. Good hard stats.

– Phil

“infrastructure as code” – is a euphemism for tracking configuration management and server building in line with product development.

Saving this here for my own history and for later discussion.

Leave a Response