OK, this post is about virtual machines in the JVM sense, not in the hypervisor sense. (The lines are getting a little blurry these days though.)
Back in the day, I once installed Windows NT on an RS/6000 (PowerPC) just to play with it. (It's funny how obsolete/impractical technology seemed so interesting back then, and these days it boggles my mind how anybody could care about Haiku, Amiga, etc.) So Windows NT: it installed OK, I started it up, and ran IE 2.0. That sucked (even at the time), but there were no updates for it. I ran the bundled Pinball game. That was the end of the story, because there was no ISV support. Just porting the kernel wasn't enough: an x86 WinNT application still couldn't run on PowerPC WinNT. The same fate could befall ARM netbooks (ahem "smartbooks").
This post suggests that .NET could be the answer. It starts by assuming that ARM netbooks will be common (a question on which the jury is still out), and then assumes Microsoft will somehow want to participate in that ecosystem (probably a safe bet: look at Windows ME on phones). Port some Windows kernel to ARM netbooks, provide a .NET runtime, and then just run .NET applications -- never worry about needing native ARM Windows binaries.
That has an existing parallel of course: J2ME on mobile phones. As a consumer, I'd call that a success. I love that I can download a random Java application and not worry about if the creator has built it for N phone vendors x M models. I'm sure J2ME has its limits, but it has made my life better.
And of course Google is walking down the same path with Dalvik. The cool thing about Java/Dalvik/.NET that it might just allow another processor architecture to compete with Intel without the legacy software issue. It will be interesting to see if Intel eventually enables Java on Moblin.
With Intel investing so many resources not just into the Linux kernel, but now into a full mobile Linux distribution (complete with UI), maybe Microsoft will annoy them right back by enabling ARM netbooks. You know both of them have to be looking to embedded systems for growth.
Anyways, I'd only buy a netbook that runs Linux. ;) I've heard good things about the ARM instruction set...
29 May 2009
15 May 2009
Oracle buys another hypervisor?!
Oracle made headlines for two acqusitions in the past month, Sun and Virtual Iron. By my count, that makes them the proud owners of no fewer than four x86 hypervisors: Oracle VM, Sun's xVM Server, Sun's xVM Desktop (a.k.a. VirtualBox), and Virtual Iron. (I've never really understood why Sun had two.) All but VirtualBox are based on Xen.
Even with this surprising success in the game of "collect the Xen implementations," that still leaves at least Red Hat, Novell, and of course Citrix itself offering competing Xen solutions. I'll admit the Unix wars predate me, but that seems like an impressive degree of fragmentation. Still, Red Hat has announced plans to abandon Xen for KVM, and even Novell included KVM as a tech preview in SLES11. There's no question that the number of Xen-based products is about to significantly shrink.
I've even seen one person speculate that the cost of maintaining Xen is so high, that with Red Hat pulling out, Oracle must have been worried about strengthening their Xen development capabilities.
What's worse though is that each of those Oracle hypervisors has its own management stack. Systems management is one of those areas that sounds really easy, but in practice never is. Management software contains so many layers that it's hard to find anybody who actually understands the end-to-end details of a particular code path. You need translation layers for components that are too old, too new, or fit at a different layer, or written for a different management stack. In this case, you might find one management stack built on xm, another built on libvirt, another built on CIM (and "enterprise frameworks" are a whole other world of complexity). Do they use OVF for image files? Should they? Every design question has tradeoffs and requires serious consideration.
Speaking from experience at a large company, I expect there will be at least 6 months of churn while architects furiously scribe presentations, rearrange block diagrams, create hypothetical development sizings, establish migration plans for legacy customers, escalate issues to management (which will be sorting itself out too), find and get input from related organizations ("how does this affect our relationship with VMware?"), and in general figure out what they're doing. After all the dust has settled, they'll still need to write the code.
Will the eventual result of this consolidation be a stronger Xen ecosystem a few years from now? To be honest, I couldn't care less... but it could be worth the cost of a bag of popcorn.
Even with this surprising success in the game of "collect the Xen implementations," that still leaves at least Red Hat, Novell, and of course Citrix itself offering competing Xen solutions. I'll admit the Unix wars predate me, but that seems like an impressive degree of fragmentation. Still, Red Hat has announced plans to abandon Xen for KVM, and even Novell included KVM as a tech preview in SLES11. There's no question that the number of Xen-based products is about to significantly shrink.
I've even seen one person speculate that the cost of maintaining Xen is so high, that with Red Hat pulling out, Oracle must have been worried about strengthening their Xen development capabilities.
What's worse though is that each of those Oracle hypervisors has its own management stack. Systems management is one of those areas that sounds really easy, but in practice never is. Management software contains so many layers that it's hard to find anybody who actually understands the end-to-end details of a particular code path. You need translation layers for components that are too old, too new, or fit at a different layer, or written for a different management stack. In this case, you might find one management stack built on xm, another built on libvirt, another built on CIM (and "enterprise frameworks" are a whole other world of complexity). Do they use OVF for image files? Should they? Every design question has tradeoffs and requires serious consideration.
Speaking from experience at a large company, I expect there will be at least 6 months of churn while architects furiously scribe presentations, rearrange block diagrams, create hypothetical development sizings, establish migration plans for legacy customers, escalate issues to management (which will be sorting itself out too), find and get input from related organizations ("how does this affect our relationship with VMware?"), and in general figure out what they're doing. After all the dust has settled, they'll still need to write the code.
Will the eventual result of this consolidation be a stronger Xen ecosystem a few years from now? To be honest, I couldn't care less... but it could be worth the cost of a bag of popcorn.
Subscribe to:
Posts (Atom)