View All Videos

Archive for the ‘DevOps’ Category

Adam Rosien on how Wealthfront moves fast and agile (Video)


Damon Edwards / 


Adam Rosien from Wealthfront came to the Silicon Valley DevOps Meetup on Tuesday April 5 and gave a great presentation on how they use techniques like Continuous Deployment, Test Driven Development, and their “Immune System” (think automated testing and analysis) to run fast and run agile. Wealthfront’s DevOps lifecycle challenges a lot of conventional assumptions, but the results they achieve in a highly-regulated financial services business (with already over $180M being managed) speak for themselves.

Scroll down for the full video and slides…





Special thanks to the kind folks at for hosting the meetup! 

“Meet the DevOps Experts” panel at Cloud Connect 2011 (video)


Dev2ops / 

I had the pleasure of being the track chair for the DevOps Track at Cloud Connect 2011. It was a short track (3 sessions) but thankfully a great lineup of all-stars accepted my invitation to participate!

Here is the video from the panel featuring all of our DevOps Track speakers. The audio is a bit soft in parts, but I think you’ll find it to be great content. I played the role of moderator and spent most of my time in the audience getting questions from the attendees. 


Andrew Shafer – Cloud Scaling
Teyo Tyree – Puppet Labs
Alex Honor – DTO Solutions / Rundeck Project
James Urquhart – Cisco
Juan Paul Ramirez – Shopzilla
Lloyd Taylor – ngmoco:)


Note: Some of the attendees had video cameras out and may have recorded the other sessions in the track. If I uncover those videos, I’ll post it ASAP.


Video: Lloyd Taylor on diagnosing and transforming your organization

Damon Edwards / 

I find Lloyd Taylor to be creating some of the most interesting and fresh DevOps related content around. He dives right to the heart of cultural issues and provides clear insights and practical strategies we can all use. Lloyd comes from an interesting background that combines senior operations experience at some of the biggest names on the web with his long-standing interest in studying interpersonal and organizational dynamics. If it sounds like I’m a fan, it’s because I am. Each time I listen to Lloyd speak, I learn something new. Hopefully you will as well.

Enjoy Lloyd’s presentation (and the ensuing discussion before my camera battery ran out) from this week’s SVDevOps meetup, it’s well worth an hour of your time:



Books from Lloyd’s recommended reading list (links go to Amazon):

Video Q&A: Aaron Peterson and Kevin Gray on self-healing infrastructure


Damon Edwards / 

At LISA 2010, I caught up with Aaron Peterson (Opscode) and Kevin Gray (Dyn) after they gave a very interesting presentation/demo called “DevOps Gameday“.

From the title, I think a number of attendees were expecting to see the standard Dev to Ops promotion/deployment of code that is so common to the DevOps discussion. Instead the presenters (Opscode, Zenoss, Dyn Inc.) focused on what happens when you have a failure after the code has been deployed. This demo was about self-healing infrastructure… breaking a multi-node system and having it heal itself.

Of course, this kind of canned demo isn’t all that new in the vendor world. However, what is very interesting about their efforts is they want to capture the best practices required to do it and share the code with the world through their combined project (hosted on GitHub). 

If they fulfill the mission of their open project, it’s exactly the kind of “here is how you can do what the big players do” sharing that is good for our industry. 


DevOps is not a technology problem. DevOps is a business problem.


Damon Edwards / 

Update: follow-up post about the competitive business advantage that DevOps enables.


Since Patrick Debois called for the first DevOps Days event and unleashed the term “DevOps” upon the world, there is no denying that DevOps has evolved into a global movement.

Of course, DevOps has its detractors. Negative opinions range from the misguided (“DevOps is a new name for a Sys Admin”) to the dismissive (“DevOps is just some crazy Devs trying to get rid of Ops” or “DevOps is just crazy some Ops trying to act like Devs so they will be better liked”) to the outright offended (whose arguments tend to defy logic).

I’ve spent the past nine months or so overcoming resistance to the DevOps movement in both public forums and inside client companies. During that time, I’ve begun to notice a common misconception that I think is fueling much of the negative initial reaction that some people have to DevOps ideas. I want to take a shot at clearing it up now:

DevOps is not a technology problem.

Technology plays a key part in enabling solutions to DevOps problems. However, DevOps itself is fundamentally a business problem.

What does the business have to do with DevOps?

The most fundamental business process in any company is getting an idea from inception to where it is making you money.

Within that business process there are all kinds of activity that needs to happen, some technology-driven and some human-driven. This is where all of the different functions of IT come into play. Developers, QA, Architecture, Release Engineering, Security, Operations, etc each do their part to fulfill that process.

But if you take away the context of the business process, what have you got? You’ve got a bunch of people and groups doing their own thing. You lose any real incentive to fight inefficiency, duplication of effort, conflicts, and disconnects between those groups. It’s every person for themselves, literally.

But you know what else happens if you remove the context of the business process? Your job eventually goes away. Enabling the business is why we get paychecks and why we get to spend our time doing what we do.

If there is no business to enable or we don’t do any business enabling, this all just turns into a hobby. And by definition, it’s pretty difficult to get paid for a hobby.

The whole point of DevOps is to enable your business to react to market forces as quickly, efficiently, and reliably as possible. Without the business, there is no other reason for us to be talking about DevOps problems, much less spending any time solving them.



Doesn’t this sound a lot like the goals of Agile?

If the goals of DevOps sound similar to the goals of Agile, it’s because they are. But Agile and DevOps are different things. You can be great at Agile Development but still have plenty of DevOps issues. On the flip side of that coin, you could do a great job removing many DevOps issues and not use Agile Development methodologies at all (although that is increasingly unlikely).

I like to describe Agile and DevOps as being related ideas, who share a common Lean ancestry, but work on different planes. While Agile deep dives into improving one major IT function (delivering software), DevOps works on improving the interaction and flow across IT functions (stretching the length of the entire development to operations lifecycle).


But I thought DevOps was all about cool tools?

Technology is the great enabler for making almost any business process more efficient, scalable, and reliable. However, we have to remember that on their own, tools are just tools.

It’s just as likely that you’ll use a new tool to reinforce bad habits and old broken processes as you will to improve your organization. It’s the desired effect on the business process you are supporting that dictates why and how a tool is best used.

When people are clear on what their DevOps problems are and what process improvements need to happen to remedy those DevOps problems, the tool discussion becomes rather straightforward (if not trivial).

Since the nascent DevOps movement is mostly made up of technologists, it’s easy to understand why there is such excitement to jump right into tooling discussions. But perhaps we need to do more to make sure that everyone is up to speed on why the tools are needed and what the desired business process improvements are before diving into our standard “Puppet vs. Chef” or “Files Centric vs. Package Centric” arguments.


If DevOps is about a business process then why is it called “DevOps”?

In my opinion, one fault of the early DevOps conversations is that it wasn’t immediately clear just how big the scope of this problem truly is. Now that we have a year of perspective behind us, it turns out that we have been attacking one of the biggest problems in all of business: How to enable a business to react to market forces as quickly as possible.

But alas, the conversation had to start somewhere so it gravitated to the almost universal problem of conflict and disconnect between Developer culture and Operations culture. Every org chart is different, but it’s fairly easy to cartoonishly divide the world into a Dev camp and Ops camp for the sake of having common reference points to discuss (even though we all know the world is much more complex and grey).

Within that cartoon Dev/Ops example, most of the early DevOps attention has been about improving deployment activity. Since change activity makes up the bulk of the work across an IT organization, that too was a logical and natural place to start.

Maybe Patrick should have called that first event “BizDevQASecurityOpsCloudUsers Days” or “SolvingABroaderProblemThanAgile Days”… But I doubt anyone would have shown up.

Anthony Shortland on strategies for solving DevOps problems (Video)


Dev2ops / 

Last night, Adrian Cole (of jclouds fame) organized a Java-oriented DevOps Meetup here in San Francisco. 

There were a number of freeform lightening talks used as an excellent device to get the conversation started. Below is an interesting talk from DTO’s Anthony Shortand. Anthony gave an excellent conceptual introduction to two strategies for solving DevOps problems, “Full Lifecycle Traceability” and “Establishing a Formal Separation of Concerns”.





Page 8 of 14First678910Last