When The Open Cloud... Isn't

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 openThere 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 openThe 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'tI 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.

Thank you for this follow up. It's valuable for folks to see that the Oracle v. Google ruling *could* change; however, until it does so I think we'll have to go with the current ruling. The fosspatent.com writeup is compelling, but it's not a legal ruling. I am hopeful that the original ruling stands, but we'll see.

Also, it's unclear how long this will take to resolve. These are all super recent events and the case still needs to hit the federal circuit, so we probably shouldn't make a call on it until it moves further along.

Randy, one of the key points in your article was that open APIs are not copywritable. But the reference to the Google/Oracle lawsuit is a bit out of date. At the time, many thought that the Alsup ruling was incorrect and in fact it seems as if it will be overturned. Take a look at this article by FOSSPATENT's Florian Mueller for more info: http://www.fosspatents.com/2013/12/oracle-apparently-winning-android-java.html ...

Randy Bias is scoring more points for his position in the comments below. Specifically, in his response to Rackspace's Gerardo, he's saying that those who try to distinguish themselves from Amzon on a basis of "open APIs" are barking up the wrong tree. This is a continuation of his disagreement with those members of the OpenStack community who campaign against AWS. As the market leader, he thinks Amazon and its APIs must be respected and OpenStack membefrs must find their place in the universe alongside Amazon rather than entertaining hopes of displacing it.

OpenStack is not monolithic just as Linux is not monolithic. This is its fundamental strength. Certainly Canonical, RedHat, and SUSE don't agree on all things related to Linux operating systems, nor should they. In that same way, all OpenStack vendors can look for eachother's success without necessarily agreeing on business model or technology.

This is why there are hundreds of companies involved with a project like OpenStack, but only dozens with OpenStack's competitors. It's inclusive, democratic, meritocratic, and messy. That's part of why we like it. It's like any other market place, just in micro, not macro.

Choice of a public cloud provider is another freedom, but the problem is that any given public cloud is no more "open" than another. Switching costs are high regardless of the underlying technology and data gravity creates it's own problems. There is inherent value in open source software and even open hardware, but there isn't really any relevant to me as the buyer of a public cloud service if that public cloud service is running on open anything. All hosted services are "closed" pretty much by definition.

I'm afraid your assertions about applications using the same paradigm being manifested by the same API does not wash. See my OpenStack Summit presentation on this matter:

http://www.youtube.com/watch?v=MLMiLmHC6bU

The reality is that the API is mostly irrelevant. You can have different behaviors between two clouds built with the same software and APIs, but different architectures. VM spinup times could be different, number of NICs per VM could be different, and more. All of these items create friction for the application developer or DevOps person. Just look at Rackspace's two offerings: the public cloud provides 2 NICs per VM and the private cloud provides 1 NIC per VM. If your automation tools assume one NIC they will blow up when moving from private to public. And this is literally just one example of dozens I could give.

Saying that the same code and APIs create choice, openness, or compatibility does not make sense. Android on a smartphone runs a Linux operating system tuned for ARM and low power consumption. A Cray supercomputer runs a Linux operating system tuned for a custom parallel processor and very high power consumption. Try taking an application designed for one system and run it on the other. You can't. It's not a simple recompile. Same software, same APIs, different architectures.

This isn't about software or APIs. It's about architectures.

OpenStack has no reference architecture just as the Linux kernel has no reference architecture for an OS built into it. RHEL is a reference architecture for a Linux OS that includes Linux. Open Cloud System is a reference architecture for a cloud OS that includes OpenStack. OpenStack itself does not create interoperability and compatibility. Nor does it's APIs. Only a reference architecture will do that and those reference architectures will not come from OpenStack itself but from those who build a true cloud operating system from it.

For the record, gdada570 is Gerardo Dada, manager of product marketing at Rackspace and author of the Rackspace blog that Bias takes issue with. His Rackspace bio follows: Gerardo A. Dada is an experienced technologist with over 15 years of experience in enterprise software and web technologies. In his current role, he is responsible for all product marketing initiatives at Rackspace inclusive of defining our go-to-market product portfolio strategy, global launch readiness, market analysis and segmentation. Follow him on Twitter @gerardodada.

I wite the post you referenced for Rackspace and I appreciate your point of view. We are close on our fundamental views. We both agree being open is about freedom and choice.

My argument is that the value is not in being able to see the code or change it. The value is that you can build a private cloud with the same software, and choose between many providers (Rackspace, HP, IBM, etc) to run your applications using the same paradigm, which is manifested in the API.

An open API means the community (i.e. OpenStack) can agree on a way of doing business that is more inclusive and does not limit what is possible to the specific views or architecture of a vendor. Being open also means tolerance to divergent points of view and alternative ways of looking at the world, so while I disagree, I respect your opinion.

Cheers,

-Gerardo

(p.s. my comment reflects my personal opinion, which may not be the same as that of my employer)

As Randy says, Salesforce CRM data is a good example of a new silo in IT operations. Indeed, Judith Hurwitz aptly pointed out here how frequently cloud coimputing ends up generating new silos, even though it's not supposed to. "How To Break Down The New Cloud Silos" at http://www.informationweek.com/cloud/cloud-storage/how-to-break-down-the-new-cloud-silos/d/d-id/899722?. So far, openness only comes to vigilent end users, employing all their skills and engagement.

Open v closed is not binary. It's a continuum. In reality, there are multiple dimensions of open-ness to consider at different layers of the IT stack, all the way down to the concrete and up to the user experience.

Right -- at this point, the term "open" is about as well-defined as the term "cloud." And while it's true that few companies willin practice yank all their data out of Salesforce.com, CIOs damn straight should know that they canif circumstances dictate.

Enterprise 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.