King Ludd #13: What the Cloud Should Learn From Android
King Ludd Cabin
Watching the rise of the Docker project is quite exciting, and it represents a very valuable step towards the future for server component deployment, however, what is more potentially useful is layers that could be built on top of it, and one of the best sources of inspiration for these will turn out to be the mobile operating system Android.
The logo for the genuinely exciting docker project, simultaneously proving (along with others like Go) that a cute logo goes a long way.
To point out an obvious but under-appreciated fact, Android is a high availability Linux system for low power devices that requires a relatively low amount of system administration. (Relatively, because it still has the capability to radically confuse you as to just why the battery is flat when you woke up this morning). Ironically the mechanisms for how Android achieves this are inspired by 1980s research into distributed systems (internally even the terminology is the same), yet modern server software deployment seemingly hasn’t even learned the lessons of the 1970s.
Google’s Nexus 5: smartphone or high availability Linux deployment? It’s actually both.
The key thing about Android is that it enables service discovery and binding at runtime, and not just when the application is compiled. This means that applications can query for other applications that could provide them with services, and then connect to them for this. A conceptually simple example would be having a photo gallery application that other apps, such as a camera, can use to store photos. The user could swap either the photo gallery app or the camera one, and the two should in principle be able to continue oblivious to these changes, since they should speak a standard language of the messages travelling between them.
This idea originated many decades ago in research applied to early computer networks, where programs running on one computer could access a central service directory to look for programs running on other computers capable of performing their tasks for them. An example more familiar to a server developer would be writing a program that needs a database service to store the data it is handling, but the killer difference is more often than not the database service is not automatically discovered, yet configured in a tedious manual process highly specific to the deployment of that particular application, and this is why server devs can’t have nice things.
The future really has to be user managed apps running in the cloud, but if it requires the current level of sys admin monkey work, such as the classic database configuration, it’s not going to happen. The end user needs to be able to rent computer space, buy a database service encapsulated in a container and have it seamlessly provide data services to their other applications, in their own containers, that they’ve bought from other vendors. Those containers can discover the services running in the others automatically, so at most the user just has to confirm which connection to make. (Android users will be familiar with the occasional popup when multiple apps can fulfil a specific action and it’s up to you to resolve the confusion). And yes, in that future we have an app store of server side containers.
Back when cloud computing didn’t have a name and the network wasn’t really up to it some companies tried launching “Network Computers” which unsurprisingly bombed. Dilbert author Scott Adams satirised this effort in a cartoon characterising the machines as amazingly user friendly with just one button, and they push it for you before it leaves the factory.
So what’s needed to get there? It seems beyond the scope of a project like Docker itself, and instead will probably be some other entity leveraging that and similar work. Containers must be able to discover, connect to, and interchange messages with other components, based on a specification of what they would like to achieve. Android does this with the much lauded Intent mechanism, which while not perfect in the current implementation could be shored up significantly. Android applications create Intent objects describing what they want to do (and to what) and the operating system works out which application is going to handle it, launches the target application, and delivers the Intent object to it. This provides the exact mechanism mentioned earlier with the camera and the photo gallery.
If any Android developers made it this far they’re probably shaking their heads in disbelief right about now. The problem they will be concerned about is that the inconsistency between the messages understood by the photo galleries on two different phones can be absolutely insane. This is the justifiable end of the much discussed “fragmentation” problem with Android, while if you hear people whining about issues like screen size difference that really is just whining. The theoretical answer to this would be standardisation of the messages, though in the case of the photo gallery there is already a standard, it’s just needlessly complex and often poorly implemented. Many server devs will understand the general idea from the RDBMS world where superficially the language SQL is common to many databases, but in practise SQL for one will not work on another – the Android situation is nothing like as bad as that, not even close. The fact is fragmentation is going to be a developer headache in the future, and they’re just going to have to live with it.
The first real recognisable GUI and programming environment, Smalltalk, has late binding as a fundamental property of the system.
When thinking about these cloud based systems for non-technical end users we really are having to think about them in terms of running for a hundred years. I would fully expect a ten year old buying into a service in 2020 to have a continuous always running path through to 2100 in the same computing environment, with the underlying transitions in hardware abstracted away, and the late binding between applications and services enabling them to switch between these gradually over time, with minimal hard coded interdependencies ensuring that their whole system stays working when individual parts change. This is in stark contrast to how many developers work today, with systems such as Maven encouraging early strong binding between specific versions of vast numbers of software components, and the previous buzzterm “Service Oriented Architecture” mangled the concepts in a way typical of the enterprise world. That is what Alan Kay characterised as pyramidal style development, but pyramids are brute force, and things only really got interesting when people started building arches. The late binding of components is to the future of software what the arch was to architecture.
Nigel Birkenshaw runs atomirex. He can be reached at [email protected].
