Red Hat’s annual conference in Boston this year features a major foray into cloud computing, with a commitment to OpenStack, the open source cloud alternative gunning for market traction against Amazon’s EC2 and VMware.
Red Hat has prospered by taming the open-source beast without killing its animal spirits. By metabolizing innovation from developers who work for other people into software they sell and support, they’ve successfully become the establishment Linux player — the only open source company to grow past $1B in revenues. They’re also the #1 contributor to OpenStack code; a pattern emerges.
Red Hat customers featured on the posters around the conference are almost all 40- and 50-somethings. In fact the greying, largely male audience of attendees is hard to tell apart from those I’ve met at Oracle Open World. A small minority of those I spoke to here asked a troubling question: “Is OpenStack mature enough?”
What’s troubling is not the question; OpenStack is, without question, still maturing. So I answered: “Mature enough for what?”
The systems where we keep information on this planet have grown and accumulated so rapidly that organizations managing those systems are choking on all that cumulative past innovation. To keep their heads above water, they try to control their perceived risks with proven infrastructure technology.
The downside is that they expose themselves to creative destruction in two directions. Sure, faster, cheaper, better technology to run their existing business applications will make their systems obsolete. But businesses who create new applications more quickly will steal their customers, and there won’t be anyone to pay for those nice new systems, even if they cost less. Put more succinctly: if you focus exclusively on building the infrastructure that can’t fail, the business that runs on that infrastructure will fail.
How so? One of the basic principles of running an application on the cloud is that the cloud servers will fail, and the application needs to absorb those bumps without hurting customers. The risk is that the wrong people have to absorb those bumps: IT externalizes the risk onto their business application developers.
Ask any corporate developer how long he or she has to wait for a server to build and run new software on. They’ll tell you it’s weeks to months, for IT to allocate their systems, configure their networks, set up security controls, provision their storage, and test whatever new code has been written – delays of weeks and months before new code can begin to deliver customer benefits.
One financial services company we work with found out that the typical daily contribution of a new transactional algorithm was $10,000; the typical time to take that algorithm from the developer to production deployment was 180 days. Even if you spent four years in fifth grade, you can do the math.
The appeal of cloud platforms like OpenStack and Amazon EC2 is that the infrastructure itself is programmable. The leading, disruptive digital businesses – from Apple to Facebook to Paypal to Expedia to Netflix – have all set up cloud infrastructures that automatically allocate developers a standardized combination of network, storage, memory, compute that they can control using software – quickly, without manual intervention or bureaucratic delays.
OpenStack’s standardized cloud control APIs means that developers can allocate a slice of cloud infrastructure via self-service; in the time it takes to fill out a service request ticket, they can apply the parameters of their desired compute environment and provision it themselves. Then, because it’s standardized, they can use that configuration and its APIs in development, test, and production, eliminating costly delays. New functionality that delights customers gets out the door faster – fast enough to keep those customers.
Most Red Hat customers understand this, even though their use of cloud technologies is early. (VMware doesn’t count as cloud). Even better, they’ve learned the lessons of Linux adoption, starting small, finding the risks and working them out rather than hoping to avoid them. They’ll make mistakes, learn from them, fix them, and accelerate from there.
IT organizations who look for maturity first are looking backwards. Maturity comes from experience, not the other way around.