Monthly Archives: January 2012

How Some Journalists Confuse People About Cloud

Simon Wardley and I had a quick exchange about the sloppily written and factually inaccurate writing of Wired’s Jon Stokes. Simon commented about a November post on Wired CloudLine as follows:

@swardley:  “This Wired post on cloud from Nov ’11 – where it isn’t wrong (repeating unfounded myths), it is tediously obvious –”

I piled on and Simon posted about another post here.

@swardley: “Oh dear, another of the wired author’s articles – – is so full of holes, well, no wonder people are confused.”

Stokes replied here.

@jonst0kes:  “@cloudbzz @swardley And I’d like to think that one of you could write a real takedown instead of slinging insults on twitter.”

Challenge accepted.

Let me just start by stating the obvious – When a respected editor like Stokes at a very respected zine like Wired puts up crap, misinformation and rubbish, it just confuses everybody. If very knowledgable people like Simon Wardley are calling bullshit on someone’s weak attempt at journalism, then you can bet that something is not right.

Wired Cloudline Post by Jon Stokes – “An 11th Law of Cloudonomics

Stokes:  “Don’t build a public cloud–instead, build a private one with extra capacity you can rent out.”

I’m sorry, but if you’re renting out your cloud, it’s public – so you’re building a public cloud and you better damned well know what you’re getting into. Anybody who has a clue about building clouds knows that there are tremendous differences in terms of requirements and use cases – depending on the cloud, the maturity of your ops team, and a whole bunch of other factors. Yes, you can build a cloud that is dual use, but it’s rare and very difficult to reconcile the differing needs. I know of only one today – at it’s in Asia, not in the U.S.

Stokes: “If you look at the successful public clouds—AWS, AppEngine,, Rackspace—you’ll notice that they all have one thing in common: all of them were built for internal use, and their owners then opted to further monetize them by renting out excess capacity.”

Garbage!  Amazon’s Bezos and CTO Werner Vogels have repeatedly disputed this.  Here is just one instance that Vogels posted on Quora:

Vogels: “The excess capacity story is a myth. It was never a matter of selling excess capacity, actually within 2 months after launch AWS would have already burned through the excess capacity.”

Rackspace built their public cloud as a public cloud, and never had any internal use case that I can come up with (they’re a hosting company at their core – what would they have a private cloud for internally??). For private clouds, they actually use a very different technology stack based on VMware, whereas their public Cloud Servers is built on Xen. But again, their private clouds are for their customers, not for their own internal use.

Stokes: “It’s possible that in the future, OpenStack, Nimubla, and Eucalyptus will create a market for what we might called “AWS clones”—EC2- and S3-compatible cloud services that give you frictionless portability among competing clouds.”

Eucalyptus is the only stack that is remotely an AWS clone – and that’s how it started as a project at UC Santa Barbara. OpenStack is based on Rackspace and NASA Nebula – not AWS clones – and Nimbula is something built by former AWS engineers but is also not a clone. There are some features that are common to enable federation, but that’s hardly being a clone (we call it interoperability). And none of them give you frictionless portability between each other.

Stokes: “In that future, we could see a company succeed by building a public cloud solely for the purpose of making it an AWS clone.”

Huh? That’s about the least likely scenario for success I could dream of. If all I do is build an AWS clone to compete against Amazon with its scale, resources and brand, then I’m the biggest moron on the planet. That would be total #FAIL.

Stokes: “…attempts to roll out new public clouds and attract customers to them will fail because it’s too expensive to build a datacenter and then hang out a shingle hoping for drop-in business to pick up.”

Generally I agree with this, but not for the reasons Stokes gives. Most cloud providers don’t need to build a data center. You can get what you need from large DC providers (space, power, HVAC, connectivity) and build your cloud. But you need to have a reason for customers to consider your cloud, and the idea of “build it and they will come” is a truly lame strategy. I don’t know a single cloud provider today that is operating on that model.

Stokes: “And most cloud customers are drop-in customers at the end of the day.”

Most startups might “drop in” on a cloud. But most enterprises certainly are more mature than that. You don’t drop in on IBM’s cloud (which is pretty successful), or Terremark’s or Savvis’s. Gartner MQ upstart BlueLock is (a) not even remotely an AWS clone, (b) having really great success, and (c) does not want or allow “drop-in customers” at all (you need to call them and talk to a sales rep).

Going forward I expect better from Stokes and the folks at Wired.


(c) 2011 CloudBzz / TechBzz Media, LLC. All rights reserved. This post originally appeared at You can follow CloudBzz on Twitter @CloudBzz.


PaaSing Comments – Data and PaaS

I’ve been looking at the PaaS space for some time now.  I spent some time with the good folks at CloudBees (naturally), and have had many conversations on CloudFoundry, Azure, and more with vendors, customers and other cloudy folks.

Krishnan posted a very good article over on CloudAve, and at one level I fully agree that PaaS will be come more of a data-centric (vs. code-centric) animal over the next few years.  To some degree that’s generally true of all areas of IT – data, intelligence and action from data, etc.  But there is a lot more to this.

Most PaaS frameworks have very few actual services – other than code logic containers, maybe one messaging framework, and some data services (structured and unstructured persistence and query).  You get some scale out, load balancing, and rudimentary IAM and operations services.  Over time as the enterprise PaaS market really starts to take off, we may find that these solutions are sorely lacking.

In the data and analytics space alone there are many types of services that PaaS frameworks could benefit from:  data capture, transformation, persistence (have), integration, analytics and intelligence.  But this is too one-dimensional.  Is it batch or realtime, or high-frequency/low-latency?  What is the volume of data, how does it arrive and in what format? What is the use-case of the data services?  Is it structured or unstructured? Realtime optimization of an individual users’ e-commerce experience or month-end financial reporting and trend analysis?

Many enterprises have multiple needs and different technologies to service them.  Many applications have the same – multiple data and analytical topologies and requirements.  Today’s complex applications are really compositions of multiple workload models, each with its own set of needs.  You can’t build a trading system with just one type of workload model assumption.  You need multiple.

A truly useful PaaS environment is going to need a “specialty engine” app store model that enables developers to mix and match and assemble these services without needing to break out of the core PaaS programming model. They need to be seamlessly integrated into a core services data model so the interfaces are consumed in a consistent manner and behave predictably.

Data-centricity is one of the anchor points.  But so is integration.  And messaging.  And security in all it’s richness and diversity of need.

This gets back to the question of scale.  Salesforce has the lead, but they also have a very limiting computational model which will keep them out of the more challenging applications.  Microsoft is making strides with Azure, and Amazon continues to add components but in a not-very-integrated way.  But will a lot of other companies be able to compete?  Will enterprises be able to build and operate such complex solutions (they already do, but…)?

This is a great opportunity and challenge, and I have great expectations that we will be seeing some exciting innovations in the PaaS market this year.


Cloudy Implications and Recommendations in Megaupload Seizure

The FBI seized popular upload site yesterday.  They took the site down and now own the servers.

I am not an attorney, and I have no opinion on whether or not the MegaUpload guys were breaking laws or encouraging users to violate copyrights through illegal uploading and streaming of movies, recordings, etc.  Right or wrong, the FBI did it and now we need to deal with the fallout.

The challenge is that there were very likely many users who were not breaking any laws.  People backing up their music, photos, websites, documents and who knows what else.  I highly doubt any large corporations would want to use such a site, but I bet a lot of small businesses did.  My focus here is on the ramifications to the enterprise, and how to protect yourself from being impacted by this.

What if the offending site was using Amazon, Google or Microsoft to store their bad content?  I’m sure that the Feds would have had no problems getting the sites shut down through these companies without needing to resort to taking them offline.  But legally could they have gone in and seized the AWS data centers?  Or some of the servers?  Maybe legally, but perhaps not easily for both technical and legal reasons (Amazon has lots of money for lawyers…).

What if the cloud provider was someone smaller, without the financial ability to challenge the FBI?  I mean, those guys usually don’t call ahead — they just bust in the door and start taking stuff.  The point is that IT needs to take some steps that protect themselves from getting caught up in an aggressive enforcement action, legitimate or not.

Recommendations to IT

  1. Stick with larger, more legitimate vendors that have the ability to square up with the Feds when necessary – not that will stop them but it could slow them down enough to let you get your data
  2. Encrypt your data using your own keys so that even if your servers get taken, your data is secured (of course, that’s just a good idea in general)
  3. Back up your data to another cloud or your own data center.  Having all of your eggs in one basket is just stupid (and that goes for consumers who are more likely to just trust a single backup provider like Carbonite (who stated in their S1 offering docs that they expected to lose data and that the consumer’s PC was assumed to be the primary copy!)

Feds, Please Consider Doing it Differently

Perhaps we need some legislation to protect the innocent legitimate users from the enforcement fallout caused by people who are clearly breaking laws.  I don’t understand why, for example, the FBI could not have copied off all of the files, logs, databases etc. but left the site running.  Even watching the traffic that occurred after the announcement could have given the FBI some interesting insights into some of the illegal usage.

Bottom Line – protect yourself because this is a story that could be coming to your preferred cloud someday.

Tagged , ,
%d bloggers like this: