Boycott the Enomaly hoax and censored cloud-computing Google Group

Update: I have been asked to remove this post by the new CEO of Enomaly on the basis that they are changing/have changed since it was written. While there are some signs that this is the case, as a matter of policy I have not yet deleted a post and I don't intend to start here. Until I work out what to do with this request, bear in mind that this is a (dated) personal opinion and that you should draw your own from the facts which you should also verify yourself (in most cases I have linked to primary sources). Thanks.

It's now been two weeks since I posted the 'Enomalism vapourware lands Enomaly in the cloud computing doghouse' article. Enomalism is still vaporware (Update: despite being rebadged 'Enomaly Elastic Computing CloudPlatform' or "EC2ECP") and the offending group is still arbitrarily censored according to 'Moderator' Khazret Sapenov's personal whims and fancies, only without me, a few other bloggers and of course Reuven Cohen himself. We've had comments ranging from '[we] decided it was not for us [as] the ability to do the most basic tasks were just not there' through comparisons to 13 year old boys in the bedroom (and worse), and perhaps most accurately:

[The Enomaly] ship is taking on a lot water and is on fire, and I don't see a rescue anywhere in sight.

Meanwhile, being "quintissential professionals" (their words) they've resorted to spreading FUD and actively and blatantly slandering me, my company, fellow professionals and the community itself and I've personally been called a liar, a charlatan and a "fake cloud expert", my posts an insomnia cure, accused of self-promotion, associated with Osama bin Laden(!!!), even compared to a dog as well as Martha Stewart (?!?) and had my sexuality questioned by 'Jeremy', a brand new anonymous coward poster who conveniently appeared at the same time as Reuven Cohen (the head honcho for those who just joined us). Defending the indefensible, he lynched James Urquhart for offering support and (like Reuven Cohen) took exception to our posting photos; an obvious if unprovable connection. Oh, and 'Jeremy', thanks for pointing out the one assertion I didn't feel the need to give proof for (my being 'the #3 poster at the time' in the offending Google Group). Here's a screenshot of the stats showing me 1 post off #2 position (like it matters - the point was that us active and early contributors who built the group by actively participating could be considered stakeholders, as they are in the open Cloud Computing Community).

"So will Enomaly open up the community voluntarily or do [they] need to be coerced? And no, I don't buy that this is a personal endeavour and I doubt anyone else will either."

While this 'guerilla warfare' style response could have been anticipated from a fly-by-night outfit with three-men-and-a-dog (hence the carefully constructed, researched and referenced article), the various private thankyou notes from people within the community who wanted to say something like this but for whatever reason couldn't caught me by surprise; thanks too all of you for your public and private words of support. These ranged from simply 'Thanks for your recent post on these guys.' to this:

Sam,

Longtime listener, first-time caller, as they say.

I'm loving your blog. And I just swallowed the Enomaly piece -- very well linked, good job providing that background material. [snip]

Keep up the great work.

[snip]

Suffice to say the level of disdain for these guys within the community is both surprising and (less surprisingly) on the rise, and...

Yet you've still got a handful of people talking about Reuven Cohen like it's the second coming of Christ

...comparing him to the likes of Vin[t] Cerf, Ray Ozzie, Marc Benioff, and a bunch of others who have actually walked the walk rather than just talking the talk (although apparently the going rate for this kind of praise is a $50 bottle of red). Yes CloudCamp was a good (if obvious and inevitible) idea and the logos's cute - indeed I'd even attend if I was Silicon Valley rather than Sydney on Tuesday 30th September. Given the prospect of event organisation sends shivers down my spine I'm glad others are doing it - kudos also to co-conspirator Dave Nielsen who arguably deserves his fair share of the limelight. However the real thing these guys are seeking (and getting) credit for (EnomalismEnomaly ECP) is still to this day vapourware, with no release in sight after a long string of alphas, betas and flaky (yet according to them 'STABLE') 'release candidates'. Update: Enomalism has since been condemned to the land of vapourware for eternity (see below) and the rebadged Enomaly ECP is hidden here, behind a broken email harvester and a curious 'contact us for SVN access' message.

"Do take this seriously - I feel very strongly about this community hijacking and am not in the least bit impressed by [Khazret]'s behaviour; I won't discriminate between any of [them] (and Enomaly) in my response if the gloves do have to come off given [they] have been given ample opportunity to intervene."

Let's not forget about Khazret Sapenov, Enomaly's Director (yes, that's right, Director) of Research & Development, presumably therefore a key player in the ongoing failure to deliver, as well as fascist (in the words of his own boss, Reuven Cohen) moderator of the cloud computing Google Group. I'm not aware of any meaningful "Research" that Enomaly's "Enomaly Labs" "a(sic) emerging technology incubator" is credited for and we've already seen what the "Development" division is[n't] capable of. Then again, given he's flat out moderatingcensoring the offending group at all hours (both on and off Enomaly time) it's not at all surprising.

"One of the persistent questions we've heard over the last couple years is what "exactly" does Enomaly do?"

Meanwhile Reuven Cohen (self-proclaimed cloud "advocate", "provocateur", "pioneer" & "prominent blogger") threw a hissy fit at the weekend and quit the group 'for a few days' (only he didn't according to yesterday's activity in the group's List of Cloud Platforms, Providers and Enablers). This was almost certainly a feigned attempt to 'arms length' it, despite continuing to talk about it as his own and take credit for founding it along with a bunch of other dubious distinctions like 'creating' the term elastic computing (which I am told by a reader was in commercial use this time back in 2001 and which they didn't use until some time after Amazon popularised it). He then rebadged Enomalism as the highly original and not-copied-from-Amazon-at-all "Enomaly Elastic Computing Platform (ECP)" while "proudly and clearly stat[ing their] new mission to bring 'Clarity to Cloud Computing'".

Clarity to Cloud Computing? Forget the fact that cloud computing is well accepted to be Internet based and Enomaly's EnomalismECP is on-premises virtualisation vapourware.

If he's hoping that I'll forget about it then he's got another think coming... I'm just getting started and as I said before, he "most definitely not going to like what happens next but [he] can't say [he] weren't explicitly warned".

Speaking of Reuven Cohen, one of the more interesting revelations that surfaced from this fiasco was the claims that...

"posts are delayed [by Khazret] so that Reuven is able to post on the topic first"

...and by extension, take credit for others' leads, insights and vision. As an active poster I believe this is both possible and probable (even if others don't), especially given their recent [mis]behaviour and although also unproveable the archives certainly concur with this theory. It would go a long way towards explaining why control of the group is of such paramount importance to them and their "visionary". That and the list itself.

'The List™' you ask? So did I when I saw that I'd been publicly accused of "approach[ing the] creator of The List demand[ing] status of partner with access to [The] List of members e-mail addresses". So that would explain why I've been badgering them - fair enough they deny my unreasonable request, right? Wrong. It was never about 'The List' until they made it about 'The List' - I clearly couldn't care less who in the community is blessed as moderators (I dare not even suggest that it should have been myself) so long as one can post without fear of arbitrary (or worse, calculated) repression.

My exact words were "please add a few of the other active community members to [help] administer it"...

So judge for yourself how unreasonable I was now that you have the full story, as while Khazret Sapenov is happy to deep link employment standards legislation he conveniently doesn't bother linking his slander to its victims' posts at all. And now there's all this talk about "easily giv[ing] it up without any resistance" and "who cares, you just need the damn list, noone remembers it afterwards". In fact, Khazret Sapenov made reference his precious list (like Gollum's precious ring) on no less than eight separate occasions in his seven point defamatory diatribe and another half a dozen times in his back-to-back broadside. That's over a dozen times for something I didn't mention even once - I couldn't care less about collecting email addresses, especially when the offending post is promoting an open source prototype.

Getting to the point, let's straighten a few things out with regards to Khazret Sapenov's utterly ridiculous accusations and implications:

From How to become a cloud guru:

• Like many I was foisted into the group after connecting on LinkedIn, hardly the same as 'Find community, get your posts injected there'. The quality of my posts is not an issue and I utterred the phrase 'compute cloud' once, while telling Reuven to calm down about standards.
• I'm not discriminatory about who I'm "bashing" - particularly crass acts of stupidity by individuals and small organisations occasionally warrant highlighting too, and no, Enomaly is not by any stretch of the imagination "large company".
• The Cloud Computing Community's mailing lists and wiki already have a bunch of users despite not even having been properly launched yet, and in any case I couldn't care less if I was the only user if the archives (like this blog) would still be useful to others. Of course it would be a lot easier if they would just let the community use the existing group so as to get diversity in opinions, but they have Enomaly's own commercial agenda to satisfy.
• We've already addressed my "approach[ing] creator of the list and demand[ing] status of partner with access to list" above (it simply never happened). Same for "get[ting] some members of initial mailing list on [my] side", "promis[ing] something to them", blah blah blah.
• Despite both of them constantly bitching about James and I posting postage-stamp sized photos, they were removed at Reuven's behest and yet he still posted mine at the top of his first diatribe. As he linked to one I had hosted on S3 I took the liberty of replacing it with something more appropriate, but the hypocrisy is laughable.
• "Mak[ing my] buddies duplicate this post and add comments under different nicks" is a convenient way to bundle all the abuse together at my doorstep, but I'm afraid your delusional - there are plenty of people who have simply had enough of Enomaly's drivel.
• As for The Cure of Folly, talk to me when you land your first production 32,000 user cloud computing deployment (like the one Google co-founder Sergey Brin was bragging about in the recent earnings call).
  

From Sam Johnston is barking at Dell, Nirvanix and Enomaly:

• On Dell's trademark, as I explained clearly in my very first post on the subject (which popularised the group by bringing it into the mainstream press), I wasn't "struck by bright idea to trademark 'Cloud Computing'" and "upset to know that it was already taken" but rather perplexed by the ™ symbol in Dell's first Cloud Computing™ press release and surprised nobody else picked it up in almost 18 months. Being a proponent of competition without intellectual property [ab]use and seeking to level the playing field I (successfully I might add) worked to have the allocation struck down.
• "Oh, Nirvanix screwed up?" If you call being implicated in the effective loss of hundreds of gigabytes of data held in trust on behalf of 20,000 paying customers "screwing up" then yes, they did. I take it that you're condoning your partner's [in]actions and see no problem with this then. Figures. At least you accept their responsibility.
• The Dell scoop was big news, as evidenced by coverage by everyone from The Register to The Wall Street Journal.
• On the censored Google Group: "Khazret Sapenov owns a good one". Exactly - therein lies the problem.
• On taking hostages, "so they force him to give me a good bit of the list contacts", I couldn't care less about The List™ and just want an open community and a level playing field. Enomaly have proven time and time again they can't be trusted, preferring to play dirty underhanded tricks than play fair.
  
• "Employment standards? Human rights?" WTF?
  
• As for "I'll contact most active participants of their list to defect to my 'open' list", this is straight from fantasy land, but nonetheless it's not a bad idea - if they know about the goings on on under the table and still choose to stay then they deserve what they get. I'll look into it, especially now he's dragged the entire list into this by spreading FUD and we have a few useful feeds of the posts courtesy some "useless lurkers".
  
• The Cloud Computing Community Wiki was not created because "Wikipedia is lame" but because we need somewhere to produce original research like the Cloud Computing Incidents Database; new knowledge, rather than to present the existing knowledge in a new form (e.g., summarized or classified), which is explicitly forbidden by Wikipedia.

And in general, there's no point in declaring my posts "totally off" and that I've used "bad information", "90% of [which] is not true" without specifically identifying so much as a single error or omission. I've been very careful to source everything, having a good faith belief that it is correct, and encourage them to identify any points that need updating. In any case this is just my opinion and others are welcome to draw their own conclusions.

A censored and manipulated community is worse than no community at all.

Anyway, while writing this has provided some amount of entertainment on an otherwise uneventful Paris-London train ride (and hopefully some mild entertainment for you readers), there's plenty of other more useful things I could be doing when I get back online.

That's why I'll try to stop feeding the trolls and boycott Enomaly and their censored Google Group instead. I encourage you to do the same.

That is, at least as long as they defend this indefensible position, after which time I reserve the right to pull a 180 and give them their fair chance of success (including potentially pulling these posts as it's not my intention to inflict damage but to restore order by leveling the playing field). With any luck they will do a quick cost benefit analysis on the value of hoarding and manipulating the community versus the cost of the (significant) bad will this is generating (and will continue to generate).

If you remain unconvinced need proof of their antics just follow Geva Perry's example and try to have this important issue discussed on the list - you'll soon enough be infuriated (and probably banned) too.

• If you have a blog, blog about it.
• If you have a talk, talk about it.
• If you see a story, comment on it.
• If you see a listing, rate it.
• If someone asks, tell them (and maybe even if they don't).
  

But don't post to the cloud-computing group or buy Enomaly products and services until you're satisfied with their prevailing policies. And like with Nirvanix, if you have a grievance then take it to Enomaly's new page on GetSatisfaction.com which has a juicy pagerank, a faceless Enomaly employee and some resistance to censorship.

Read full history - Boycott the Enomaly hoax and censored cloud-computing Google Group

Taxonomy: The 6 layer Cloud Computing Stack

Finally things have settled down enough that we can start making some sensible statements about the taxonomy of cloud computing. The Wikipedia cloud computing article(s) in particular are now fairly stable (after countless hours of work over the recent months) and the main one has climbed its way to the top of Google's search results for "cloud computing". New articles like the hours-old one on RightScale are slipping in to the cloud computing category tree nicely too.

Therefore, without further ado I am pleased to announce the 6 layer Cloud Computing Stack (developed and hosted on the brand new Cloud Computing Community Wiki) in all its Creative Commons Public Domain glory. You can use it however you see fit, commercially or non-commercially, under whatever license you want and you don't even need to give me credit for it. You can get it in SVG and PNG formats from the WikiMedia Commons, and if you've got the excellent OmniGraffle editor then I'll even send you the originals if you ask nicely.

The 6 layers of the Cloud Computing Stack (from top to bottom) are:

• Clients (examples) are computer hardware and/or computer software which rely on The Cloud for application delivery, or which is specifically designed for delivery of cloud services, and which are in either case essentially useless without it.
• Services (examples) (aka Web Service) are "software system[s] designed to support interoperable machine-to-machine interaction over a network"^[36] which may be accessed by other cloud computing components, software (eg Software plus services) or end users directly.
• Application (examples) leverages The Cloud in software architecture, often eliminating the need to install and run the application on the customer's own computer, thus alleviating the burden of software maintenance, ongoing operation, and support.
  
• Platform (examples) (aka Platform as a service) (the delivery of a computing platform and/or solution stack as a service) facilitates deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers
• Storage (examples) is the delivery of data storage as a service (including database-like services), often billed on a utility computing basis (eg per gigabyte per month)
• Infrastructure (examples) (aka Infrastructure as a service) is the delivery of computer infrastructure (typically a platform virtualization environment) as a service

This finds a happy medium in that it:

• Doesn't oversimplify like the aaSy 3 layer stack (SaaS, PaaS, IaaS)
• Doesn't overcomplicate like the all-inclusive 11 layer stack (remember cloud computing is about hiding the complexity of the Facilities, Network, Hardware, OS, Systems Management and Development Environment layers).
• Favours 'Application' (as in 'Web Application') over 'Software' (which can exist on the servers with SaaS and/or the clients with software plus services).
• Ignores things cloud computing users don't care about (most notably anything physical)
• Avoids altogether the overused 'as a Service' moniker, the characteristics of which (scalability, utility billing, no capex, etc.) are common and shared with cloud computing in general.
• Resists the urge to create new terms (neologisms) unnecessarily, opting for the simplest appropriate single word possible.
  

I hope that this work proves useful in understanding what cloud computing is all about and how cloud computing architecture works. I also hope that these terms take over from more complex, aaSy neologisms as they're clean, simple and they just make sense. Here's a translation table to get you started:

• Cloud Computer, Device, etc. » Cloud Client
  
• Web Services » Cloud Services
  
• Software as a Service, Software plus Services » Cloud Application
• Platform as a Service » Cloud Platform
• Storage as a Service, Cloud Attached Storage » Cloud Storage
• Infrastructure as a Service, Hardware as a Service » Cloud Infrastructure

Read full history - Taxonomy: The 6 layer Cloud Computing Stack

Cloud Computing: Bill of Rights (aka Ten Commandments)

I am pleased to share with you (at nearly 4am) the results of consolidating efforts by James Urquhart on his blog and Rich Wellner and I offline, by way of a draft of a 'consensus' Cloud Computing Bill of Rights or Ten Commandments available on the brand new Cloud Computing Community Wiki (http://wiki.cloudcommunity.org/).

This MediaWiki site was setup to facilitate tasks like this which are not suitable for inclusion in Wikipedia (which forbids such original research). It is fully open and you don't even need to create an account (let alone ask for permission to do so) in order to both read and write, making it significantly more accessible than existing efforts. The wiki is hosted by Dreamhost and the mailing list on a VPSlink VPS dedicated to the community and sponsored by my company, Australian Online Solutions. Not particularly 'cloudy', I know, but accessibility was the #1 goal.

If you have feedback, please comment on this post, on the article talk page or be BOLD and edit the article yourself!

http://wiki.cloudcommunity.org/wiki/CC:BoR

Cloud Computing: Bill of Rights

Preamble

The Cloud Computing Bill of Rights (CCBoR) (aka Ten Commandments) is a community consensus maintained document designed to protect the interests of cloud computing users.
We believe that users have certain rights when using resources on a cloud. Cloud computing is a powerful approach to sharing resources in a highly connected world and will succeed or fail on the basis of how that sharing takes place. In recognition of the growing value, be it financial or intellectual, of the work we will do using cloud based resources, providers and consumers must know the set of common assumptions they can make when engaging in this style of computing.
RFC2119 requirement levels are used throughout but for the sake of style all-caps are not used.

Roles

• User consumes the cloud computing service.
• Subuser consumes the cloud computing service sub-allocated by the User (eg Google Apps accounts)
• Provider delivers the cloud computing service to the user.

Definitions

• Data is the collection of organised information belonging to the user and their subusers, including metadata and configuration data
• Metadata is data about data, including tags, access control lists, content types, etc.
• Configuration Data is any and all data relating to parametrisation of the application(s)
• Transparent means machine-readable and represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic software

User rights

Auditing

1. Events must be securely recorded for an appropriate period depending on the needs of the user
2. Logs must be made available by download in a transparent format and optionally online
3. Monitoring beyond that required for service delivery be able to be opted out of

Billing

1. Itemised Invoices must be made available with sufficient information so as to validate the providers' claims
2. Limits must be able to be enforced so as to prevent runaway costs
3. Transparency is required in billing, in that a user should be able to calculate and anticipate usage
4. Usage Data (both current and historical) must be available to enable Users to monitor usage trends

Backups

1. Bulk Access shall be provided to all user data (including metadata and configuration data)
2. Frequency of access shall not be unreasonably limited (eg >30 days)
3. Redundancy should be built into the systems such that user data is protected against loss
4. Transparent formats shall be used, except where the user explicitly stores opaque data

Data

1. Encryption of data shall be facilitated where feasible and never unnecessarily hindered
2. Integrity of data should be maintained (exception is data processing where data is easily replaced by user)
3. Licensing as necessary for delivery of services (eg hosting) is acceptable with explicit permission
4. Metadata and configuration data (eg settings) is included
5. Ownership is retained by the user along with all associated rights (eg copyright)
6. Purging of data as required, including immediate, permanent and secure purging if necessary
7. Subusers' data is included (eg Google Apps users have multiple accounts, SalesForce users have customer accounts)

Interfaces

1. Availability of Application Programming Interfaces (APIs) shall be maintained for accessing and manipulating data
2. Change control shall allow for all API changes to be notified well in advance# Documentation shall be made available online in open standard formats
3. Existing standards shall be used (eg REST)
4. Superseded versions of APIs shall be available for a reasonable period

Legal

1. Conflicts of interest shall be revealed to the user (eg where sponsorship has affected platform choice)
2. Contracts shall use clear and easy to understand contract language, striving for the fewest surprises
3. Termination of service agreements without penalty must be possible in the event that Terms of Service changes are not acceptable to the User
4. Warrants shall be defended and notified to the user according to a set of published policies, except where forbidden

Location

1. Exact Location need not be provided beyond the smallest significant jurisdictional boundary (eg state, country, union of states)
2. Location of systems and data shall be made available to users
3. Selection of an appropriate location based on user preferences shall be provided where feasible (price may vary according to local conditions)

Security

1. Access to systems must be available in a secure fashion (eg appropriate authentication and transport layer security with appropriate ciphers)
2. Administrative Requests be handled using secure processes resistent to social engineering (eg identity verification, proof of control of domain)
3. Confidentiality of user data must be maintained
4. Multitenancy be strictly enforced such that no user can access or modify the data of any concurrent, former or future user

Service

1. Advertising shall match service levels and price points (eg never advertise a high service level at a low price point and demand a premium) and service delivered shall match expectations
2. Alternative service levels may be offered to the customer and priced accordingly
3. Availability shall be maintained by vendor according to prevailing Service Level Agreements
4. Expenses accrued in maintaining the service levels shall be borne in full by the provider
5. Subusers service levels shall be the responsibility of the User; subusers may or may not be assisted by provider

Standards

1. Innovation should not be impaired by forced adoption of standards
2. Open Standards should be used where appopriate standards are available

Acknowledgements

• Sam Johnston prepared this document based on existing efforts and contributed to it
• James Urquhart refined a draft document over a number of blog posts
• Rich Wellner contributed a pre-prepared draft document for incorporation

References

1. DreamHost Newsletter – July 2008
2. Amazon S3 Storage Now Available In Europe
3. Google Apps Domain Verification
4. The Cloud Computing Bill of Rights
5. Update: The Cloud Computing Bill of Rights

Read full history - Cloud Computing: Bill of Rights (aka Ten Commandments)

Enomalism vapourware lands Enomaly in the cloud computing doghouse

Update: Refer to Boycott the Enomaly hoax and censored cloud-computing Google Group post.

Many of us have heard about the overhyped Enomalism "Elastic Computing Platform" vapourware; indeed I've even been enthusiastically monitoring its (extremely limited) progress since shortly after its "creation" (as in "inception" rather than "release") in 2005 by small Canadian outfit [An] Enomaly, during which time I was working with Xen at Citrix (pre-acquisition). These guys, specifically founder and 'Chief Technologist' Reuven Cohen (a web developer from the school of hard knocks, which would explain where all the pretty graphics and marketing-speak comes from) claim to have invented 'elastic computing' way back in 2004, despite not bothering using the term right up until Amazon popularised it with the 2006 EC2 beta. They also bought us gems like 'Virtual Private Cloud' (Update: since deleted as non-notable, unverifiable original reasearch), a long string of dead and dying start ups and 'alliances' and even claim to have a 'vibrant community' with 12,000 list members (when there's ~150), 40,000+ downloads (but not according to SourceForge, who apparently didn't do their research before declaring it project of the month last month) and 1,000 beta testers (of which only ~20 have bothered to download the latest release candidate archive - probably about half of which were me trying unsuccessfully to get the thing to run).

Anyway, depite my purist view of cloud computing as 'Internet ('Cloud') based development and use of computer technology ('Computing')' I appreciate that there is benefit to be derived from the next generation of virtualisation outside the cloud (which is something different altogether) and my interest in Enomalism (and other similar projects like Eucalyptus) was recently renewed following a flurry of announcements about a long awaited and severely overdue stable release. It was only after doing some more digging that I noticed some anomalies with Enomaly and I am disappointed to concede that in my opinion:

Enomaly's Enomalism vapourware is all smoke and mirrors; nothing more than an elaborate hoax.

Not one to make a bold statement without justification, Wikipedia defines vapourware as a product "announced by a developer well in advance of release, but which then fails to emerge after having well exceeded the period of development time that was initially claimed or would normally be expected for the development cycle of a similar product". I originally made the connection because Wikipedia's article on Enomalism was linked to the vaporware article shortly after its creation (Update: the article was since speedy deleted as non-notable spam following in the footsteps of the articles for Enomaly and its owner, but you might still catch it in Google's cache) but I'm not the first to accuse it of being a mockup or hoax.

How did Enomalism (now at 2.1 RC1 Release 3) even get past 1.0 without so much as a single stable release?

Enomalism 2.1 RC1 Release 3's arrival last week (inexplicable release numbering aside) begs this question. Given the 'beta' 1.0 release in May 2006, how is it that the 2.0 releases in March and April 2008 were alpha and "should be used at your own risk"? Since when is a major 'point zero' release [pre]-alpha or beta quality anyway? Even more disconcerting, why are new files and features being added and 'massive code cleanup and refactor[ing]' being done in a release candidate? And how can a release which doesn't even start be 'considered STABLE in terms of applicability to a production environment' (Update: since redacted, see cached copy)? Having a "quintissential professional" lead developer "decid[ing] to upgrade TurboGears on the eve of the release of two... TWO major projects" (after which "all hell broke loose" leaving them "with enterprise applications without SSL support, which is a non starter any way you look at it") certainly helps. Giving up on 1.x prior to release to rebuild from the ground goes a long way towards explaining this too, and the Wikipedia article (created by Enomaly themselves in a blatant conflict of interest) admits that "development has progressed through multiple proof of concepts, alpha releases and finally beta releases. Stable releases are expected to be completed by August 2008". So here we are, having patiently waited three years while being fed press releases, screenshots, videos, flash tutorials, mockups, keynotes, podcasts, alphas, betas, blogs, blogs, blogs, blogs, blogs, more blogs and all manner of other guff, but still with nothing concrete. All promises, no delivery; talk without action; bark without bite.

The last straw came last week when one of the most interesting features (Amazon EC2 support) was pulled...

...and they started talking about it in the context of defining a cloudbursting functional spec. That's right, starting a functional spec for a heavily advertised feature! If nothing else 'cloudburst' (real meaning: 'an extreme form of rainfall, sometimes mixed with hail and thunder') has to be one of the single most ridiculous pieces of technical jargon I've heard in years, and one that's far more appropriate in the context of acute overloaded cloud failures. More to the point, it's exactly this (now indefinitely missing) feature that has garnered a good deal of the (apparently unwarranted) buzz around the product; without it one may as well stick with a mature, proven solution like VMware Virtual Infrastructure or competitive projects like Eucalyptus which are actually producing results.

There's nothing to see here... move along... to Freenomalism? Eucalyptus?

Initially I thought the project could be saved by forking it as Freenomalism (and I may still do so if Enomalism ever sees the light of day) but as I still haven't managed to get even the most recent releases up and running properly even on clean installs of a number of different Linux releases it seems it would be easier to start from scratch. After all, a lot of the heavy lifting is done by TurboGears and libvirt anyway and calls for help have gone unanswered for years and even filing tickets hasn't worked for those who've bothered to try amongst the 500+ spams. In any case lots of work has been done on stabilising the packaging which is now available for inclusion Enomalism if they want. Furthermore, despite being 'open source' the source code logs are concealed, the sporadic pushes to the SourceForge tree are uselessly tagged 'SVN Autocommit' and trying to get their attention via the SourceForge project is futile too. Fortunately I'm not getting the kernel panics others reported but the first time I tried it was (foolishly) on a remote server which instantly dropped off the network for days after uttering its last words: 'Configuring Virtual Bridge on eth0 IP 192.168.10.180...'

It's worth mentioning that I had good reason to do some background research. My recent post (cached copy) to one of the larger cloud computing Google Groups announcing Cloud User Shell (cush) (a free, open source prototype and the first cloud computing shell) made it through the invisible moderation net but information about its mailing lists was silently redacted and an off-list invitation for "Moderator <cloudmoderator@gmail.com>" (later found to be Khazret Sapenov, Director of R&D at Enomaly) to participate in the list management rudely rejected. When I requested that he "please add a few of the other active community members to [help] administer it" citing that "long blackouts are extremely disruptive" he childishly and silently evicted me from the group, deleted me from the member list, updated the FAQ to read 'This group is moderated...at moderators personal discretion', and worst of all, silently and inexplicably deleted the announcement from the archives. Furthermore, in a stunning display of hubris they have hidden the member list even from members and infringed copyright by retrospectively relicensed the group posts under a Creative Commons license with neither notification nor permission!

Repeated requests to rejoin were denied and as the #3 poster at the time I reached out to Reuven, calling for "an unfettered communications channel which is open for anyone to join and post, and which is not dependent on (nor able to be held hostage by) any one person". Reuven conceded that Khazret was his employee and that this "rather fascist approach to its moderation" was a "recurring theme", adding that he "would love to have [me] involved in [his!?!] cloud book". He promised to take care of it the following week (but didn't) and repeated calls for them to open up the community have gone unanswered. Of course they claim this is an extracurricular activity but it's hardly a basket weaving group, rather a massive conflict of interest directly related to their core [in]competency. Did this heated debate about the private cloud oxymoron really end here for example? Your guess is as good as mine. I guess by now he knows where he can stick his cloud book (which completely misses the point of cloud computing and looks dead already anyway), but more on that later... I'm not one to talk about problems without offering solutions but in the mean time I need someone (ideally another original member) to forward the group mails (don't worry, we'll strip any identifiable headers) over to(Update: Position filled, thanks) there's a new, open community currently in development (which you can already join by mailing members-subscribe@cloudcommunity.org).

Anyway this is just my opinion... you've now got all the information you need to make up your own mind. I'm sure Reuven's a nice guy (I'm yet to meet him but will surely cross paths eventually) and he's clever enough to have made it this far. On the other hand it seems this reality check is apparently long overdue and they can't say this wasn't hard earned, nor that they weren't warned and given ample time to pull their heads in.

Here's a laundry list of how Enomaly can get themselves out of the doghouse (which they currently unsurprisingly share with their partner, Nirvanix) having gone to such great lengths to get into it:

• Stop engaging in conversations about things we don't need
• Stop wasting our time with blather about vapourware
• Stop announcing features which never materialise (like Google AppEngine support, announced within 24 hours of its release and never heard of again - we've been under NDA with Google since 2006 and we didn't even find out about it until everyone else)
  
• Stop trying to hijack cloud computing to sell "I can't believe it's not cloud" wares
• Stop bragging about meeting "completely clueless" VCs until one of them bites (and even then only so we can rib them for proving you right)
• Stop building robots, hacking your coffee machine, and reviving horror fiction search engines at the 11th hour when you should be writing code
  
• Secure your software (which currently wants to insecurely download and execute code from all over the place, among other things)
• Stop price gouging (eg by adding a web interface and charging 300% and 500% markups for Amazon Web Services storage and compute respectively - although this is marginally better than CPU scavenging I guess)
• Stop infringing copyrights (by treating others' IP as your own and releasing it under Creative Commons licenses, violating the GPL, etc.)
  
• Stop cybersquatting
• Stop trying to censor the community
  
• Quit with the underhanded, dirty tricks like deleting competitors' releases (especially those for free, open source software in the true sense)

Above all, prove your critics wrong by releasing secure, stable software in a timely fashion (this month perhaps?), particularly if you want to have any hope of being "the Apache of cloud computing, the preferred platform for anyone looking to create scalable, multi-tenant, hosted applications".

Otherwise who knows, maybe cloud computing will be powered by an army of monkeys after all...

Update: Removed photos at Reuven's behest.

Read full history - Enomalism vapourware lands Enomaly in the cloud computing doghouse

Privacy and cloud computing

There has been a good deal of talk of late on the important topic of security and privacy in relation to cloud computing. Indeed there are some legitimate concerns and some work that needs to be done in this area in general, but I'm going to focus today on the latter term (indeed they are distinct - as a CISSP security is my forte but I will talk more on this separately):

Privacy is the ability of an individual or group to seclude themselves or information about themselves and thereby reveal themselves selectively.

Traditionally privacy has been maintained by physically controlling access to sensitive data, be it by hiding one's diary under one's mattress through installation of elaborate security systems. Access is then selectively restricted to trusted associates as required, often without surrendering physical control over the object. In a world of 1's and 0's it's a similar story, only involving passwords, encryption, access control lists, etc.

Occasionally however we do need to surrender information to others in order to transact and as part of everyday life; be it to apply for a drivers license or passport, or subscribe to a commercial service. In doing so we hope that they ('the controller' in European Union parlance) will take care of it as it were their own, but this is rarely the case unless economics and/or regulations dictate:

Externalisation leaves the true cost of most breaches to be borne by the data subject rather than the controller; the victim rather than the perpetrator.

Currently even the largest breaches go relatively unpunished, in that corporations typically only face limited reputational damage and (depending on the jurisdiction) the cost of notifying victims, while the affected individuals themselves can face permanent financial ruin and associated problems. According to the Data Loss Database, only days ago arrests were made over 11,000,000 records copied by a call center worker, and the hall off shame is topped by TJX with almost 100m customer records (including credit card numbers). Often though the data is simply 'lost', on a device or backup media which has been stolen, misplaced or sold on eBay.

Personal information has similar properties to nuclear waste; few attributes are transient (account balance), most have long half-lives (address, telephone) many can outlive the owner (SSN) and some are by definition immutable (DoB, eye colour).

In an environment of rampent consumer credit being foisted on us by credit providers who have little in the way of authentication beyond name, address and date of birth these losses can be devastating. This imbalance will need to be leveled by lawmakers (for example by imposing a per-record penalty for losses that would transform minor annoyances into serious financial disincentives), but this is tangential to the special case of cloud computing, rather serving to give background into the prevalent issues.

Cloud computing is relatively immune to traditional privacy breaches; there is no backup media to lose, laptop based databases to steal, unencrypted or unauthenticated connections to sniff or hijack, etc.

The fact is that many (likely most) of these breaches could have been avoided in a cloud computing environment. Data is stored 'in the cloud' and accessed by well authenticated users over well secured connections. Authentication is typically via passwords and/or tokens (we even have a prototype smart card authentication product) and encryption usually over Transport Layer Security (TLS), centrally enforced by the cloud applications and cloud services. A well configured cloud computing architecture (with a secure client supporting strong authentication and encryption) is a hacker's worst nightmare. Granted we still have some tweaking to do (eg the extended validation certificates farce) but the attack surface area can be reduced to a single port (tcp/443) which is extremely antisocial until it is satisfied that you are who you say you are (and vice versa).

A well configured cloud computing architecture is a hacker's worst nightmare. Conversely, a poorly configured cloud computing architecture is a hacker's best dream.

On the other hand, one of the best ways to keep information safe is not to collect it in the first place; by consolidating the data the reward for a successful attack increases significantly. Fortunately the defenses typically improve at least proportionally, with vendors (whose businesses are built on trust) deploying armies of security boffins that an individual entity could only dream of. The risk is similar to that of a monoculture, the same term that has been used to describe the Windows monopoly (and we have seen the effects of this in the form of massive distributed botnets); the Irish can tell you why putting all your eggs in one basket is a particularly bad idea.

In summary the potential for enhanced privacy protection in a cloud computing environment is clear, provided the risks are properly and carefully mitigated. We are making good progress in this area and overall the news is good, but we need to tread carefully and keep a very close eye on the spectre of ubiquitous surveillance (Big Brother), large scale privacy breaches and targeted attacks.

Cloud computing has the technology and many of the systems in place already; now it is up to the lawmakers to step up to the plate.

Read full history - Privacy and cloud computing

The Cloud Computing Doghouse: Nirvanix (aka Streamload aka MediaMax aka The Linkup)

Although Dell have been denied the ill-fated cloud computing trademark (that's lowercase please. hold the ™) and moved on to more interesting things, they're yet to concede defeat and withdraw their application. Even though the double decker bus has disappeared from the moon, that leaves us with 6 months of uncertainty before USPTO consider it abandoned, during which time they can appeal the decision. Although it is generally accepted that they would have a snowball's chance in hell of succeeding, I would have preferred they take it out the back and put it out of its misery, and they can stay in the doghouse until they do (or it expires).

On the other hand there's a backlog of crass acts of stupidity in the cloud computing space so they're going to have so shove over and make room in the doghouse for someone (or something) new; the inaugurating member can't monopolise it forever. And who better than a 'new' company associated with "the meltdown of an online storage service that will leave about 20,000 paying subscribers without their digital music, video, and photo files": Nirvanix.

First and foremost (given they have apparently threatened to sue one of their own founders) this is an opinion piece based on what little information I have been able to scratch together from various online sources - draw your own conclusions and do your own research before you rely on anything here. It is more a commentary on one of the inherent but easily mitigated risks of cloud computing - unreliable providers - than on Nirvanix itself.

Let's start with some background and basic maths:

Today you can buy a terabyte (1Tb) hard drive with a 5 year (60 month) warranty for $150 retail single unit quantities. Meanwhile the going rate for cloud storage is about $0.15/Gb/month. Ignoring complications like formatting losses, servers (which are cheap and can host many drives), bandwidth, etc., simply by wiring these up to the cloud one could get a return on investment in a month ($0.15 x 1000Gb/m = $150) and over the life of the $150 drive you can make a whopping $9,000.

Admittedly a gross simplification, but to remote users looking down relatively narrow pipes it can be very difficult to tell the difference between a cheap desktop hard drive and an expensive enterprise SAN (that run at about $20/Gb/year, over an order of magnitude more expensive than cloud storage). At least it is until the thing loses their precious 1's and 0's, in which case you hope it was run (or at least backed) by a large storage vendor from redundant datacenters rather than a long haired 16 year old from his basement. Herein lies the problem; presumably Nirvanix/Streamload/MediaMax/The Linkup (or whatever they're calling themselves today) fall somewhere between the two extremes (hopefully the former rather than the latter), but it's hard to tell where.

If the various articles (especially this one) are to be believed, the whole sorry saga goes something like this:

• Steve Iverson (a uni student at the time) develops "adaptive data compression algorithms" for his thesis in 1998
• Shortly after graduation he founded Streamload to "easily and securely send, store, move, receive and access their digital files"
• By 2005 Streamload was hosting about half a petabyte (425Tb) of data for "well over 20,000 users"
• Streamload was rebadged (after receiving some investment) to Streamload MediaMax™ (as distinct from MediaMax, Inc. which did not exist at the time) on the DEMOfall 05 stage as "a suite of ultra-high capacity online services that helps you manage, share, and access all the files and digital media in your life."
• However by December 2006 it was losing money and Patrick Harr (current Nirvanix CEO) replaced Steve (with his blessing) as CEO and Steve became CTO. After 60 days assessment the new CEO "advocated letting it 'gracefully die' and creating a new company selling 'cloud' storage to paying enterprise customers".
• Disaster struck on June 15 2007 when "a Streamload system administrator's script accidently misidentified and deleted 'good data' along with the 'dead data' of some 3.5 million former user accounts and files"
• Two weeks later Streamload's board of directors pressed on with Harr's strategy and "split the company into two independent businesses. Streamload changed its name to Nirvanix. It kept many of the former company's physical assets [including all the servers and data] and employees, and secured $12$18 million in initial venture funding."
• Meanwhile "The MediaMax consumer product and its disgruntled customers went to Iverson as CEO of a 'new' business" along with "only about $500,000 in working capital" while Nirvanix managed to scratch together a cool $18m from the likes of Intel.
  
• After a botched upgrade to MediaMax v5 (which by Steve's own admission introduced a bunch of features users didn't want) they changed their name again to The Linkup which was marketed as "a social networking site based around storage", only to also botch the migration to 20% more expensive (at $5.95/$11.95 per month) paid-only services.
• Users of the free service were given three weeks (which was extended due to problems with the 'mover' script) to upgrade or permanently lose their data. Curiously the data was the whole time stored on Nirvanix servers and was being migrated to their new enterprise Storage Delivery Network.
  
• Late July Nirvanix Clarifies False Information in Blogosphere in a blog post buried in their developer site.
  
• MediaMax/The Linkup closed its doors on 8/8/08, having given users 30 days notice to retrieve their (remaining) data.

As at today the various angry masses are waiting for Nirvanix to give them access to (what remains, apparently about half of) their data, which Nirvanix assures us "remain[s] secure in the old Streamload/MediaMax storage system" (although it is not clear whether the files migrated to The Linkup were not deleted 8 days after the 8/8/8 closure). They also claim "access to those files requires the MediaMax application front-end and database" (roping SAVVIS, who apparently maintained the frontend, into the fray) but MediaMax claim to have offered it to them, noting that "if they could have got the files back, they would have". Steve goes on to say:

Fundamentally, MediaMax is responsible because you are our customer, and the biggest mistake we made was to trust Nirvanix to manage our customer data - yes, it was on the “old Streamload system”, and not their new Nirvanix SDN, but I believe the care and attention that was required was not there and was beyond unprofessional.

Here's where it gets really interesting. In Nirvanix's own words:

Are Nirvanix Inc. and MediaMax Inc. the same company?

No. Nirvanix and MediaMax split out of the same company, Streamload, Inc. in July 2007. Each company would be independently formed with separate ownership, oversight and investors. The companies were subsequently split off in July 2007 and have been separate and distinct entities since that time.

Did Nirvanix delete user data?

No, Nirvanix has not deleted any customer data.

Did a storage problem occur at Streamload?

As documented on the MediaMax blog in July 2007, a storage problem did occur at Streamload on the Streamload/MediaMax storage system in June 2007. This occurred prior to the formation of Nirvanix Inc. and was completely independent of the Nirvanix Storage Delivery Network which was not launched until October 2007.

The problem with these denials, and in particular the claim that the mass deletions at the start of the death spiral "occurred prior to the formation of Nirvanix Inc.", is that it conflicts not only with what investors, ex-partners, users, etc. say but also with the California Secretary of State, who list Nirvanix, Inc. as a "merged out" California corporation (C2111900) filed on 15 June 1998 (conveniently the exact same month Streamload was founded; almost a decade before they claim it came into existence) and as a Delaware corporation (C3051094) filed on 16 October 2007. Incidentally MediaMax, Inc. (C2998020) was filed earlier, on 16 May 2007. In case you're wondering what "merged out" means (despite having to learn all this as CAcert's Organisation Assurance Officer I had to look it up too), here's the definition:

The limited partnership or limited liability company has merged out of existence in California into another business entity. The name of the surviving entity can be obtained by requesting a status report.

Thus it appears that Streamload, Inc. changed its name to Nirvanix, Inc. which then "merged out" of existence in California, "into" Nirvanix, Inc. (Delaware)... the corporate equivalent of moving house (it would be good if someone in the US could get a status report to confirm).

A murderer changing her name after the crime and then claiming immunity on the grounds that it happened before she existed would spend the rest of her life in jail.

Even if they were a different legal entity as claimed they still appparently have the same staff, same 525 B Street, San Diego address, even the same CEO (which I'll bet a judge would find interesting). If they are one and the same then is it not actually Nirvanix, Inc. who still has a binding contract with all those customers (at the very least least the ones who didn't migrate to The Linkup)? Did the original Streamload terms allow for a transfer from StreamloadNirvanix to MediaMax? Did the customers agree? Indeed, was it not then a StreamloadNirvanix system administrator who ordered the deletion of the data? (Update: According to a comment MediaMax claim it was, which reconciles with the dates above.)

So why have Nirvanix thus far managed to escape culpability in the form of public (PR) execution and class action lawsuits? This appears to be no accident, rather the result of a sustained [dis]information campaign. For example, most of this information is from the Nirvanix article in Wikipedia which was recently nominated for deletion, apparently by Matthew Harvey at JPR Communications (Nirvanix's PR firm) who already blanked it twice before being blocked for doing it a third time as a sock puppet. Jonathan Buckley (Nirvanix's Chief Marketing Officer) also weighed in with a Strong Delete vote (that was largely ignored as a conflict of interest) and the article was unsurprisingly kept and remains to give a voice to the disenfranchised masses. They have also apparently been fairly active with the bloggers, calling their posts "inaccurate and libelous", a post by an investor "suspect and untrue", again claiming "Nirvanix was not even incorporated in June of 2007", and you can bet there's plenty more going on that we don't hear about (Update: including press censorship, astroturfing and blaming the victims, claiming they "are all software pirates and porn addicts").

The more cynical reader could be forgiven for believing that this was planned (but I think it was more a case of incompetence and gross negligence):

• Develop interesting technology
• Build reputation by servicing users for free
• Get millions in investment
• Float said users off on a leaky liferaft with $1 in $37 ($500k for MediaMax vs $18m for Nirvanix), and the inventor himself
  
• $$$Profit$$$
  

Why do I care? I don't particularly (at least not about this specific situation) but like the rest of the fledgling cloud computing industry I do find articles that could have been easily avoided (like "Storms in the cloud leave users up creek without a paddle") difficult to swallow. I've never used their services and I don't compete with them; if anything I may end up recommending them to my consulting clients if they are the best fit for a problem. I do however feel for the 20,000 or so people who lost irreplacible photographs, video, music and other data through acts that can only be described as gross negligence; as a long time professional system administrator I find occurances like the June 2007 accidental deletion extremely hard to accept. The story of a disenfranchised inventor having been parted with his invention is oh-so-common too. Finally, I just don't like coverups:

Trust is (for now) an essential component in cloud computing infrastructure and victims of outages, data loss, privacy breaches, breakins, etc. have every right to full transparency.

Were this another storage provider (eg Amazon S3) there would have been a clear demarcation point (the APIs) and it would have been possible to demonstrate that the client either called for the destruction of data or did not. Accordingly, immutable audit logs should be maintained and made available to cloud computing users (this is not always the case today - often they are kept but not accessible). There should also be protection against accidental deletions (in that they should not be immediately committed unless purging is required and requested, eg to satisfy a privacy policy or other legal requirement). Nirvanix notes that (for the SDN at least) "at any point during this eight-day [deletion] process, the file can be fully recovered" and other providers have similar checks and balances (this is almost certainly why you can't recreate a Google Apps user for 5 days, for example).

So where to from here? If Nirvanix do have the data as they claim, then they should stop the 'internal' bickering and do everything within their power to get as much of the property (data) as possible back to its rightful owners, or give a full and transparent explanation for why this is impossible. If they are in fact the same legal entity the users contracted with initially (Streamload, Inc., as appears to be the case) then they should take responsibility for their [in]actions, apologise and offer a refund. That being the case, customers should hold them to this, both directly (info@nirvanix.com or 619.764.5650) and with the help of organisations like GetSatisfaction.com, Better Business Bureau or if necessary, the courts.

In the mean time they can stay in the doghouse, with Dell...

Read full history - The Cloud Computing Doghouse: Nirvanix (aka Streamload aka MediaMax aka The Linkup)