Cloud computing and the big rethink: Part 1
Chris Hoff, my friend and colleague at Cisco Systems, has reached enlightenment regarding the role of the operating system and, subsequently, the need for the virtual machine in a cloud-centric world.
His post last week reflects a realization attained by those who consider the big picture of cloud computing long enough.
He summarizes his thoughts nicely at the opening of the post:
Virtual machines (VMs) represent the symptoms of a set of legacy problems packaged up to provide a placebo effect as an answer that in some cases we have, until lately, appeared disinclined and not technologically empowered to solve.
If I had a wish, it would be that VM's end up being the short-term gap-filler they deserve to be and ultimately become a legacy technology so we can solve some of our real architectural issues the way they ought to be solved.
Hoff goes on to note that the real problem isn't the VM, but the modern operating system:
The approach we've taken today is that the VMM/Hypervisor abstracts the hardware from the OS. The applications are still stuck on top of operating systems that don't provide much in the way of any benefit given the emergence of development frameworks/languages such as J2EE, PHP, Ruby, .NET, etc. that were built around the notions of decoupled, distributed and mashable application "fabrics."
My own observation here is that our current spate of operating systems were designed when competitors were pushing to use the OS as a differentiator--a way of distinguishing one company's product experience from another. OSes started out being targeted at software, providing a way for applications to use a generalized API to acquire and consume the resources they needed.
At the time, computers had one CPU and the logical thing to do was to design a single OS that could run multiple applications, preferably at once. This created the need for additional functionality to both manage resources and manage the applications themselves.
Furthermore, the operating system increasingly targeted not the needs of software, but the needs of people; more specifically, the needs of computing buyers. Take a look at OS X, or Windows, or even "enterprise" Linux distributions today. The number of features and packages that are included to entice software developers, system administrators, or even consumers to consume the product is overwhelming.
However, any given application doesn't need all those bells and whistles, and most OSes are unfortunately not designed to adjust their footprint to the needs of a specific application.
So, the problem isn't that OS capabilities are not needed, just that they are ridiculously packaged, and could in fact be wrapped into software frameworks that hide any division between the application and the systems it runs on.
By the way, that this is exactly why EMC purchased Fastscale last month, as noted by Chuck Hollis, EMC's CTO of global marketing, on the day the acquisition was announced. Simon Crosby, CTO of the data center and cloud division at Citrix, also notes that this change is coming but sees the OS playing a more important transitional role.
This is a critical concept for application developers wondering how cloud computing will affect software architectures. It is also a critical concept for why IT operations professionals need to understand that their roles and responsibilities are changing.
Because of this, I'll be following up with a few posts this week that will expand on this concept and give you much more of a sense of why the operating system, along with most server, network, and storage virtualization is a stop-gap measure as we move to a cloud experience centered on the application user and the developer.
Next on the list is an explanation of why cloud computing drives infrastructure toward homogeneity (at least within a data center) and why that is the bane of server virtualization.
James Urquhart is a seasoned field technologist with almost 20 years of experience in distributed systems development and deployment, focusing on service-oriented architectures, cloud computing, and virtualization. James is currently market manager for the Data Center 3.0 strategy at Cisco Systems, though the opinions expressed here are strictly his own. He is a member of the CNET Blog Network and is not an employee of CNET. 
Naturally, I think this is a great post :-)
We've fallen into the habit of calling these legacy-OS-free environments "compute clouds" for no other reason that we needed a descriptor. Maybe you and maybe Hoff can come up with a better term?
We also think that the pathway lies in newer forms of application development where the abstraction is sufficiently high that legacy OS concepts aren't seen. A popular example of this is Ruby on Rails (or the more enterprise-appropriate Groovy on Grails from SpringSource).
Develop an application in one of these environments, and -- not only will you develop more efficiently and have a better app -- but you have the potential to end up with an application that is cloud-ready and not tied to legacy operating systems, databases, file systems, etc.
As many have pointed out, the transition will be gradual and measured. Fortunately, the hypervisor can play a role in both camps -- bridging the legacy to more cloud-like models, and serving as an idealized platform for legacy-free application environments.
The discussion can get a bit deeper, if you're up for it :-)
-- Chuck Hollis
I think you are a little confused on what exactly cloud computing is. The term is a very accurate descriptor and was not chose arbitrarily or for a lack of a better word.
I believe the point of this article was to touch on the poor mechanics used in today's cloud computing and the hope for, what the author believes to be, much needed advancements.
This seems to be the crux of the issue. Previously attracting people to develop on your platform meant sprawling features and options--but that is contrary to true industrialization.
So put simply--how will future solutions balance between broad developer and deployment attractiveness and underlying industrial efficiency. One bet is a more atomized and specialized world, where DB, storage, others are more services than stacks. But that has big limitations.
Oh well back to the control spectrum question you always raise very well. TBD.
It also has another great benefit, it is a greener form of cloud computing requiring smaller data centers, less bandwidth usage and the execution of application directly on the client processors (fewer server round-trips and faster user response times). Its powered by a small XML Virtual Machine that is pushed to the run-time memory of your browser from icloud.com and then is used to run the icloud XML OS. It implements the higher levels of a traditional OS, including file system, multiple application instance support, inter application communication and user interface. Most notable more effecient development API's and data synchronization capabilities accross multiple clients (collaboration).
Read more in my Linux Magazine article:
http://os.icloud.com/v1/links/12884901897/2325
Daniel Arthursson, CEO
Xcerion / icloud.com
- by meh130 October 1, 2009 7:52 PM PDT
- One thing to consider when considering how virtualization affects operation systems. Most assumptions in this area assume a VM or virtual server instance which is running one, single threaded, or minimally threaded application. Somehow, I think certain OS functions, like network stacks and process schedulers, will continue to be critical for higher powered middleware applications (like IBM WebSphere or Oracle WebLogic).
- Like this Reply to this comment
-
(7 Comments)A Java appserver can handle hundreds of threads per instance. A large Nehalem EX system, with 64 hardware strands, could be carved into eight, 8-strand VMs. These would be roughly equivalent to the typical dedicated deployment platforms of the past for J2EE appservers. Run a transactional web platform like an E-Commerce site on one of these VMs, and you could easily support dozens of simultaneous transactions, each spawning many threads. Here you need an OS (even a JEOS), with robust multithreading support and effective thread scheduling. Even more, you really need an OS which can behave well in a guest environment.
If I were VMware, I might try to figure out how I could create a JEOS platform which could intelligently and securely communicate with the hypervisor so as not to create thread scheduling or virtual memory conflicts. If I were Red Hat, I would be trying to figure out how to make the RHEL host/KVM/RHEL guest environment work together intelligently. If I were Microsoft, I would be doing the same with the Parent/Hyper-V/Child architecture.