Freedom of choice – Three Ways DevOps is Revolutionizing Enterprise Software

“I’m free to do what I want, any old time”

– “I’m Free” – Rolling Stones

Here comes the Revolution

Anyone reading the tech news today these days can see that something profound is happening with enterprise software. Venture capital money is flowing into enterprise startups (including Sumo Logic). Old stalwarts like Dell and BMC are likely to be taken private in order to rework their business models. The stock of other software titans are being punished for clinging to old, proprietary models. Most of the old school crowd are trying to improve their image by buying younger, more attractive companies – like IBM with Urbancode. So, exactly what is happening?

Some of it is clearly not new. The big fish in the enterprise pond are always gobbling up Looking upthe small innovators, hopefully improving the lot of the larger company. Why then are some calling this the Golden Age of Enterprise Software? Many will point to BYOD, Cloud, Big Data, DevOps, etc. Personally, I think there is a more subtle trend here. More than ever before, software developers have tools at their fingertips that allow them to deliver software quickly and efficiently, and conversely they are also being held more responsible for the performance of that application.

In the best case scenarios, this has led to highly disruptive and innovative practices that shatter the enterprise software model (take Etsy and NetFlix as two prominent examples). Instead of an operations team passively receiving poorly tested code from unengaged developers, you get highly automated, constantly adapting architectures deftly driven forward by highly-skilled, and highly-motivated DevOps teams. I am not saying something new here. What I personally find interesting here is the disruptive effect this is having on enterprise software, in general. Here are three general trends I see:

 

1. The Rebirth of Automation

This is the DevOps trend that most point to, which is dominated by Puppet Labs and OpsCode (Chef). It seems 90%+ of DevOps discussions start here. The deft combination of flexibility, expandability, and community appeal to the development mindset already conditioned by the open source movement. The idea of “Infrastructure as Code” is a natural extension of first virtualization, then cloud computing. It is so easy to create new “servers” now, that there is no excuse not to completely automated the build and maintenance of those servers.

2. The “Re-discovery” of the Customer

The proven theories of lean manufacturing have long stalked IT in the form of concepts like lean software software development and six-sigma. And some of the DevOps community is trying hard to bring these concepts to IT Operations. Underlying this is the trend towards the importance of consumer and user satisfaction. The switching costs are so low, and the modes of feedback so verbose, that companies can no longer afford to ignore their users. This means that the lessons learned by the automotive industry – eliminate everything that doesn’t provide value to the customer – are now essential for the IT industry. This is not good news for legacy software companies associated with the image of uncaring, passive IT departments. It is also fueling the rise of cost-effective solutions like SaaS (are million dollar software solutions gathering dust providing customer value?).

3. Measure Everything

Example Etsy GraphAs the DevOps movement takes on more of Lean thinking, then the importance of measurement rises. In the seminal book on DevOps – “The Phoenix Project” – monitoring is a central theme. We see this in the real world with Etsy’s efforts. They are monitoring thousand of metrics with statsd, providing insight into every part of their application. So, what’s different here? In the old world, what you monitor is dictated to you by software vendors who deliver generic metrics to fit all customers. In the new world order, developers can add metrics directly into their logs, or through a tool like statsd, and monitor exactly what they want to. In the spirit of open-source, it is more important to get what you need (custom, relevant metrics), rather than get it in a pretty package. In essence, this means that the old Application Performance Monitoring (APM) tools may be headed for a rude awakening. Why do you even need an APM tool, if you can pump custom metrics to a generic graphing tool, or a log analysis tool? Well, I am not sure that you do…

These points are only one small part of what is changing, and I don’t claim to know exactly what the future bodes for IT software vendors. What is obvious, though, is that the barriers to entry for innovation are low, and the money willing to chase it is plentiful, so this is definitely a golden age – just not for the old school, perhaps…

* Picture of statsd graph from Etsy’s blog – Code as Craft

Advertisements

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 http://illustration.worth1000.com/entries/95497/bunny-under-a-low-bar

Reposted from BMC Communities