AWS and Zombies

However, this restriction will not apply in the event of the occurrence (certified by the United States Centers for Disease Control or successor body) of a widespread viral infection transmitted via bites or contact with bodily fluids that causes human corpses to reanimate and seek to consume living human flesh, blood, brain or nerve tissue and is likely to result in the fall of organized civilization.

" Simon, I respectfully beg to differ.

Eucalyptus and CloudStack are merely “zombie projects,” being used tactically by Amazon to achieve its strategic objectives — as Microsoft used similar zombie projects in the 1990′s. 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.

Please allow me to explain. :-)

In traditional voodoo, “zombies” are corpses raised by a sorcerer and completely controlled by the sorcerer’s will, with no freedom of thought, choice, or action. If raised soon enough after death, they may LOOK alive, but they are…merely zombies.

Eucalyptus and CloudStack are now “zombie projects.” They are utterly (although indirectly) controlled by Amazon, through the projects’ need to maintain compatibility with Amazon’s AWS APIs. These projects may once have had independent life, but — threatened with economic death by the meteoric rise of OpenStack — they have chosen to become AWS zombies instead. As such, they have lost all freedom of thought, choice, and action. They can implement no new cloud services, other than those previously implemented by AWS. Their architectures cannot be creatively improved, lest they break compatibility with AWS. They are zombies, serving only Amazon’s will — and serving only Amazon’s strategic interests. Every company that comes to rely on these zombies becomes infected with their zombie virus, and thereby exposes itself to a future Cloud Zombie Apocalypse.

In creating these zombies, Amazon is stealing a page from Microsoft’s “How to Build a Monopoly” playbook (of which I wrote one small chapter, back in the 1990′s).

Consider one of Microsoft’s best-documented zombie-creation programs, the Windows Interface Source Environment (WISE, http://en.wikipedia.org/wiki/Windows_Interface_Source_Enviro...). Microsoft used the WISE program to combat Sun’s WABI & PWI projects, which sought to create Unix-based implementations of Microsoft’s Win32 API. This API was the key to Microsoft’s vendor lock-in, and so Microsoft wanted to control any such implementations.

By licensing Windows’ source code to third parties such as Hunter, Mainsoft, and Bristol, Microsoft created “zombie projects” that out-competed Sun’s WABI & PWI. Once the tactical threat of WABI & PWI was eliminated, Microsoft slaughtered its zombies, as detailed in the records of subsequent anti-trust actions (see http://en.wikipedia.org/wiki/Bristol_Technology_Inc.#1998.E2...). Any apps that targeted the Win32 API could then run only on Windows…which was Microsoft’s strategic goal.

Microsoft could kill its WISE zombies because of the fine print in the WISE program’s license agreement, which — is it had been public and were closely examined — would have revealed signs of the coming Win32 Zombie Apocalypse.

At the same time, Microsoft created a zombie project on the Mac: the “Visual Studio 4 Cross-Development Edition for Macintosh,” to further establish its Win32 API as the industry’s de facto standard. This zombie enabled developers to recompile their Win32-based apps to run on the Mac. This worked so well that at least one such app won an “Eddy” award for best new Mac app one year. Indeed, it worked so well that Microsoft’s apps group burdened its license agreement with restrictions on the kinds of apps that could be created with it, to ensure that no one could use it to create an Office-killer.

Again, the zombie project’s fine print contained signs of the coming Win32 Zombie Apocalypse.

Many developers were seduced into supporting the Win32 API in part by the zombies’ demonstrated ability to deliver cross-platform deployments. When Microsoft slaughtered its Win32 zombie projects (in the Win32 Zombie Apocalypse), these developers found that they had no choice but to deploy their apps on Windows, and only on Windows, because it was the only Win32 implementation left. Which was, of course, the WHOLE POINT of Microsoft’s creation of these zombies in the first place: to lure developers with claims of portability, with the intent to eliminate such portability as soon as the tipping point had been crossed.

Zombie-creation is just too effective a tactic NOT to use, if you’re trying to lock the entire industry into a proprietary de facto standard.

That is, of course, exactly what Amazon is doing today. It is attempting to establish its proprietary AWS API as the industry’s de facto standard, and one of its tactics is the resurrection of corpses like Eucalyptus and CloudStack as zombies. These zombies walk, and talk, and smile, and market just like living projects…but Amazon can — and will! — slaughter them as soon as they have served their tactical purpose.

Some pundits, seeing Amazon re-animate these private cloud zombies, have taken Amazon’s actions as recanting its leadership’s previous denunciation of private clouds as “false clouds.” Ha! Far from it! The zombies are a mere tactic, advancing Amazon’s strategic objective of providing the One (Public) Cloud to Rule Them All. The sole (not “soul,” because zombies have none) purpose of Amazon’s zombies is to slow OpenStack’s momentum. 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 1990′s.

When Amazon uses the fine print of its license agreements (and/or its rapidly-growing portfolio of cloud patents) to slaughter its zombies in the Cloud Zombie Apocalypse, each company that has come to depend on such a zombie will realize that it, too, has become infected with the zombie virus. It, too, will have lost its free will. Every line of code that its has written to AWS’ API will compel it to switch from the zombies’ private clouds to Amazon’s public cloud (or to a private cloud service that Amazon may, by then, have started), because no other implementations of that API will then exist.

This outcome would, of course, be tremendously valuable to Amazon. It would give Amazon a monopoly on cloud services for the foreseeable future — an outcome that is clearly worth exploiting a little fine print.

On the other hand, it would be disastrous for the industry, and damaging to the entire world economy. Just because Microsoft got away with it, doesn’t mean we should let Amazon, too. We can choose to learn from history, rather than repeat it.

Fortunately, the solution is simple: use OpenStack — an open implementation of an open API, openly designed and openly governed — to meet your cloud computing needs. Using OpenStack is an vaccination against the coming Cloud Zombie Apocalypse.

So: is AWS’ API already the de facto standard cloud computing API? Not even close. It is, at most, the CP/M to OpenStack’s DOS. And as these references show, this competition is still in its very early stages.

Simon, I understand that you disagree. But you shouldn’t. Dig in a bit, explore the history of zombie projects, and see for yourself how they’ve been used to create the false appearance of de facto standardization long before the issue has truly been settled.

You are far to virtuous a person. Simon, to continue luring people into the zombie trap, once you see it for what it is. Or, if I am mistaken on that point, I can hope for your future redemption. I, too, once lured people into the zombie trap. It is a relief, now, to be on the side of the angels. I hope that you’ll join me there.

Respectfully,

Jim Plamondon Director, Developer Relations Rackspace Cloud"

https://aws.amazon.com/lumberyard