In my last post I bemoaned that current efforts around cloud computing are pretty primitive. I closed with a comment that I had some thoughts about what a true cloud computing platform should look like. This post goes into that topic, albeit yet at a high-level.
I think that a cloud operating system (let’s call it a COS) first needs to provide a programming model that encompasses both local and distributed computing. For a long time now we’ve divided software into various categories that each had some fundamentally different architectures:
- Local, client-based, computing
- Remote, server-based computing with a thin front-end (namely, Web applications accessed via browsers)
- Client-server applications that couple thick, client-based, software with remote, server-based computing services
The first category is dominated by Windows-based software, typically written in C++ (perhaps, Microsoft MFC based) or in C#/.NET. The second category is populated by a variety of different web application platforms – Jave J2EE platforms, PHP, ASP.NET and others – on the server and using Internet Explorer, Firefox and Safari on the client. The final category is represented by the fewest number of applications. The client software is frequently written in C++ or C#/.NET but the server software can be implemented through SOAP web services, though custom communication protocols or through domain-specific protocols such as those used by Microsoft Exchange (talking to Outlook clients) or by databases (SQL Server, Oracle, others).
It would be valuable for a COS to first start out by unifying these concepts. If the difference between writing a local application and a client-server application is minimal, more developers will be able to accomplish the latter. The COS might start by suggesting (and providing services to this end) that applications be written by first separating their UI from their computational elements. This concept exists, to some extent, in the MVC (model-view-controller) design paradigm and in n-tier design. It’s applicable even to local applications. It might then also suggest that communication between the UI and the computational elements be achieved through particular means. I would suggest SOAP over HTTP, but that could be simply be one of several mechanisms/transport layers provided by the COS. Applications would define the interface to the computational layer and the local/remote location of the UI and computational layers would dictate the choice of transports. With most SOAP toolkits this should be easy to accomplish given that they already generate stub functions to hide the transport details. I would also suggest that database access be hidden inside the computational layer rather than directly performed by the UI components (this, too, is a tenet of n-tier design).
A COS should also provide a programming model that exploits the benefits of Web based application delivery and thin clients. Ultimately, an Ajax based Web application is a fat client-side application that happens to be delivered by an HTTP server and talks to its computational elements over Web services – a model very similar to what I’ve described.
There’s not much that’s magical about HTTP-based application delivery. The HTML files could just as easily already be present on the client computer. URIs can be FILE:// based instead of HTTP:// based. The only additional piece that a Web-delivered application provides is the URL of the site that provides the back-end computational services. This is inferred from the URL that is used to load the application, but that is purely circumstantial. I would be possible to load an Ajax application locally (from a local HTML file) and provide it with a URI for the server application with which it should communicate. Note, too, that the nature of this URI dictates the security context under which the application is run. Local applications might have access to files and other local resources whereas applications loaded from untrusted Web sites might run under very stringent conditions.
With these mechanics taken care of, the next thing that a COS needs to consider is the nature of its communication protocols. SOAP over HTTP has significant limitations as a general-purpose remote procedure call (RPC) mechanism.
One of these limitations is its single-duplex nature. Clients call servers, but servers don’t typically call clients. Server-to-client communication needs to be implemented through some form of subscribe/poll model. The COS should provide services to facilitate this. A second problem with SOAP-based Web services is its reliance on HTTP as a transport protocol. HTTP is stateless.
Web applications struggle with statelessness, but this characteristic can also provide a valuable benefit. The drawback of statelessness is that it places extra burdens on the UI and computational components of COS applications. Today, Web based applications rely on browser cookies or other hacks to provide some handle that can be used by the server components to establish/reestablish context for the particular UI session. Note that using the term session suggests the nature of the problem. A user has a concept of a session. S/he puts an item into a shopping cart and expects the shopping cart state to persist between page invocations. The server code, however, wants to be stateless. Only by providing a browser cookie or some other session handle can the concept of a session be established. The server code (usually, as part of the J2EE middleware or the .NET framework) is provided with session state that’s based on the cookie/handle. If subsequent HTTP requests are handled by different servers (due to load-balancing, for example), the server side application framework has to provide some form of session state that exists across machines. This is usually implemented by persisting session state in a database or by using some type of messaging mechanism across servers.
The discussion above also suggests the benefits of statelessness. Because HTTP requests (and, thus, SOAP based Web services) are stateless, server code can be more easily extended to run on multiple machines in the computing cloud. A COS’ computational elements could be run on multiple servers and UI requests could be directed to any one of them. Like current Web servers, the COS would have to provide a formal mechanism for providing session state across computers.
If the COS makes no distinction between local and distributed applications, local applications will also need to adhere to restrictions imposed by the nature of communications between the UI and computational elements. In general, communication between the two will have to use interfaces amenable to message-based communication. Function arguments would use pass by value semantics and there would be restrictions on the types objects that could be passed between elements. Developers who are using Web services today will already be familiar with these restrictions.
In the case of SETI@home and Folding@home -type applications, a COS should also support apps that consist mostly of computational elements. Today’s Web servers, for the most part, are active only when awakened by requests from browses. A COS should support the concept of a headless application that consists of only computational elements.
In subsequent posts, I’ll write more about my thoughts for accomplishing this as well as my thoughts on storage and how to achieve a self-organizing COS.