Next-generation mobile is all about the cloud

[bimo]

"Cloud" has a special place in my hit parade of despised neo-techno-vernacular. Unlike Web 2.0, my all-time favourite, at least "cloud" is somewhat self-descriptive: Formless, vaporous, and a semi-reliable indicator of climatic conditions. If you point at a round, puffy cloud and declare that it looks like a pitchfork, and someone with you nods and says, "Cool, I can see that", the forecast is mostly patronising, with zero vision and periodic sucking up. You're in trustworthy company if that person says, "Are you blind?". If someone in a meeting refers to a cloud, or worse still, the cloud, don't nod just to keep the conversation going. Consider it your duty to ask them to define the term.



Whenever I can, I tackle buzzwords head on by unilaterally issuing a concrete definition. I've decided that a cloud is a hosted data store equipped with omniscience and omnipresence, aware of every movement and able to land anything from a stream to a droplet of data on a moving target with faultless precision and efficiency. A cloud assures guaranteed intact delivery of arbitrary payloads, autonomous, simultaneous, and network-agnostic synchronisation of an unlimited number of clients, immediate sensing of a client's presence after a period of non-availability, real-time notification of new data, intelligent handling of fragmented and out-of-order payloads, optimal use of low-speed and unreliable connections, continuous retry persistence, periodic reports of delivery failures, and end-to-end acknowledgement of successful delivery.

When I send information to this cloud I've defined from my desktop or mobile device, either explicitly by sending email or implicitly by making a change to my schedule, I get a real-time acknowledgement that the cloud has received the data. I can then take for granted that the cloud will blanket the globe to find all client devices interested in that information, push the data to them simultaneously, and verify that it reached them intact. If the cloud can't locate a client, it obsesses until that client pops up on radar. When it does, the cloud assumes that connectivity to the client is fickle and fragile (with mobile connections, it often is). It hurriedly delivers at least a fragment of everything in the queue, because if I'm only in sight of the cloud for a few seconds, I'd rather see the first 50 words of all the messages waiting for me than one message with a 1MB attachment, and nothing else until that message is fully transferred. It takes a cloud to do that.

If someone tries to sell you a cloud that doesn't meet most or all of these requirements, tell them for me that they'll have to call it something else. If someone designs a cloud to my specifications, tell them that I screwed up their shot at a patent.

I haven't seen anything meeting that description made available to commercial users as a packaged service from anyone but RIM. The BlackBerry delivery, presence, and notification infrastructure is not regarded by its users to be a cloud. It's just BlackBerry; the capabilities of the infrastructure define the device. A BlackBerry handset is a proprietary terminal for a commercial cloud. Take away RIM's cloud, and a BlackBerry becomes a PDA with a very slow browser.

RIM's cloud is heavy on immediate notification and reliable delivery of short messages and light on services. Even though every BlackBerry has calendar and contacts applications, they are only synchronised over the air if you have an in-house or hosted back end with BlackBerry Enterprise Server (BES) plus Exchange, GroupWise, or Domino/Notes. BES enriches RIM's cloud by letting other data and notifications hitch a ride on it. Oh, go up and add extensibility to my definition of "cloud". I didn't put it in because I take for granted that any commercial-grade solution is extensible via published APIs and protocols.

The BlackBerry infrastructure is not a perfect cloud. It is optimised for low latency rather than large payloads. As the payload size rises, delivery can't be guaranteed. You can use RIM's cloud as a gateway to the internet, but messaging and notification take precedence, so browsing performance and reliability are abysmal.

Businesses need a cloud that strikes a happy medium between low notification latency and high-speed data transfer. Steve Jobs pitched the original iPhone with Yahoo push mail as "BlackBerry for the rest of us", and Apple marketed its MobileMe service using a cloud logo, and at one time, Apple used the tag line "Exchange for the rest of us". iPhone's Yahoo push email was DOA, perhaps a victim of Apple's romance with Google (unconsummated at the time). Still, iPhone 2.0 with MobileMe could have been a model for a RIM-like infrastructure fleshed out with a suite of services.

If MobileMe were stabilised and sold as a cloud for iPhone users, it would pass muster by consumer standards and make a fair model for a more ambitious commercial service. It does work: If you have two iPhones with active cellular data connections, messages sent between them via MobileMe are indeed pushed. There is a delay of several seconds between sending and delivery. Attachments are retrieved on their first viewing. It works out reasonably well unless you're out in the sticks where even EDGE won't reach. That's BlackBerry territory. RIM's cloud will shove the first 250 characters (or whatever the worst-case limit turns out to be) of your messages down single bar, receive-only cell data links. That's core to its design. MobileMe and iPhone aren't so obsessed with universal delivery. BlackBerry's cloud is of the slow and sure variety, while Apple's waits for a clearer shot and blasts those big, fat, desktop-generated messages to you in one stream. It's a matter of preference.

My preference would strike a balance between the two. When I'm in a cellular ghetto, I want to see some sign, at least a notice that my queue is backing up because I haven't seen a tower for the past ten minutes. Cellular Short Message Service (SMS) and cell broadcasts work even when TCP service isn't available. I want my cloud to send whatever it can, as long as my device drops it in my inbox.

One unavoidable catch of living in a cloud is that it requires proprietary client software. Standard-issue messaging and PIM clients use server polling and session-oriented protocols for broad interoperability, firewall friendliness, and cheap implementation. A cloud client has to be aware of the specific notification method used by the cloud, be able to route payload data to applications that understand how to process them, and queue outbound messages for reliable delivery over unreliable networks.

That's well outside the mandate of OS X's Mail.app, Windows' Outlook Express, open-source desktop alternatives and most smart phone/PDA mail clients. New mail appears in your garden-variety client's inbox when your client makes its 10 or 30 minute rounds, regardless of the means used to send it. You might try to play the system by setting your client's polling interval to one minute, but IT deals with this all the time. If it doesn't enforce policies on mail client polling, it can impose connection rules that keep you from abusing the server. If you don't have a push client, you're out of the cloud.

But let's not think about that. One cool thing about clouds is that they are inherently interconnected. An iPhone-to-iPhone message is delivered more or less immediately through MobileMe. A message sent from my iPhone to my BlackBerry shoots from Apple's cloud to RIM's like lightning. iPhone and BlackBerry are full cloud peers with regard to email. Similarly, if I add one of my ActiveSync-equipped, Exchange or Windows Live-connected Windows Mobile handsets to the recipient list of the message I send from my iPhone, the Windows Mobile handset will receive it in seconds rather than minutes. This isn't the result of a secret pact among Apple, RIM, and Microsoft (as if). It isn't cloud-to-cloud notification, although that will come when users demand it. Any push-capable client is a maximum of two cloud hops away from any other push-capable client. Mail servers that serve push clients deliver or relay inbound messages immediately rather than holding them in a queue that is processed at intervals.

As always happens when I set out to bring meaning to some fuzzy word, I end up concluding that whatever it is, if people need it, the technology or concept won't need a separate term to define it for long. Once you have clouds notifying clouds and private sub-clouds within public or enterprise clouds, there is no cloud, just peer-to-peer messaging. There are adaptable standards for rapid re-establishment of broken authenticated TCP connections, multi-channel streams to support interleaved notification during payload transfer (if we stay in a one socket per client model), and transparent reliable delivery. There are standards covering address book and calendar data representation and handset/desktop synchronisation. All of the ingredients needed to make a services-rich global cloud are in the public domain. It's a matter of shedding the legacy baggage of clumsy session-oriented protocols and transports that were optimised for dial-up and time-metered networks. Clients would have to get smarter, but commercial users are already there. Cloud? What cloud?