X

Moore's Law vs. the cloud

There's still a lot of work needed to figure out what clients should look like in a cloud computing world.

Gordon Haff
Gordon Haff is Red Hat's cloud evangelist although the opinions expressed here are strictly his own. He's focused on enterprise IT, especially cloud computing. However, Gordon writes about a wide range of topics whether they relate to the way too many hours he spends traveling or his longtime interest in photography.
Gordon Haff
3 min read

We've been hearing a lot about thinner client devices of late. Netbooks are a hot topic, whether or not they're really a distinct category of device. I've wondered if there might not be a role for a sort of ebook-on-steroids. And Google's Chrome OS, pitched for a browser-centric world, had the digerati all in a flutter a few weeks back.

A lot of this activity reflects a general move away from software that is locally installed and run on a traditional PC to software and services housed on servers out on the network--in the cloud, to use the lingo du jour. It's enabled in no small part by increasingly pervasive networks including wireless ones of various kinds.

However, although cloud computing tracks improvements in networks, it doesn't necessarily sync up so cleanly with the parallel improvements going on in computers themselves. As a commenter put it in a recent post of mine: "The thing that I don't understand about the move to "cloud-based services" is that it seems at odds with Moore's Law. Specifically, devices are going to have more & more processing power, disk space & memory - why would you want to offload processing to the cloud?"

This is a deceptively deep comment and one that touches a lot of basic architectural questions about how we will run software and where we will run it.

One thought is that we're not really running counter to Moore's Law. Rather, we're moving the increased number of transistors that Moore's Law gives us from the client to the server. We're making clients thinner (and therefore more portable, cooler, and so forth) and the servers fatter.

There's some truth in that with mobile phones perhaps offering the clearest illustration.

But, for more notebook-like clients there's a lot of processor and graphics horsepower on the local computer that's going to waste much of the time. And, in any case, telecommunications infrastructure places hard limits on bandwidth for a given time of place, but we can dial up and down our local compute horsepower by selecting devices with different characteristics. So it makes more sense to favor local processing much of the time.

In fact, the fundamental thing that thinner clients and cloud computing tackle isn't really the movement of computing off the client but rather the movement of "state" off the client--which is to say data, applications, and customizations specific to a given user.

As a practical matter, most clients still store some amount of state. In the days of  old, terminals didn't store anything locally. Sun's Sun Ray line comes closest to replicating this experience in modern thin clients. However, even browsers store cookies and can be configured with extensions and plug-ins that will vary from one installation to the next.

And, for most purposes, this is probably a reasonable enough state of affairs. Our personal devices are personal anyway; we just want to get away from having to load and manage custom software for each individual task that we want to do. Shared, public clients are a different matter, of course. However, in this case, a lowest-common-denominator software load (such as a browser) is typically sufficient.

There is clearly a lot  of work left to do and battles, both technical and political, left to fight to arrive at the best architectural models and programming practices for this new generation of client-server computing. For example, do "rich Internet applications" live in the browser a la Microsoft's Silverlight or is a separate framework such as  Adobe's AIR a better approach? Where do .NET and Java fit in?

These (and many others) are not small questions. Application writers need to understand at a very granular level the environment for which they're writing. And there is very much a tension between richness of the client experience and the degree to which we can standardize and simplify that client.