In my mind, “a cloud” is a distributed service, where each component of the cloud is different. Data gets duplicated across nodes in the cloud, but even still, no two nodes are exactly identical. Your access client figures out which node to speak to for a given request/response cycle, and will talk to different nodes for different requests. Of course, in real-world examples, the cloud may be “fronted” by a row of identical cache servers or whatever, but they’re just a refinement of the implementation, as opposed to critical to it’s core function.

GMail (or Hotmail, Yahoo! Mail, or Facebook, Twitter, Google/Yahoo/Bing search, or umpteen other examples) are really just single-point web sites. Sure, behind the web pages you see there may be huge, complex infrastructures, but ultimately, they’re single point of entry. The provider may have taken their infrastructure and doubled it up so that if one fails, the other takes over, but essentially, both components are identical.

If you take redundancy away from both models, you end up with essentially the same thing you started with. A cloud is still a distributed “every node is unique” sort of infrastructure. If you take one node away, you lose a bit of your data, but the basic service (and your application) continues.

A web site is just a series of machines collaborating to fulfil a common purpose. If you take one of those machines away, some part of the application will fail (which may include data loss). Just because someone else runs those machines for you doesn’t make them “a cloud”.

So whilst the article’s points about centralised management and human errors in complex implementations are all valid, I’m not sure the example of GMail is anything more than “whoever is running your services for you might make a mistake, even if they’re a third party that you think are great”. I don’t think it’s valid to extend that into our choices of technological paradigms.