King Ludd #21: Your Multi-device Christmas Nightmare

Why festive cheer shouldn't be contained to the data centre

cabin cabin

It’s now officially the run up to Christmas, and with that the slow but inevitable accumulation of wrapped up gadgetry can commence under King Ludd’s festive tree. Sadly, we know it’s all downhill from here. Attempting to actually use these things is just going to end in tears.

One obvious example is if you are cursed enough to receive a modern games console. It’s almost certain that it will need the operating system patching out of the box, then the games themselves will need patching (or worse, downloading outright) and the combined mass of you and ten million others (let’s be optimistic for the manufacturers here) doing this at once will invariably cause the respective services to go offline for several hours rendering your new toy useless. This is predictable enough that any parent giving their child a console that does not patch it before wrapping it is just asking for trouble, or deliberately trying to teach their child the importance of patience in a particularly sadistic manner.

And this is just one device at the easy end of the spectrum. An idealist like myself, that believes there’s no good reason for this nonsense and it should all just work, finds plenty of reason to be grumpy.

The main problem here is that developers are so bad at dealing with distributed state. This is the apparently simple question of keeping track of if a light bulb should be on if it’s connected to multiple switches. Currently the popular way to resolve this problem is to keep track of the state of the light in the data centre, and connect all the switches and the light to the data centre. This is why so many apparently trivial things require cloud services.

The irony of this is that developers have to deal with such nasty problems within data centres, as they are themselves composed of hundreds or thousands of machines, but they have a sort of mental block when it comes to applying the same principles outside of them. If the light switches and bulb are smart enough to come to a conclusion among themselves (which is what is going on in the data centre) then . . . you don’t need the data centre.

This isn’t helped by the complete lack of development support for this idea. There is an awful lot of noise about code reuse across different form factors, but it ignores the key problem: it’s the state that needs to be shared, not the code. This is why the Microsoft “Windows Everywhere” strategy has proved so uneventful, as it just doesn’t help. If, however, your Windows Phone, WinRT tablet, and Windows 8 PC had a development system that simplified live synchronization of state between those devices in real time without the cloud then things would be a lot more interesting.

This is why the argument “Why the data center needs an operating system” misses the point. The data and consistency problems are not to be resolved merely within the safe confines of the data centre, but extend outwards to all devices.


Nigel Birkenshaw runs Atomirex and he spells centre the correct way.