Last Thursday, I sat in on an informal idea-session with some industry colleagues and, as a result, had the pleasure of meeting Tim Bray, currently at Sun Microsystems. Like most tech thought leaders, he was instrumental in drawing out of the group lots of ideas and opinions (sometimes to amusing effect). Somewhat expectedly, the topics of virtualization and cloud computing came up during the discussions. Like most in the industry I am fascinated to some degree by the still-untapped potential of each, albeit more so with the latter. The majority of my career has been spent with large institutional customers with sprawling heterogeneous data centers, all suffering from capacity fragmentation. All now use virtualization at some level. A subset of these also have employed a compute grid of some kind. In each case, the shortcomings have been almost as apparent as the significant benefits of each. In the case of virtualization, the impending virtual sprawl and being limited to merely “slicing up” hardware were some of the obvious drawbacks. With Grid, the proprietary nature of the APIs is what struck me most as a limiting factor. Notwithstanding the enormous benefits and game-changing ability of each technology (not to mention the claims of the leading vendors in the space), I am still left wanting by what exists currently (yes, techies are an insatiable bunch).
In the case of virtualization, I have often wondered what if the hypervisor model could invert itself. In other words what if it could also aggregate nodes into a cloud space while still offering the “commodity” image of an unmodified OS? Would this not be the “chocolate and peanut-butter” moment for virtualization and grid? While not to minimize the complexity necessary to accomplish such a thing (and my somewhat limited view into what it would involve), I can’t help but think that we should be close. Node-binding technologies are everywhere these days and many of them would play a role. Technology like Infiniband, and perhaps more specifically RDMA (with or without InfiniBand), I would think must be building blocks. We have clustered databases becoming mainstream such that I would imagine a cross-node, commodity-based hypervisor has to be in a lab somewhere.
I proposed this idea during the discussion last week and was a little surprised that the reaction from the group, while positive at times, was still somewhat mixed. That is until I fully understood the reasons for the alternate views. Essentially there was a suggestion that maybe the OS as we know it is not necessary to get to the next game-changer. I then modified my view somewhat to be a bit more inclusive. “Okay,” I said, “so what about a Java cloud?” That question was greeted a bit more positively. I was then taken back to a moment I had experienced with one of my customers about 18 months ago. I recall the look on his face when I had mistakenly suggested that Azul Systems was based on commodity hardware. It was the “let’s get it in a lab” look. You see, this customer had already looked at Azul Systems before and had essentially turned his attention elsewhere largely because it was based on “proprietary” hardware. Hearing the misleading suggestion that it had gone the “commodity” route had renewed his interest for another look (NB: use of quotes for both “proprietary” and “commodity” – these definitions can be philosophical rat-holes). If this customer could fire up a few nodes of his own to kick the tires, he would certainly divert resources to put the product through its paces. While one may argue whether the proprietary vs. commodity argument was a good enough one or not, there’s something to be said about wanting a low barrier to entry and not being tied to a single vendor’s hardware. What if there was a JVM that could work much the same way as Azul Systems’ JVM, except on hardware already existing in most data centers? Sure, you would still need some first-class engineering to get it right (as in the case of the clustered DBs) but think about the up-take in this case. Then imagine a service offering where you’re given your own slice of a JVM cloud (living on who knows how many nodes) and dropping your entire application, unmodified – web (e.g. Jetty), database (e.g. Derby) and whatever else it needs – into the Java cloud. You’d still likely need some JMX based services for management, some handle to your file system for your Java DB and other file-based content (ZFS might play a role here) as well as some encapsulation of how the network is exposed to you but if it were done right, such a service offering would be compelling. This is especially true when one also considers that a JVM is not just about Java anymore (as Tim pointed out by citing the DaVinci project). I would also imagine that since a cross-node JVM has already been made to work on one type of hardware, it should be possible to make it work on another (e.g. x86_64, Sparc CMT, etc.). I also can’t help but think that this might be easier to achieve than the “unmodified” cloud OS (again limited-view disclaimer applies – and by “unmodified” I mean that the dependent bits do not have to be recompiled to take advantage of the service).
So whether you believe the unmodified cloud OS or the unmodified cloud JVM are the next real game-changers (I see roles for both), or you believe in something entirely different on the horizon, it would be great to hear from you.