Cloud Native / Sponsored

Uber, Netflix and the Dreams of DevOps and Microservices

14 Apr 2015 8:36am, by

In a recent conference poll, ​Gartner’s Tom Bittman asked, “What is going wrong with your private cloud?”​ He was surprised by the response. Only 5 percent of 140 attendees who said they had a private cloud in place claimed nothing was going wrong. The other 95 percent had issues of some kind. There were many reasons for being unhappy, some being they’d set the wrong expectations, focused on the wrong benefits, or had not gone far enough to change the operational model. The point is not that private cloud projects are full of failure, but that they require much more than simply standing the cloud up to be successful.

95 Percent of Survey Respondents Wanted More Awesome

I think of this as the “blinking cursor” problem. You know that softly pulsing cursor: it’s the result of millions ­—if not billions! — of dollars spent on cloud projects. These “private cloud” projects see companies redoing how their IT department provides infrastructure. They move from physical to virtual management; move from manual ticket processing to self­-service, automated provisioning; and after efforts that must have seemed like building all of the furniture for a new IKEA store with just a pocket knife, they might end up with their own cloud. And then, after all of this, they’ve gotten the blinking cursor up! The servers are ready to use! Now the hard work of designing, developing, deploying, and managing the applications that run the business starts. There is little wonder that 95 percent of folks in that poll were not completely satisfied with their private cloud projects.

As the conversation in the DevOps community has been explaining in recent years, the issue of “culture” also causes problems. When I was studying the spread of “mainstream” DevOps as an analyst, our surveys showed that humans became the ultimate blockers of progress in cloud projects. Technology was rarely cited as a “problem,” and in contrast, people blocking progress, not changing processes enough, and otherwise resisting rather than facilitating change, were the issues. Throw all those people into a collective “them” and you’ve got bureaucratic and “political” problems to rival the dead-locked governments. These “cultural” issues become the ultimate blockers. They have to be solved if you want to make progress in becoming a software-defined business. But mixed in well with using the proper technology you get astounding business results.

When we look at the now cliché examples of industry disrupting companies — Uber, Airbnb, and Netflix — we see companies focusing on building custom software to establish competitive advantage in their marketplaces. Most of the companies we’re agog at today in that list are not so much “technology” companies, but companies expertly using software to create their unique offering and competitive positioning. The results (of the winners, at least) often drive astoundingly fast growth, as Uber’s rumored revenue shows: from $108 million in 2013 to a planned $2 billion in 2015.

Churning Your Own Butter: Delightful!

Even with all the products and open source tools available, deploying and maintaining applications on clouds turns out to be a difficult proposition. These much admired companies, most of whom started around five or more years ago, were forced to build their own cloud platforms on­ top of raw infrastructure. Each of them needed the orchestration and management layers between cloud infrastructure and the applications they were building. Designing your applications to run cloud style — following what we now call a ​“microservices” architecture​ — requires all sorts of changes in how you not only write your application, but also how you manage everything in production. You’ll often hear about “day two” problems: after you’ve deployed all your new application on day one, when you wake up on day two, there might be hundreds or even thousands of separate services to deploy and manage. Traditional manual approaches quickly become untenable without sophisticated automation.

Netflix, one of the more admired companies in this regard, was forced to write their own platform. Thankfully, Netflix has been extremely open about their learnings and even open sourced many of the components and tools. This means not only that Netflix can recruit help in evolving their platform, but also that the rest of us can benefit from it (at Pivotal, we’re making a lot of the NetflixOSS, conveniently accessible through ​Spring Cloud​). Netflix has made the code for the ​Simian Army​ and circuit breakers available, and spoken publicly about building anti­fragile systems. What Netflix hasn’t done is open their full platform. There is still plenty of heavy lifting between what is available on GitHub and a fully-automated, self-healing microservice deployment.

Beyond the Blinking Cursor

At the intersection of these bespoke platform builders and those suffering from a bad case of the blinking cursor, we find a hopeful hero: DevOps. Combining automation tools and aspects of Agile development to operations, the DevOps community has been fiendishly exploring, defining, and filling out all the plumbing needed by those private cloud builders who are now wondering when all those awesome effects of cloud they heard about in “​software is eating the world” style keynotes​ will start kicking in. The DevOps community has always aspired to deliver an end to end solution — ​the “pipeline” of software delivery​, to use one of the early metaphors that’s held up to this day. This pipeline is the end result of a continuous delivery focus, a system of software development and delivery that focuses on getting software into end­ users’ hands as quickly and frequently as possible in order to maximize feedback and plow learning back into improving the product.

Looking at the potential for this continuous delivery pipeline, there’s much to offer for operations, but deployment is just the price one pays to have production problems. In addition to the tooling in configuration management, monitoring, and systems management that the DevOps community has evolved in recent years, there are new structured platforms emerging to provide an integrated solution. These platforms, like ​Pivotal Cloud Foundry​, handle many of the concerns DevOps­-minded folks have been fixated on in recent years: packaging applications, handling auto­-deployment and scaling, controlling the nuanced but importantly different uses of stateful VMs and stateless containers in cloud applications, and not only monitoring production but automatically fixing problems when they arise.

With a solid platform in place, the blinking cursor beset can start getting the full benefits of the DevOps dream: gathering rapid feedback on how customers are using their software and continuously learning and deploying new, better versions of that product to deliver value for the business. Once the larger organization embraces the notion of being a “software-defined business,” this means IT staff must start directly programming the business. They become not a provider of “IT services” bound by the limited budgets of a “cost center,” but the ones who create and deliver the business’s core products.

Across the IT industry, we’ve done fantastic work to speed up the software delivery pipeline. All of the work at the operations level has finally given the IT department standardized tools they need to operate with both speed and safety. Companies can take advantage of fully baked cloud platforms and focus on delivering products to customers, not just blinking cursors — just be sure to bring your own DevOps culture. With that new capability, industries now need to start also focusing on how they design and develop better products. Why let the startups have all the fun disrupting industries?

Pivotal is a sponsor of The New Stack.

Feature image via Flickr Creative Commons.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.