Is the DevOps community setting the bar too low for automation tools?

I have been in the automation, particularly configuration and application automation, business for a while now. It is very good to see how the current trend of DevOps is pushing IT departments to really and truly embrace automation – and not just for the server. All that said, I am feeling a little like the mainframe guys do about cloud when I see blog posts like this. UrbanCode is now boasting of the fact that configuration-only deployments are the best thing since the first shell script emerged from the primordial ooze of UNIX. Really?! Configuration management systems should boast about being able to figure out on the fly what needs to deployed, and then deploying only that – not forcing their users to figure that out for them and calling that a feature.Have we really taken a step back in the configuration automation industry to a point where boasting about functions that should have been in your product years ago substitutes for substantive contributions? And if this is the new normal, is it working? This kind of relabeling and repacking of old ideas is not new to configuration automation software. Oh wait, now my scripts are “compiled scripts”. Or – My scripts are failing, so I moved from scripts to METAscripts written in a METAscripting language that only a METAcommunity knows :). And now I am rockin’ 25 service environments (who cares that the “last generation” tools can are known to manage 1,000+ service environments). Bottom line, can the current batch of self-styled DevOps automation tools really hang tight in the concrete jungle of enterprise IT operations?

Don’t get me wrong. It is this very willingness to thumb one’s nose at your predecessors, upon whose shoulders you currently stand, that is at the core of innovation. As Picasso said “Good Artists Copy, Great Artists Steal”. So, do we look to the purveyors of software for the solution to the problem?

The simple answer is, No. The reason why a lot of this happens, in my opinion, is because each new group in IT that finds itself tackling a new problem rarely looks backwards, or even in the next cubicle over, for solutions that have already worked. And with DevOps in particular, they are some questions that the Users (IT departments) should be asking the vendors, and themselves. Not every IT department out there will need or want the same solution, but they owe it to themselves to be thorough. So, what does an IT department do to make the right decision.

1) You have to weigh the short term needs of the immediate problem (say small-scale DevOps) against the longer term rollout (DevOps in full production). Many poor IT decisions are made on the basis of “cool feature”-itis, rather the mundane process of choosing what makes the best sense for the business.

2) Use business metrics. Every IT purchasing decision should be made on the basis of sound business metrics (We will save X% in costs, increase revenue by Y%, etc.). That means you need to invite those MBA graduates from the other office over to the team. I know – you don’t want them to bean count you into oblivion. Just realize that they speak the right language to get the project funded. And make them pay for lunch.

3) Hold the vendors (including us) accountable for the statements that we make. We should deliver references and case studies to back up our case. And, if those metrics stand up, you can use them for your business case.

Bottom, set the bar HIGHER DevOps community. You owe to yourselves, and your business, to expect more out of your vendors.

* Image from

Reposted from BMC Communities


3 thoughts on “Is the DevOps community setting the bar too low for automation tools?

  1. Ben, the customer who gave me this scenario was not referring to a situation where configuration changes could be auto-inferred and applied. This wasn’t detecting a lack of database connection threads and increasing that count.

    They were deploying updates to a financial app. This scenario is much closer to updating business rules independent of updating the application that executes the business rules. These configuration changes had to go through testing routines and (given the impact to the bottom line) approvals before release.

    “Configuration” is an extremely broad topic. I probably could have been more clear as to exactly what configuration I was talking about.

    As for lowering the bar, I think tend to think of “the bar” as two things simultaneously. The first is

  2. Bah! cut myself off.

    The first is lowering quality. The second is lowering the barrier to entry.

    I think we really do need to make it as easy as possible for traditional IT shops to get more DevOpsy and not hold out for purity. Get them in on easier to swallow steps that are on the path to spectacular awesomeness. In Agile terms, Scrum is ok even if we like XP better.

    • Great comment, Eric. I appreciate the feedback.

      I think you make a very valid point by differentiating quality from lowering the bar to entry. On the second point, I think we probably agree. I definitely want more people to automate. It is the eventual fallback to manual methods and scripts that is always so disappointing to me. Maybe this is the balancing act that we, the automation advocates, have to perform. Making automation straight forward enough to be adopted vs. enabling some sort of automation sprawl where automated processes are chaotically applied and mostly uncoordinated. The latter, In my mind, is like handing a nail gun to a person with a hammer and nails only to see them nail their foot to the floor.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s