Well, if cloud architectures are not new, exactly how old are they? The title almost begs the question.
It may be the latest, hottest buzzword, but architecturally, the cloud is more than 20 years old. And, you are intimately familiar with it. It’s the Web. What makes it “the cloud” are the enterprise applications getting moved onto the Web. But, this move isn’t just a matter of deploying some application servers and offering HTTP-based interfaces to existing software. It is a marked change with the architecture of these software systems built on and for the Web, rather than for traditional enterprise infrastructure.
A key tenet that makes enterprise application deployment in the cloud possible over the Web is REST. Having emerged over the past few years as a predominant Web service design model, REST has increasingly displaced other design models such as SOAP because of its simpler style. Joining me in the development of this blog post to be published when I’m on vacation is EMC senior technologist Cornelia Davis.
Scale by Design
The Web is highly distributed, massive in scale. With roots in defense initiatives like ARPANET, as well as NFSNET, the ideas behind the Web have been around for years (e.g. access from anywhere, ability to scale, resource federation over distances). But, what got it to what we know were advances in packet switching in the late 1980s/early 1990s and the decommissioning of ARPANET in 1990 and NFSNET in 1995 which removed the last barriers to commercial traffic.
The Web runs over a colossal network of compute, network, and storage resources where individual pieces are likely to fail relatively frequently. But, in spite of these frequent failures, we can have very reliable systems. A good number of household names such as Amazon, eBay, FaceBook, and Google run their core business applications as Web-based services in the cloud.
Good REST is Important
How do they do it?
There are many reasons for the successes of these organizations, but let’s focus on the architecture. Cloud-based applications are built over the architecture of the Web based on REST.
In his 2000 doctoral dissertation, Roy Fielding coined “REST” for Representational State Transfer to describe the architectural style of the Web, which he was heavily involved in developing. In his well-read PhD thesis, Dr. Fielding described the primitives of the Web and the manner in which they are connected, and he codified the primary tenets of the REST architectural style.
Everyone is doing REST these days, so it seems like we as an industry are well-positioned to move over to the cloud. Unfortunately, a true understanding of each of these architectural principles seems to be lacking.
So, to establish a good baseline about REST, let’s review each of the four (4) principle tenets briefly.
1. Resource orientation and addressability: The primary abstractions in the systems are a document, a picture or some media type, not actions, and these resources all have URLs. This approach means that in a systems management setting, for example, the system is exposed as a set of hosts, storage arrays, LUNs, and so on. Each host, storage array, or LUN, has a unique URL that can be used to get to a representation of that resource.
2. Uniform interface: REST resource operations are done through a small set of operations that you can levy against a resource; a RESTful design defines an agreed-upon set of semantics for each operation. The uniform interface for HTTP includes GET, POST, PUT, DELETE, PATCH, and a few other lesser-used operations. These semantics include definitions for characteristics such as safety, for example, where invoking the operation has no side effect on the resource state, or idempotence, where invoking the operation any number of times results in the same resource state.
3. Transfer of resource representations: All interactions with resources are via a transfer of resource representations; clients do not directly access a resource—there
are no sessions. This loose coupling of clients and servers is absolutely paramount for the architecture of the Web where every service request is completely stateless. This approach allows for requests to be serviced by any number of nodes in the federation of compute, network, and storage that characterizes the Web.
With REST, this tenet goes beyond statelessness to requiring that the resource representations be self-described with a media type indicating the format of the representation. Just as standardized HTTP verbs helped facilitate the massive uptake of the Web, so did the standardization of the most widely-used media types. With REST, media types are used in content negotiation, allowing a server to return results specific to the client making the request, supporting a usage paradigm that allows any type of client to participate in the system, from mobile to full desktop form factors.
4. Representations with hyperlinks: The forth tenet in Dr. Fielding’s doctoral paper specifies that resource representations must carry hyperlinks to related resources or to other URLs that can drive the application state. This approach is analogous to Web pages having hyperlinks to other Web pages, or including buttons that allow the user to start a purchasing process at Amazon, for example.
While nearly impossible to imagine the World Wide Web having pages without hyperlinks, the vast majority of resource representations returned from so-called RESTful services are completely devoid of them. Without hyperlinks, clients hard code knowledge about the way in which resources are related or can be processed limiting how services and applications can be extended, upgraded, or combined with other services into new offerings (think, agility and efficiency—the raison d’etre for cloud).
Give IT Some REST
Each of these four principles tenets described here is essential to making mission-critical applications work in the cloud. When making cloud-related decisions regarding technology, be sure that the product offering fully adheres to REST and you’ll save yourself the pain of rip and replace down the road. Cloud architectures may not exactly be new, but for many enterprise applications, moving them to the cloud does require carefully designed changes.
Cornelia Davis is a senior technologist in the office of the CTO at EMC Corporation. As a member of the architecture group, her primary focus is on integration approaches with an emphasis on RESTful SOA like the new EMC DataBridge enterprise mashup platform. In April 2012, she presented a paper called “What if the Web Were not RESTful?” as part of the WWW Conference in Lyon, France.