Over the past month, I have put together some thoughts around the components that should make up the composition of a Cloud Computing service, from a service producer’s perspective, in what I termed as the Big Picture. That posting can be found here and a more extended description posted on my web page here.
For this week, I’d like to shift my focus on some of the ingredients that make up the Cloud service. Lets start peeling off the skin of this onion..
Firstly, let us recall the key characteristics or traits of Cloud Computing services, which are:
- On-demand self-service and ease of provisioning,
- Broad network access or ubiquitous access over standard mechanisms,
- Rapid elasticity in scaling out and scaling in, where necessary,
- Pay only for what you use.
Cloud service allows you to easily provision servers, shut them down when you’re done with them, and pay only for what you use. You can have your infrastructure up and running in hours instead of the long lead time your IT department usually take. You would also be able to scale out and scale in as necessary, hence you’re not stuck with the inflexible architectures that existing hosting providers use. And the best part is that a Cloud service is supposed to be ubiquitous, allowing you to carry out all of these right from your laptop’s browser over the Internet. But how do you actually provision, shutdown and scale such resources? Especially over a browser on your laptop?
This is where Cloud APIs comes into the picture. And this is where so many have debated and argued on the merits (or otherwise) of the various Cloud APIs (based SOAP, WSDL, WS-* or REST specifications). William Vambenepe’s blog entry did a good job comparing 4 known public Cloud APIs (AWS EC2, GoGrid, Rackspace and Sun Cloud API). He pointed out that the most interesting thing about the Cloud APIs is the use of REST for Cloud management and one of the compelling reason to use REST is not to have a constraint in the design of the URI (Uniform Resource Identifier) space.
REST stands for Representational State Transfer, which is an architecture style for distributed and networked hypermedia systems, coined by by Roy Fielding in his Ph.D. dissertation. REST is not a standard nor a protocol but rather a set of styles or principles that define how Web standards, such as HTTP and URIs, are supposed to be used. Here is Roy Fielding’s explanation of the meaning of Representational State Transfer:
“Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”
REST-styled architectures would consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of “representations” of “resources”. And as we all know it, the Web is comprised of many resources, which are essentially any coherent and meaningful item of interest, that is addressable. Example of a resource that is uniquely identifiable, i.e. with a URI, are: http://www.example.com/sample/1029.html, and one of the guiding principle of REST is to uniquely identify resources through an ID, i.e. a URI.
At any particular time, a client can either be transitioning between application states or “at rest”. A client in a rest state is able to interact with its user, but creates no load and consumes no per-client storage on the set of servers or on the network. This is known as the stateless communication principle. In other words, each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server, beyond a single request. An obvious reason for this is scalability as the number of clients interacting would seriously impact the server’s footprint if it had to keep client state. This principle also isolates the client against changes on the server as it is not dependent on communicating to the same server in two consecutive requests, i.e. the server could be shutdown, updated or restarted, without affecting the client. The client will only begin sending requests when it is ready to transition to a new state. While one or more requests are outstanding, the client is considered to be transitioning states. The representation of each application state contains links that may be used next time the client chooses to initiate a new state transition.
Other principles of a REST-styled architecture are: To improve network efficiency responses, must be capable of being labeled as cacheable or non-cacheable; All resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE); Provide multiple representations of resources for different needs – the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another; and use of layered components or intermediaries, such as proxy servers, cache servers, gateways, etc, which can be inserted between clients and resources to support performance, security, etc. On the latter, an application can interact with a resource by knowing two things: the identifier of the resource, and the action required—it does not need to know whether there are any caches, proxies, gateways, firewalls, tunnels, or anything else between it, to mediate the request, and the server actually holding the information.
In summary, the five key principles are:
- Give every resources a uniquely identifiable ID (URI)
- Use standard methods or interface, i.e. default HTTP protocol with standard methods GET, PUT, POST, DELETE
- Provide resources with multiple representations
- Communicate statelessly
- Use of layered components is transparent to request
Cloud APIs enables a user to realize the benefits of a scalable, self-service Cloud service. However, Cloud Computing isn’t a magic where you could just provision an instance and automatically able to scale your application dynamically and work wonders. It depends on what application do you intend to run.
I will try to address the other components of a Cloud service in my next post.
Tags: API, Cloud Computing, Compute, Storage, Virtualization