FUD is a lot like commodity open source software. It just keeps moving up the stack. A decade ago, the FUD was all about operating systems and database software. Now? It's migrated up to the cloud stack. FUD may be mobile, but it hasn't gotten any prettier.
Case in point, the efforts of OpenStack supporters and Rackspace employees to sow fear, uncertainty, and doubt about competing platforms.
Amazon Zombies, Eh?
As mentioned last week, some members of the OpenStack camp have started attacking CloudStack instead of touting the wonders of the OpenStack Essex release.
Jim Plamondon, director of developer experience for Rackspace Cloud, has been on a particular tear, leaving comments deriding Eucalyptus and CloudStack as 'zombie projects'. (Note, I contacted Plamondon directly via LinkedIn and verified that the comments are actually his.)
According to Plamondon, Amazon is using those projects "to achieve its strategic directives... Any firm that uses these zombies runs the risk of infection with the zombie virus, thereby risking disaster when Amazon slaughters its zombies in a future Cloud Zombie Apocalypse."
At least he's entertaining. Then again, Plamondon has had time to hone his delivery and studied at the feet of masters. Plamondon is famous (or infamous) for characterizing developers as "pawns" and says Amazon is "stealing a page from Microsoft's 'How to Build a Monopoly' playbook (of which I wrote one small chapter, back in the 1990s)."
Setting aside the colorful rhetoric, here's how the claims boil down:
- Implementing Amazon APIs is some sort of desperate ploy in reaction to OpenStack.
- CloudStack and Eucalyptus cannot implement new cloud services, unless they're implemented by AWS.
- CloudStack and Eucalyptus are "controlled" by the APIs.
- At some point in the future, Amazon will withdraw access to the APIs and "slaughter" the companies using them.
- Companies that use either stack are "infected" by using technology that apes the Amazon APIs.
Let's start with the first claim, that Eucalyptus and CloudStack are implementing Amazon's APIs due to the "threat of economic death by the meteoric rise of OpenStack." (Plamondon's words, not mine, though I fixed his typo.)
Given that Eucalyptus started as a project to implement the Amazon APIs, this claim is easily proved wrong. Plamondon should know better, since some of OpenStack's origins come from a fork of Eucalyptus.
Whether Eucalyptus or CloudStack are "threatened" by OpenStack is also irrelevant in considering whether Amazon's APIs are good or bad for the projects or companies using them.
The next claim, that CloudStack or Eucalyptus cannot implement new services, is also off-base. What's necessary for API compatibility is that they provide an analog to Amazon's services using the same API. There's nothing about using the Amazon APIs that precludes Eucalyptus or CloudStack from offering additional APIs or services that do not correspond with the Amazon APIs.
Case in point, see the Eucalyptus 3 product roadmap, which includes features above and beyond Amazon's API. Eucalyptus features "AWS Identity and Access Management (IAM) API Plus Extensions for On-premise Clouds." Does this sound like an inability to implement new cloud services? It may be a modest extension, but it's a feature set beyond what Amazon offers. Once again, easily disproved.
Plamondon should know this. Microsoft, after all, practiced and popularized the term "embrace and extend." There's no technical reason why a community cannot implement the AWS APIs and offer additional features.
Next is the claim that Amazon "controls" the companies with its APIs. There's some merit to this, in that to stay compatible, the community has to keep up with changes in Amazon's APIs. Further, there's no indication that other organizations have a seat at the table when Amazon makes decisions about its APIs.
Having a standard controlled by a single organization is a totally legitimate concern. If the rest of the IaaS/PaaS vendors could sit down and agree on a standard set of APIs, the industry would be much better off.
Not surprisingly, Plamondon suggests that OpenStack is the "open API, openly designed and openly governed." Lots of "opens" in there, and it's certainly more open than Amazon's process for creating its API. Then again, not everyone has been pleased with OpenStack's governance so far. When OpenStack's foundation takes shape and it's clear the full OpenStack community is in charge, this argument will be more convincing.
Zombie Slaughter and Scariness
Finally, let's consider the last claims - that Amazon plans to pull a Microsoft and remove access to the APIs, kill off the competing projects and force companies to move to AWS. Says Plamondon: "Only by preventing OpenStack from establishing a truly open cloud stack - with an open API and an open implementation, designed through an open process, openly governed - can Amazon establish the kind of Total Industry Domination that Microsoft attained in the 1990s."
Plamondon cites Microsoft licensing Windows' source code to third parties to thwart Sun's efforts to provide a Windows compatibility layer to allow running apps developed for Windows 3.x on Solaris. Microsoft licensed Windows source code, until the contracts ran out and then it refused to license Windows NT 4.0 or 5.0.
But that is a very different scenario. Amazon isn't licensing source code, it's publishing the APIs and others are implementing them. Conceivably, Amazon could stop publishing updates to its APIs or try to slap restrictive terms on them. But the relationship between Amazon and others implementing its APIs differs significantly from Microsoft's relationship with its licensees.
It's unclear whether there's any license agreement for the APIs between Amazon and CloudStack. The agreement that Amazon has formed with Eucalyptus is not public, and nobody's talking on that one.
OpenStack also implements some Amazon APIs, as well. Presumably, Rackspace and the rest of the OpenStackers did not need to reach a license agreement with Amazon prior to implementing this.
Secondly, there's not much evidence for the premise that Amazon will "slaughter" those implementing the APIs. Just because Microsoft was willing to engage in less-than-friendly practices to protect its dominance does not mean that Amazon will do the same.
An Amazon assault would most likely include a patent suit. If that's the case, choice of API will matter very little. Amazon can sue Rackspace, the OpenStack Foundation or Citrix on cloud patents regardless of whether they implement the AWS APIs.
Look around a bit, and you'll see plenty of software patent suits. You'll also notice that if a company wants to sue a competitor for patent infringement, it doesn't matter whether the other company is implementing any APIs. Consider the Microsoft suit against Barnes & Noble. It has nothing to do with implementing any APIs - merely that Android presents a threat to Microsoft, and Barnes & Noble has been unwilling to pony up licensing fees.
If Amazon wants to attack competitors, it can cite its patent for "managing access of multiple executing programs to non-local block data storage" or another one of its other cloud patents. It doesn't need to prove that the infringement relies on implementing the AWS APIs.
By the way, this isn't a suggestion. It'd be nice if the cloud industry could avoid the patent shenanigans roiling the mobile industry. But the notion that Eucalyptus and CloudStack are particularly susceptible to attack because they've implemented the Amazon APIs is shaky at best.
None of this should take away from the exceptional work that's been done by the OpenStack community during the past few years. Despite the fact that the OpenStack community is still heavily dependent on Rackspace, it's grown admirably and continues to improve. It's a shame that anyone involved in the project feels the need to try to spread uncertainty and doubt about other open source projects.
Likewise, it would be unfortunate if these efforts succeeded in undermining Eucalyptus or CloudStack. If OpenStack offers a better alternative than Eucalyptus or CloudStack, then developers and companies should embrace it. Either way, the choice shouldn't be driven by FUD.
Photo courtesy of Shutterstock.