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 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.
The USPTO awarded search giant Google a software method patent that covers the principle of distributed MapReduce, a strategy for parallel processing that is used by the search giant. If Google chooses to aggressively enforce the patent, it could have significant implications for some open source software projects that use the technique, including the Apache Foundation’s popular Hadoop software framework.
Here are my initial thoughts (I plan on a more thorough post upon further reflection):
- This has potentially very profound implications for the rapidly developing world of “big data” application architectures.
- These “big data” problems are some of the key use cases for cloud computing adoption, public, private, or anywhere. One need look no farther than the rapid uptake of Hadoop and the growth of its community and ecosystem.
- Google has definitely done the most to popularize the notion of applying map and reduce operations to processing large sets of data.
- Having said that, the roots of this approach to data manipulation are very old in the history of computer science, from the earliest days of AI / Lisp / etc.
- Map-reduce is not the last word on big data algorithms, but it is an important one.
In short, big data problems are important to cloud computing, map-reduce are an important class of algorithms for some of these big data problems, and many people have put 2 and 2 together.
As for the patent and other implications,
- I have tended to favor some level of software patents – we have a couple ourselves – so I do think that there is a time and a place for patents, yet I also understand how easily abused software patents can be in the hands of … well, people who can abuse them.
- I have absolutely no idea how enforceable this patent could be … that is a much more complex question far better suited for those interested legal scholars and fine patent counsel out there.
- I have even less of an idea what Google intends to do with this patent. Will they benignly gift it back to the community, or twirl it around like some stealthy Sword of Damocles, always there but just outside of the ability of everyone else to perceive it’s precise power?
- As anyone who has ever participated (or even been near) a patent dispute understands, in most cases the value of the patent is directly proportional to the amount of cash to either prosecute alleged infringements or defend against said prosecutions, and
- Google has lots of cash (yes, yes, I realize that this is quite a revelation).
One more thing, and the importance of this is non-trivial- Google loves to portray themselves as “more open than thou”, with a very fine-sounding “do no evil” ethos that is repeated as a litany.
That is all and well so far as it goes, but what does that mean for absolutely everyone else who ever has or ever will use a promising set of basic techniques for a serious cloud app, or perhaps wants to innovate far beyond, but who happens to be outside of Fort Google?
One More Thing
I have been really surprised at the relatively low-key response to this patent award from the community.
When Dell famously received a trademark from the very same USPTO for “cloud computing” in April 2008 the hue and cry of the bereaved was astonishing … and effective. Within a week Dell had politely withdrawn the application, and returned the name to the community.
That was only a name.
This is far more significant, impacting the bounds and capabilities of real applications, and what do we hear so far … not much.
It’d be great to hear from others who care about the future of cloud computing in some way. There are so many aspects to this – legal, technical, operational, even psychological – all wrapped up into the idea of competitive positions, markets, and the future of cloud computing. So yes it’s a complex topic, but there may be some relatively simple answers.
Maybe Google needs look no further than Dell for some guidance on this one.
These are quick thoughts about a complex topic. Hopefully next week I’ll have a chance to reflect more deeply on this situation, see what develops a bit more, and then post further. This should be interesting.