Cloudscaling CEO Randy Bias argues that using public APIs and open-source code doesn't make your cloud service "open."
Editor's note: CEO Randy Bias's Cloudscaling firm is a cloud software supplier competing with the companies cited in this commentary.
As one of the earliest proponents of the notions behind an "open cloud," I always find it amusing when the purity of message is diluted behind marketing fluff. Recently, two blog posts, one from IBM and another from Rackspace, revealed a deep misunderstanding of what openness is about generally and what "open cloud" is about specifically.
Being open There has always been a debate about "open-source software" vs. "free software," but it is generally accepted that the discussion is about level of freedom. Open-source software provides freedom to access and see the code, while free software, theoretically, provides more freedoms, most notably greater flexibility in licensing.
Of course, the debate gets even murkier when you look at something like the Apache Public License, which allows not only the ability to see the code, but to copy and use the code commercially -- yet another freedom that may be important to you. Regardless, what is clear is that both open-source and free software provide choice and freedom, and most of the argument is about to what degree and around what dimensions you get choice and freedom.
The ideas of being open have evolved significantly. For example, the Open Compute Project (OCP) provides "open hardware," an attempt to institute freedom of choice for hardware suppliers. At its heart, you get access to the "code" (server, motherboard, and other hardware designs), but since not everyone can manufacture their own hardware, the true value is that you can take these designs to anyone you want to build the hardware for you. So, unlike open-source or free software, it's unlikely you can open up and modify the code directly, but you can certainly use what's available to reduce lock-in by specifying to the hardware manufacturer what to make on your behalf.
Hosted services will never be open The recent Rackspace blog post shows how far afield we have come on "open," which is now being badly abused as a notion. There is no reason to pick apart the article point by point, but a few key items are worth calling out.
First, the FUD around "proprietary API" is just plain nonsense, given the Oracle v. Google ruling that public APIs cannot be copyrighted. That's right. If it's a public API, it's "open" by default. You can copy, imitate, and modify to your heart's content.
Second, there is a long spiel about "open" being about "flexibility... not a licensing model," and a "philosophy that encourages customers to do business with you because they want to, not because they have to." Except, none of these are generally accepted uses of the term "open," nor do they resemble anything other than Rackspace's existing business model.
Most importantly, these points appear geared to convince the reader that nothing could be more "open" than Rackspace's public cloud. Here I fear we wander off into fantasy land. Hosted services cannot be anything other than closed and proprietary, regardless of what software is used to run them.
Why is this? If the license of the software you use to run your hosted service determines your "openness," then aren't Amazon and Google already the biggest open clouds around? They are certainly two of the world's largest consumers of open-source software. But they don't have an "open" API? Except there is no such thing as an open API, is there?
Hosted services remove freedom and enforce a certain amount of lock-in, far more than you would receive from open-source software or open hardware. If you run your application on Amazon Web Services, Google Compute Engine, or Rackspace Cloud, you will be locked into their closed systems. You can't see their code or any proprietary changes, you can't replicate them, and you can't walk away with their alterations. Your freedoms are severely curtailed.
Open isn't whatever you call it "Words have meaning, and names have power." Miguel de Cervantes Saavedra brought us this bit of wisdom. The value in terms and our notional understanding of them is that they allow for communication. Communication is impeded when terms are grossly overloaded. We all saw this with the term "cloud" itself. IBM's recent blog posting takes "open cloud" to the new extreme, equating it to scalable storage architectures, interoperability, open APIs (already disproven if you see above), federation, data mobility, and openness in public clouds.
Open-source software is not a standard, nor does it create standards. Standards can exist regardless of the type of software used. Typically this is because the interfaces (such as APIs) between systems are not protected, or because all participants have agreed to license a private interface. Open cloud won't make storage architectures more scalable, lead to federation, or increase data mobility. These last two may certainly provide some freedoms if implemented, but they are not freedoms themselves, and having an "open cloud" certainly doesn't create them.
Take, for example, data mobility. Do you want to own and move your data back and forth between two systems? Of course you do. We all do. But in practice, how often have you out-loaded your Salesforce.com customer data and imported it into another CRM system? You haven't, because it's hard. All hosted systems, regardless of what kind of software they use, store their data in proprietary data structures and schemas. They must, because typically this is how they create and maintain competitive advantage. You can't easily create data portability/mobility between any two hosted systems. The exact same problems that have plagued enterprise integration efforts for decades also exist for all public clouds, SaaS, or other hosted services.
Open isn't whatever you call it. Open has meaning. It's about freedom for you and for me. Hosted services increase, not decrease, lock-in.
When the open cloud... isn't I want as much openness as I can get. I'm sure you do as well. Openness equates to freedom, and we all want more. But freedoms come at a price and always have. In this case, if you want to maintain control, you must be prepared to maintain the code. By extension, that means you must be prepared to run the system. No one else can help you be open. You must help yourself.
The open cloud is only what you make it.
Randy Bias is co-founder and CEO of cloud software supplier Cloudscaling. He pioneered IaaS at GoGrid and is a founding member and current board member of the OpenStack Foundation.
Can the trendy tech strategy of DevOps really bring peace between developers and IT operations -- and deliver faster, more reliable app creation and delivery? Also in the DevOps Challenge issue of InformationWeek: Execs charting digital business strategies can't afford to take Internet connectivity for granted.
Multicloud Infrastructure & Application ManagementEnterprise cloud adoption has evolved to the point where hybrid public/private cloud designs and use of multiple providers is common. Who among us has mastered provisioning resources in different clouds; allocating the right resources to each application; assigning applications to the "best" cloud provider based on performance or reliability requirements.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.