It’s an Operating System Jim, But Not as We Know It”

In the past couple of months, both Microsoft and VMware have been wary of defining their new platforms as an “operating system”. Microsoft was adamant that Azure isn’t an operating system, while VMware did use the term but hedged by saying that it wasn’t really the same thing as a conventional operating system. So the question arises "is there such a thing as a cloud operating system?". To answer that question we need to look at what a traditional operating system provides and compare it with the functionality that is needed to create a "cloud". Traditional operating systems are something of a moving target in that they have evolved over time and the definition has become somewhat clouded. But for the most part people would agree that the operating system provides:

1. Management of hardware resources like processors, memory and I/O interfaces to abstract the underlying hardware details from applications.
2. Scheduling of application execution to allow multiple applications to share the same hardware.
3. Application programming interfaces (APIs) to allow inter-process communication and other fundamental constructs needed by application developers.
4. Management interfaces to simplify installation and update of applications and operating system components.

These features all operate at a single system level (though clustered systems have extended the concepts to some degree) and require the operating system to “understand” the individual hardware components within the server.

A “cloud operating system” has to operate at macro level to control the operation of multiple servers in the cloud, which means creating functions that are analogs of the micro-level functions provided by a traditional operating system:

1. You can’t just plug a server into the cloud and make it useful, it’s just a bunch of components, so there has to be some software installed on each server to control it. For example Microsoft’s Azure system will install a hypervisor onto any server in the cloud (for more details see http://www.vinternals.com/2008/11/microsoft-azure-infrastructure.html). This provides the bare minimum of functionality on each server.
2. Shared resources like storage have to be managed and presented to applications in the cloud, the vStorage component of VMware’s VDC-OS (for more details on vStorage see http://virtualgeek.typepad.com/virtual_geek/2008/09/so-what-does-vs.html).
3. Applications have to be scheduled in the cloud, so that quality of service can be maintained by ensuring that nobody hogs all the resources in the cloud.
4. Depending on the cloud implementation there maybe APIs for application developers. Examples of cloud platforms that provide interfaces for application developers include both Microsoft’s Azure and Google’s App Engine. In contrast, VMware’s VDC-OS doesn’t provide application developers with interfaces (for more discussion on this see my previous blog entry “Waiting For The Other Shoe to Drop”
5. Management interface to assist in managing the cloud and deploying applications into the cloud.

So the cloud platforms of the future must have functions that are similar in many ways to a traditional operating system. To a degree, the classification of these new cloud platforms is irrelevant, ultimately, if vendors and customers are comfortable with calling them cloud operating systems, then that’s what they’ll end up being called.

Posted by: Nik Simpson

Comments

[marc farley]

Hi Nik, The concept of an operations manager certainly needs to exist for cloud facilities, but I'm not sure we ought to bend the term "operating system" for that purpose.

[Nik Simpson]

Thanks Marc, to a degree, I agree we are stretching the definition, but does it really matter? A cloud OS has to perform many functions at the cloud level that are analogous to the functions performed by a traditional operation system, just on a much larger scale. If you look at Azure you can map just about all of its components onto things we see in a single system OS, so calling it a cloud OS doesn't seem like that much of a stretch.

At the end of the day though it's going to be about whether the term "cloud OS" gains traction, if the press and the vendors start talking about "cloud operating systems" then the name will stick. A quick search on Google for the term "cloud operating system" yields many pages of hits, so horse may not have left the barn yet, but it's certainly out of the stable ;-)

[Robert Wipfel]

Just for grins, we did a mapping of conventional single-server OS data structures to new distributed organization (ASCII table follows):

Legacy OS | Virtual OS | Equivalence
Binary file | Image file | Code
LSB Service | Defined VM | Configuration
Process | Active VM | Scheduled code
int argc, char *argv[] | Jobargs | Environment
Data file(s) | Logical unit(s) | Data
Nice level | Constraints | Quality of service
Process group | TesselApp | Application

A global RESTful web namespace is the modern equivalent of what was in single system image Unix (SVR4/mk); i.e. the ability to enumerate all instances of objectclass=X regardless of location, is today called federated search, on SVR4/mk it was cat /proc/ to see all processes across all nodes of a parallel distributed memory machine.

And before the idea that files could be used to represent (as in *R*est) anything:

"One of the overall design goals is to create a computing system which is capable of meeting all of the requirements of a large computer utility. Such systems must run continuously and reliably 7 days a week, 24 hours a day [...] and must be capable of meeting wide service demands. "because the system must ultimately be comprehensive and able to adapt to unknown future requirements, its framework must be general, and capable of evolving over time"

Corbato and Vyssotsky on Multics, circa 1965, http://www.multicians.org/fjcc1.html

Maybe the next new OS should simply be called "DOS" as in Distributed OS ;-)