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

3 Reasons why DevOps isn’t changing IT faster

iStock_RobotRaceThe recent article from Luke Kanies (from Puppet Labs) on Wired.com really got me thinking. Similar to Luke, I have had an interesting vantage point to observe the changing nature of systems administration – spending time as one myself – over the last decade or so. From my graduate physics department, to Loudcloud, EDS, BladeLogic, BMC, and now Sumo Logic, I have seen the best and not-so-great IT shops and how they operate. Not all of those IT teams I saw in action were, or are now, adopting best practices like automation and DevOps. The trend that Luke points out means that operations teams that continue to languish in constant firefighting mode, relying on ad-hoc scripts and the sweat off the admin’s brow, are becoming more obvious for being clearly out of step with the direction of the industry.

So, why aren’t all operations teams, and the techies themselves, falling over each other to embrace tools like Puppet, SumoLogic, and other DevOps/Automation tools? Clearly some organizations are embracing them. Why not all of them? I have few of my own ideas here, and I would like to hear yours as well.

1. The move from “Artist” to “Manager” is not natural

Back when I started in IT, most IT admins “owned” a small collection of devices or applications. Server admins owned a handful of servers, database admins a few databases, network admins a few switches and firewalls, etc. They controlled access to their systems jealously, and took personal pride in their operation. They were artists, and their systems, and the way those systems were managed, were an art form. As IT budgets have shrunk, and the load on IT increased, this level of care is impossible.

Yet, you still find many admins jealously guarding their root access privileges, instead of moving to a shared responsibility model with other admins. Why? I think it is the same reason why I feel such satisfaction after cooking a meal, building new shelves in my garage, or fixing a leaky faucet. I did it myself, and it feels good to start and finish something. Participating in automated processes can be deeply unsatisfying. That is why admins need to learn new skills, and find new pride in the quality of their automation or find satisfaction in steadily improving quality.

2. Using Automation may seem like losing control

One conversation from my IT past sticks in my mind more than any other. I was on site with a customer trying to explain the benefits of automation to a group of systems administrators. One system admin floored me by insisting that she could more accurately, and more quickly, make changes to 20 UNIX servers than I could ever do with automation. It was like some modern version of John Henry calling me out to some man vs. machine contest, and subtly decrying the inhumanity of my automation tool. I can’t even remember my answer now, but this perspective is at the root of much of the push-back against automation and DevOps. Instead of looking at the business outcome – better experience and value for the customer – some frustrated system admins see these new ideas as a direct affront to the quality of their work. This is precisely why I think the fundamental shift in DevOps is from a internal IT focus to an external customer focus. That way admins can measure their success by customer impact. Not an easy change to make, but it is essential for IT’s continued relevance.

3. Change seems hard/bad/unnatural/unneeded

Isn’t the root of the resistance here really the natural tendency to resist change? On the other hand, how many times have operations teams been assured that the latest IT fad will reduce their workload and improve quality, only to see the opposite happen? So what’s different about DevOps? I think I could write a whole blog entry just on that, but a few things come to mind. First, the focus is on customer value, which greatly simplifies priorities. Second, it’s all about outcomes, not process for the sake of process. Finally, it is all about continuous improvement driven by the experience of the people on the frontline. This means that admins must be rewarded going forward for doing things that increase customer value, rather than putting out fires or pleasing angry executives.

So, it all comes back to culture – surprise, surprise. I think this will be the primary challenge of DevOps going forward. How do we overcome the IT culture so resistant to change, while providing an attractive way for all of those systems administrators to breathe easily in their new roles?