DevOps is Not Just a Tool

I was forwarded an interesting article last week and it really made me think.  The article in question is  written by John Allspaw and entitled "An Open Letter To Monitoring/Metrics/Alerting Companies".  The main point John makes is regardless how advanced and powerful a piece of software is, there will always be a need for a user on the other side of the screen making sense of the data.  Software at its core is just a product.  I agree with John that it is disingenuous for a company to pitch their product as "the end all be all solution for better troubleshooting".  There are other components in making a true DevOps practice a reality.

I am a huge fan of the CNBC show The Profit.  If you have never watched it before; the host, Markus Lemonis travels around and invests his personal capital in struggling businesses.  He dedicates his time and effort into getting businesses on an exponential growth path.  Markus always refers to a simple formula for success.  The formula consists of the three P's; Product, Process, and People.  A true DevOps environment will also include the three P's.

Product

                           Is it all there?

The tools of an organization working on DevOps practices must have the ability to facilitate cross team conversations.  This means that the tool (or tools) implemented must present data in multiple ways that can be interpreted by different teams.  So logically, the tool must be able to do one thing above all else, collect data.  Analyzing incomplete pictures will always lead to incomplete results.  Be weary of solutions that will always "filter out noise".  The hardest problems to solve always seem to be in the "noise" of the environment.

Process

                         It's ok to look down

Why does your company do things the way it does?  Why do you have those status calls?  Why do you have an internal forum?  If you cannot answer these questions, I do not want to talk to you.  You should have a clear understanding of the process of your organization and they "why" behind that process.  In simpler terms, process is meant for the sake of progress.  In a DevOps world the process should facilitate communication between all the groups involved in the SDLC.  I have seen some of the best organizations put Ops members on the weekly Dev touch bases and vice versa.  Production problems suck.  They are stressful, a huge drain on the business and a black eye on the brand.  If an organization takes the steps required to allow honest discussions regularly you will see a noticeable drop in P1 production issues.

People

                                    No computer will replace you

The center of the DevOps movement is the people.  Bottom line.  To build the best applications, you need the best people.  I have worked with some amazing engineers, and some not so amazing engineers.  I have sadly had to walk away from potential deals because I know the group that would be responsible for understanding the data was not capable of doing so.  The reason why I walk away from those situations is the same reason a chainsaw company will not sell its product to a 10 year old.  The child is not ready and will likely hurt itself as opposed to providing any value.

Final Rant

I hate the fact that organizations look down on services when evaluating potential purchases.  Requiring services does not mean the product is hard to understand, more so your organization requires some assistance in perfecting your individual products, process, and people.  You cannot honestly think your team will instantly become better just by installing something in your environment.  Just like learning anything new, it will require changes in all three fronts to truly become a DevOps shop.