Cloud-Oriented Architecture and the Internet of Things

Quick quiz for all your Cloud aficionados out there: what’s missing from the NIST definition of Cloud Computing? To make this challenge easy for you, here’s the definition: “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” Give up? What’s missing is any mention of data centers. Sure, today’s Clouds typically consist of resources in data centers, running one way or another on racks full of physical servers. But there’s nothing in the definition of Cloud that specifies anything about the physical location of Cloud resources.

Look at the NIST definition again. If you’ve seen this definition before, you may notice a new word that NIST presumably added after their now-seminal definition entered the blogosphere: ubiquitous.  I don’t know what fevered discussion led to the late inclusion of this word, but its addition is telling. After all, it doesn’t matter how many data centers you have, they will never be ubiquitous. But NIST in their wisdom never intended the resources in the definition of Cloud to be limited to data centers, or for the list of Cloud resources to be exhaustive, for that matter. We could add, say, mobile phones, automobiles, factory equipment, and the proverbial fridge to the list, and as long as we have the convenient, on demand network access as well as the automated provisioning and deprovisioning, then this entire “Internet of Things” is part of the Cloud.

This globally ubiquitous interpretation of Cloud Computing should be especially exciting to architects, since it falls to them to understand all the technology resources at the disposal of the organization and how to address business challenges with such resources. From ZapThink’s perspective, the Internet of Things provides a grand stage for our ZapThink 2020 vision to play out. There are fundamental differences, after all, between data centers and the Internet of Things, which means that fundamental Cloud architecture principles must also transform to support this new reality. This transformation promises to be truly disruptive—a true paradigm shift as we figure out what it means to implement what we call Cloud-Oriented Architecture.

Understanding Resources

Since Cloud-Oriented Architecture (COA, natch) extends past the data center to the ubiquitous resources of the Internet of Things, we must expand our definition of resource beyond the list in the NIST definition of Cloud Computing. The obvious place to go for such a definition is the REST architectural style, which defines a resource as “an entity or capability on a network.” Note that resources in “traditional” (i.e., data center-based) Clouds are a subset of this broader definition of resource. In RESTful terms, Web pages, php scripts, and ASP/JSP pages, for example, can all be resources. We wouldn’t normally lump such resources in with servers, storage, networks, and the other Cloud resources we typically talk about in the Cloud context. But in COA, where we free the Cloud from the data center, anything we can give a Uniform Resource Indicator (URI) to can be a resource. And of course, with IPv6 we have plenty of IP addresses to go around, where anything might have one—and if a thing has an IP address, it can certainly have one (or more) URIs.

So far, so good, but beware a pitfall in our path: Resource-Oriented Architecture (ROA). ROA takes certain elements of REST and recasts traditional integration by leveraging RESTful APIs. ROA has its place to be sure, as it resolves some of the knottier problems of Web Services-based SOA, but ROA is decidedly not COA. In fact, they are at opposite ends of a philosophical spectrum that underscores the paradigm shift inherent in moving to the Cloud.

ROA + HOA = COA

In fact, COA is really more about Hypermedia-Oriented Architecture (HOA) than ROA. The point to assigning URIs to resources, after all, is to build distributed hypermedia applications, which are the point of REST. This is where you need to make a conceptual leap: while the traditional notion of a hypermedia app is a glorified Web site, with COA, applications consist of hyperlinked resources of any type, from mobile apps to traffic signals.

We’ve been networking traffic signals for decades, of course, so what’s really new here? The answer: control. Traditional distributed applications have centralized control, while distributed hypermedia apps do not. In fact, this distribution of control is what we mean by the prefix “hyper,” and is what makes the Web what it is today. Remember the green screen menu-based interfaces from the 1960s and 1970s? You clicked on a menu item to load a different screen. But those links weren’t hyperlinks, because they couldn’t take you to a screen (or page) on a different system. The secret of hypertext (now hypermedia) is that it enables the Web to be worldwide, with no central point of control.

Fast forward to the present, and today’s world of distributed computing has a schizophrenic nature: the world of enterprise IT with its inherently centralized control, and the world of the Web—horizontally scalable, partition tolerant, and lacking a single point of control. And now we have the Cloud, and COA bringing the two together. It’s time to bring enterprise IT into the 21^st century, kicking and screaming. We managed to survive the rise of the Web itself, as IT managers begrudgingly provided Internet access to employees’ desktops. Now with the ubiquitous penetration of mobile technology (there’s the U word again!), those managers are once again struggling to maintain control, lest the enterprise rank and file download some malicious app or other malware that brings the organization to its knees.

This situation is only going to get worse (or better, depending on your point of view). Mobile devices are only going to get more powerful. The Internet of Things will continue to grow past our smartphones as Cloud resources penetrate every aspect of our daily lives. The cybersecurity implications are profound, let alone the day-to-day issues of governance. Enterprises who don’t rise to the challenge and revamp their thinking about how technology contributes to the operations of the business are sticking their heads in the sand.

We encouraged IT organizations to loosen the ties of control as far back as 2008, when we explained Why Today is a Perfect Time for No-ESB SOA. Move the control to the Service composition level, we argued, and free yourself from the limitations and inflexibility of a middleware-centric approach to integration. Four years later, this move to lightweight, decentralized Business Process Management (BPM) is still a work in progress, in part because the BPM tools on the market follow the old middleware-centric patterns, but also because the marketplace is not yet ready for the paradigm shift that we’re now in the midst of.

Today’s question, therefore, is whether the market—that is, you—are ready for COA. Are you ready to free the Cloud from the data center? Are you ready to give up centralized security in favor of a lightweight, federated approach? Are you ready to discard the API-centric ROA in favor of the truly RESTful HOA? Perhaps. But such changes in thinking take time. But ready or not, change is afoot. Be an ostrich and continue to do things the old way at your peril.

The ZapThink Take

ZapThink has been piecing this story together for years now, and we’ll pull all the threads together in our upcoming book, The Agile Architecture Revolution (John Wiley & Sons, 2013). As we move away from vertically scalable enterprise applications that require and promote central control to a Cloud of distributed resources that cross organizational boundaries, organizations will need to rethink—and in many cases, reinvent—their approach to governance, security, scalability, and change. In other words, a new way of looking at architecture.

We don’t call this shift a revolution lightly. True revolutions require paradigm shifts: throwing out old ways of thinking and replacing them with entirely different approaches. As a result, paradigm shifts suggest some manner of disruption and discontinuity that in turn differentiates revolutionary change from evolutionary change. Furthermore, revolutionary change is difficult to identify while it’s happening. People usually aren’t sure they’ve been through a revolution until after the fact. Evolutionary change, on the other hand, is far easier to detect, and can move so fast that people confuse it with a true paradigm shift.

We got it wrong in the dot.com era. The hype around the “New Economy” turned out to be just that—hype. The Web turned out to be more of a new marketing channel than a true paradigm shift. The Agile Architecture Revolution, however, is more subtle, because it involves so many different types of change across so many different areas of endeavor. We won’t be sure till we’re done, of course, but the disruption is already upon us. Don’t be an ostrich.

Image credit: marxchivist