Agility is the widely accepted watchword for cloud computing. Customers are embracing a renaissance of thinking that focuses on the idea of DevOps as a means to achieve agility. Any discussion about DevOps, like so many buzzwords, can quickly become mired in semantic arguments, but the one truism we can all agree on is that we need to break the traditional barriers between application developers and IT infrastructure operators.
Most enterprises have created environments in which developers and operators are rewarded for fundamentally opposing goals. This disconnect has existed for as long as I can remember. Developers, operating on behalf of the lines of business, are focused almost entirely on creating new value for the business. Meanwhile, infrastructure operators are focused almost entirely on managing down risk.
For an enterprise developer, getting to market in the fastest manner possible is what matters most. Conversely, infrastructure engineers and architects focus on making sure the network, servers, and storage systems never go down.
Time after time, I hear a similar story from our customers that goes like this: "We went to the infrastructure teams with the long list of requirements for our new application. They told us it would take 18 months and $10 million before it would be ready. So we went to Amazon Web Services (AWS). We didn't get our list of infrastructure requirements and we had to change our application model, but we got to market immediately."
That's because the inherent value of AWS has less to do with its cost and more to do with its delivery model, which is on-demand, elastic, and very developer-centric. If delivering an awesome infrastructure cloud was only about providing virtual machines on demand, then Amazon, Google, and Microsoft would already have serious competition in public cloud -- and they don't.
Developers' overriding concern for the rapid and inexpensive delivery of new applications that support new business initiatives should be obvious. Operators' need to support developers in this mode should also be obvious. If they do not, then developers will continue to go exclusively to public cloud services. Security, control, compliance, cost, and many other factors will almost always take a second seat to driving new revenue opportunities, which is as it should be for any healthy business.
Historically, operators have focused on reducing the risk of new initiatives by gold-plating the initiative: spending as much as necessary to have the "best" solutions, which of course are usually the most expensive as well. In contrast, the public cloud operators usually buy the cheapest, not the best.
Cloud applications designed via a DevOps model deploy themselves, detect server failures and adapt, and do their own data replication. Cloud-native applications route around failures, making gold-plated infrastructure superfluous. In fact, what enterprise IT infrastructure operators want to do in the new model is focus instead on building a single, enterprise-wide private cloud system that is inexpensive, easy to operate, and focused on cloud-native applications.
Now, a new trend is emerging in the enterprise. Both operators and developers realize that open-source cloud platforms such as OpenStack are the ideal building block for the new elastic cloud model. We saw this happen with Linux, which was the ideal building block for web applications and the Internet. Like Linux, OpenStack may ultimately supplant the previous proprietary incumbents that solved similar problems, while also solving whole new categories of problems.
Imagine this: Developers have an elastic cloud to target cloud-native applications; operators have built and designed this private elastic cloud to look like a public cloud; and the cloud is based on open-source tools such as OpenStack.
A wonderful thing happens because suddenly, the fear of failure evaporates. Just as with a public cloud, if a new application initiative fails, you simply shut it down -- no harm, no foul. The cost of failure is inexpensive, which fosters risk taking, which in turn creates a culture of acceptance of failed initiatives. Again, it's hard not to draw parallels to the Linux experience, where the move to industry-standard x86 servers running Linux reduced the cost of failures compared to the legacy RISC UNIX days.
It's this shift toward a new application model that embraces failure that will ultimately demolish the barrier between developers and operators in the enterprise, lead to IT harmony, and deliver true DevOps. This new model requires a change in thinking around how applications are designed and delivered, combined with a change in thinking around how private clouds are designed and delivered. Neither can stand alone.
Embrace change and failure now. Be the person in your organization who helps move to the new elastic cloud model and delivers true DevOps.