In this article, we take a look at the basic interoperability requirements when communicating with the Cloud, and in particular at techniques and standards used to express and enforce wire-level contracts between communicating parties, as these parties are increasingly also contracting parties in a Cloud environment. Many standards already developed for Web services and service-oriented architectures provide to the communicating parties a good understanding and control of the expected quality of service at the most basic level of the interaction.
Using Web Services in Cloud Computing is not a new idea. Some vendors of Cloud platforms, which provide services necessary to run Cloud applications, supply these as Web services, especially for management functions of the Cloud (on the provider side) and for storage, versioning, upgrades, migrating and data transfer on the user side. But the Cloud will gradually bring the spotlights onto the "contractual features" of Web services, while the focus so far has been on the connectivity features of this technology.
Cloud Expo New York to attract 5,000 delegates and over 100 sponsors
One View of the Cloud
The term "The Cloud" brings forward images of billowy whiteness floating in the sky with a nebulous shape and without any clear border or structure. The term has long been associated with networks, because the complexity of the routing of messages makes it hard to map out the real structure of the Internet, which is constantly changing. Calling the network a Cloud is useful when you don't really care if you know how a message gets from point A to point B; you care only that it gets there reliably and quickly. But when you extend computational capability into the network, the concept of a white billowy Cloud becomes less apt.
The Cloud is not a single amorphous blob; it is just as complex as data centers that exist today, except that this complexity is somehow opaque (hidden). (In fact, instead of a Cloud, we might envision a jellyfish - it is squishy and compliant, expanding and contracting when needed, and yet it still has a definite resilient structure - as well as a sting if you don't get it right.)
Communication with the Cloud is not going to be magically simplified compared to typical interactions today - it still has to resolve the same issues as conventional business-to-business activity, such as management and maintenance of distributed systems in a multi-owner environment, interoperability between different platforms, security and access control.
Clear partitioning of the Cloud is necessary, isolating one domain of control from another; interfaces will be needed to allow software in one domain to access another, along with business-to-business protocols for making calls or transferring data from one domain to another, just as it happens today. What is different from what we know today is that the boundaries are stretchable to allow the expansion of additional computing resources on demand. Plus, the barrier to entry is extremely low, since the cost of a small domain is very low, and that domain can stretch quickly to handle any load if needed. Thus, usage of such protocols and remote interfaces in the future is likely to be much greater than today, resulting in "federated" processes and deep integration of multiple levels of service.
It is safe to say that the complexity that follows results in increased challenges around issues of security, interoperability, availability, discovery, etc. This is on top of the challenges of distributed functionality and remote access, which are inherent in Cloud computing, not to mention the issues around user interfaces - human interactions with the Cloud - and workflow systems. Web services are increasingly employed in addressing these challenges.
Contracting with the Cloud at Wire Level
While one is used to thinking of contracts in business terms, it is clear that these terms also have to get defined at wire level when it comes to Cloud interactions. Such wire-level contracts will concern the quality of service of the Web-based interaction, accepted delays, tolerance to protocol variations (e.g., when using different versions of a messaging protocol standard), security features to be used, conditions under which interoperability must be guaranteed.
Wire-level contracts both at definition level (how to describe these) and execution level (how to enforce these) have already been used in such areas as B2B messaging and Web services. We investigate here how Web services help interfacing with the Cloud, and in particular how its contractual features will become increasingly valuable, while often overlooked today.
First, let's define our terms. A Web service can be described as a Web-accessible interface that is exposed and invoked using platform-independent technology. A Web service passes information between applications or processes using open, standards-based protocols regardless of applications' programming languages or platforms, using a machine-readable contract to describe how to pass and receive information.
To understand more about how Web services are relevant to the Cloud, it is important to realize that Web services are more than Web-mediated remote procedure calls. Web services define contracts that cover various aspects of a Web interaction between different parties that are actual contracting business partners. These contractual aspects are in turn supported by various Web services standards:
Such contracts can be defined as "technical contracts," as they focus on the communication infrastructure. As such, they can be seen as low level, down to the wire translation of SLAs or QoS agreements defined in higher-level business contracts. The above Web service standards are understood by most recent Web server platforms.
These contractual features become critical in a multi-owner environment such as the Cloud, where ensuring data interaction alone is not sufficient. Web services technology covers the various aspects of associated contract information: artifacts representing these contracts (XML schemas and document templates, policies, interface definitions) are themselves subject to exchange protocols specified by standards like WS-MetadataExchange and WS-ResourceAccess.
The platform - understood from a software viewpoint - will make management functions available in the form of Web services. Several Cloud providers actually do this already: they publish Web services for deploying and managing hosted applications. The management functions that can be controlled via Web services cover the major Cloud platform services:
These Web services are intended to be accessed or driven by in-house programs as much as by humans behind Web browsers. For example, application builds can be automatically deployed at times of the day when usage and bandwidth are low. In-house business activity monitoring tools will query and configure Cloud metrics and monitoring services. Synchronization with in-house applications will require carefully scheduled data transfers to and from the Cloud.
Such management functions have their own SLAs, and their reliability and security are expected to become critical in an environment where users' involvement will migrate more from hands-on remote management and control to an after-the-fact supervisory role decoupled from automated operations. This is where the contractual aspect of Web services described above will add value.
In the first phase, applications - many of them currently hosted as monoliths in Cloud platforms - are expected to become more distributed over time as the Cloud offers viable remote alternatives. Distribution is expected to occur first with delegating basic functions - seen as application resources - to the Cloud: storage, queuing, validation of business documents, end-user interaction, etc. This form of distribution is also gaining momentum with the rise of "hybrid clouds," described later.
This means that an application - whether running in-house or in the Cloud - will access and control Cloud resources remotely. Again, this is a multi-owner environment subject to contractual exchanges such as allowed by Web services.
In the second phase, distribution will affect higher-level components of an application. The types of applications that lend themselves to such distribution are:
The Hybrid Cloud
Various combinations of Cloud-based and in-house computing are expected to evolve. One model growing in popularity is the hybrid Cloud, where in-house applications - which may run themselves over an internal Cloud - are accessing resources and sub-processes in the public Cloud. Another example is queue-based data transfers (e.g., cross-application transfer of records related to a customer or a patient). A third example is for a cloud to host a public face to another otherwise internal application. The rise of hybrid Clouds makes interoperability - and the related technical contracts - a key requirement. Indeed, the hybrid model - unlike internal Clouds or single-provider public Clouds - assumes communication across different Cloud platforms, both for application interaction and management functions.
Such interoperability in turn will rely on three tenets:
But these B2B standards increasingly rely on Web services technologies at the protocol level, if not for service interfaces; ebXML messaging (ebMS), a popular B2B standard in Asia and Europe that provides advanced support for the contractual aspect of B2B, has embraced in its latest version (V3) Web service protocols such as WS-Security and WS-ReliableMessaging. The AS2 Web standard, which is widely adopted in consumer retail and various supply chains in the United States, has recently evolved into AS4, a simple profile of ebMS V3 that is based on Web services standards.
The growing interest in the hybrid Cloud, as well as the growing choice of cloud providers, will put more pressure on the standardization of the Cloud access - which does not always mean new standards, but in many case just reusing - or "repurposing" - existing ones. As Cloud applications move from pilot projects to production mode, these standards will also be valued in how well they support the contractual aspect of the Cloud, which concerns all the layers of the communication stack. Because the fulfillment of Cloud computing contracts between parties depends on the fulfillment of the "down-to-earth" contracts between infrastructure components (and their owners), we can expect to see the same emphasis on these wire-level agreements and QoS controls as previously seen in other communication-centric spaces such as B2B and B2C.
© 2008 SYS-CON Media Inc.