What’s up with BlackBerry? (Not much, and not for long, it appears)
My wife mentioned to me that she wasn't getting email on her BlackBerry Curve the other day. After some time of struggling (I don't use one of those annoying devices, myself; I currently use a Palm Pre Plus), I finally managed to get the service books re-sent to the device, and while monitoring our email server, saw an IMAP connection come up (albeit quite slowly, spending what seemed like an eternity selecting a folder). I doubt that sending service books really made much of a difference, unless something broke when RIM got things propped up again (temporarily).
The next day, I read several reports online about some massive problem at RIM, in Canada. The Register is now replete with stories of what appear to be ongoing problems up there:
BlackBerry BBM, email downed in epic FAIL - October 10
BlackBerry users back online after outage - October 11
BlackBerry BBM, email offline AGAIN - October 11
BlackBerry services splutter back into action, again - October 11
RIM stands, staggers, falls again - October 12
BlackBerry stumbles to feet, full of apologies - October 13
This morning, my brother couldn't get email on his BlackBerry Bold (well, no mail since 11:30 or so last night). To me, all of this speaks volumes about the whole "let's run to the Cloud" argument. Like Big Government, Big Networks are doomed to topple under their own weight. Why doesn't my Pre Plus suffer from such problems? Because the device itself connects to my mail server and pulls messages via IMAP, just as any other mail client would. What makes BlackBerry devices so susceptible to problems such as this? Because RIM connects to my mail server as an IMAP client, and then must push the data back down to the device. Even if there is no problem with the cellular carrier, if RIM can't pull or push, you're out of luck.
Even BlackBerry Enterprise Server users are not immune to such issues, as BES still must connect to RIM's network for so many things. This article covcers much of the gory details of this phenomenon.
Take it to the Cloud? What, are you kidding me?
Last Updated on by
October 14th, 2011 - 15:23
Lewis, I think your cloud argument is a bit of red herring in this case. Yes I agree that the blackberry setup introduces an unnecessary single point of failure. However, your IMAP server lives “on the cloud” and there are other single points of failure accessing your IMAP server. The server could die, the servers pipe could go down, the power to the data center could fail. Yes, all these things could be made redundant, but I’m sure RIM has generators, redundant switches, and multiple pieces of fiber going into their buildings.
I’m not currently a fan of blackberry. I do like blackberry messenger, and before android, I preferred blackberries to the iPhone and to Palm (which was my favorite phone before blackberry). I certainly never liked my data going to Canada, but accepted it as a trade-off to the single inbox UI.
Your analogy of big networks to big government is an interesting one, and one where I will agree. Size does have some benefits in terms of economy of scale in both cases. Being a large government means you can afford a large army, and you need the same number of engineers designing a new tank whether your making 10 of them or a thousand. Their are similar fixed costs in being a network provider. Where things fall apart when a carrier tries to be an email proxy or a government decides to do something not explicitly allowed in its constitution.
October 14th, 2011 - 17:07
At least a couple of the differences between RIM’s cloud and my IMAP service are actually quite clear:
When my IMAP server is cut off from the rest of the outside world, only a small number of people are affected;
Should my IMAP server go offline for an extended period of time, my subscribers can easily switch to another provider, without having to change hardware (i.e., they are not dependent upon any software I host to run the equipment which they own);
Should my IMAP server go offline, through the magic of DNS, I could pop up another IMAP server on another network backhaul in a couple of hours (in minutes, if I had the resources at my disposal) to run a mirror server, with all incoming mail held at a backup MX until that new server would come up. Granted, this was the way in which RIM’s system was supposed to work, but did not. However, I could just as easily have called one of my friends on the west coast and asked him to host the mail domains on my network until such time as my system came back. No old messages would be available in such an instance, but new messages would flow as usual.
In the case of RIM, nobody else is allowed to run their proprietary software; thus, they maintain a stranglehold on their customer base. This, I believe, is the real danger of ubiquitous cloud (or hosted – let’s call it what it is) services, where the ability to change providers either does not exist, or is made very difficult (how might an enterprise migrate away from Google Apps, after transferring a significant portion of their IP to that platform? See here, which outlines saving individual documents to various formats – not exactly a cost-effective way of migrating 30,000 spreadsheets to a usable format).
Insofar as getting to the cloud, obviously, we all suffer from the same limitations of whatever means of transport we have available. The difference is one of scale and portability, and ultimately, control over our precious data.
😉
October 16th, 2011 - 09:34
Lewis, I think you nail it with the stranglehold and control arguments. The tradeoff for hosting mail with google is a fairer trade then office suite because I can and do backup my email via thunderbird, and it would not be hard to make something more scale-able with fetchmail that would allow a flip of the switch migration (not withstanding DNS propagation issues). The only problem I see with fetchmail, is is doesn’t backup calendar and contacts, but those too are solvable problems, and I’m sure their are open source scriptable CLI tools for that.
BTW, I found an app that syncs google docs with MSOffice (http://www.labnol.org/internet/office/backup-and-sync-google-docs-files/5188/). You might want to look into that if you have clients that insist on using google docs, or as a solution to get them off of it when you show them the light.
October 16th, 2011 - 09:52
Thanks for the link, Justin! I wasn’t aware that there was anything to backup those files for offline access.
Calendar and contact backup is a typical problem for any platform, of course. Communigate uses IMAP folders for these, which is a more portable solution, if not particularly standard (and calendars can be exported as iCal). Getting contacts as LDIF or even XML requires some massaging after the IMAP download, so it’s anything but “instantaneously portable,” but at least it’s not some proprietary format.
Cheers