thoughts on computing

This is part of an ongoing series of posts in which I’ll present ideas developed in Executive’s Guide to Cloud Computing. Hope that you find these useful.

Moore's Law (Kurzweil's Extension)

Moore’s Law has long been a friend of all in the computing biz … after all, with no particular direct action by most of us all of our lives tended to get better, faster, and cheaper … perhaps in fits and starts, but over time the effects are undeniable.

Yet this progress has not been uniform, and now those realities are beginning to make themselves known – beyond a shadow of doubt – in ways that we are only now beginning to appreciate.

One Small Example
For example, it’s been more than five years since the power of an individual cpu has basically topped out, leading to the advent of multiple cores. Repeat after me: two, four, six, eight … all of these we do appreciate (sorry, couldn’t help that one much – probably comes from coaching so much baseball and softball!).

Still, while multiple cores certainly solved a problem for the silicon vendors to keep upping the ante, there are some very definite consequences to the limitations.

For starters the multi-core phenomena has really put the pressure on software developers … individual applications have to become sophisticated enough to handle multiple threads of execution well (albeit with the simplification of a physically shared memory). Absolutely anyone who has spent much time writing, debugging, or supporting multi-threaded code can attest to the plain reality that this is significantly harder than the more common.

But Wait There’s Moore
Turns out that the multi-core folks are basically constrained by their ability to get data onto and away from the physical chip – from the CPUs themselves. In other words, the total I/O bandwidth on / off the chip is a very serious design constraint, one of which many very smart folks are struggling against mightily.

Yet that is not the most serious version of this problem facing us today. Our basic inability to move  as much data as we want (bandwidth) as quickly as we want (latency) is even more onerous as manifest at a macro level. In particular, move up several levels of abstraction from the chip to the cloud … particularly clouds constructed out of aggressively commoditized infrastructures.

(For the rest of this discussion we’ll focus on bandwidth, and cover latency effects another time.)

What’s happening at the cloud level is that there is a real mis-match in the rate of improvement in three basic capabilities;

• Processing power (multi-core or otherwise)
• Storage capacity
• Network / interconnect bandwidth

This is true both individually and in aggregate.

In other words, we are not able to get data from increasingly large storage pools to and from increasingly powerful processing pools quickly enough … and the problem is getting worse, much worse.

@Beaker (Christopher Hoff) brought out the same point in a very good post yesterday. From that post:

… there is an underlying assumption that the networking that powers it (the cloud) is magically and equally as scaleable and that you can just replicate everything you do in big iron networking and security hardware and replace it one-for-one with software in the compute stacks.

The problem is that it isn’t and you can’t.

That, of course, is a great point.

Johhny Cochran the Geek?
Later in the post he riffs a great line

Abstraction has become a distraction.

Funny, except that I’ve drawn a different conclusion from the same facts. Namely, that abstractions (no matter how cool, complete, or sophisticated) still have to run on actual, physical stuff … and that actual, physical stuff matters … a lot.  Or said another way

Abstractions are great, on infrastructure they must wait.

So not as catchy as Beaker’s, but I think it makes the point ok.

The simple reality is that raising the levels of abstraction is essential to creating real cloud-native apps. While that is primarily a job for the cloud app platform, it cannot – must not – ignore the infrastructure on which it operates (physical or virtual).

What Then Can We Do?
So that seems to leave us between the proverbial rock and a hard place –  customers demand apps that scale, data and application architectures are morphing to enable an entirely new grade of scale, infrastructure operations are getting way better and thereby enabling scale, access is becoming far more ubiquitous thereby driving the need for scale, commodity is becoming far more so which thereby enables … well, do you see the theme? Scale, scale, scale … and the network isn’t keeping up with any of this, and can’t.

It just can’t. Not now, not tomorrow, nowhere into the foreseeable future, and for that matter probably never. Ever.

Yet a solution to this connundrum is beginning to emerge.

I believe that these macro-level forces will lead to is an inevitable merging of the storage and computational pools in many physical infrastructures, and that merging will tend to become the norm rather than the exception.

In other words, SANs … no thank you.  NAS … here and there. But for the big stuff a fundamentally new approach, one that is very, very cloud-native, and one to which we are surprisingly close.

In Part 2 I’ll examine at least one way this merger can occur and consider some of the consequences.