From the Author of The Agile Architecture Revolution

Jason Bloomberg

Subscribe to Jason Bloomberg: eMailAlertsEmail Alerts
Get Jason Bloomberg via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Cloud Computing, SOA Best Practices Digest, Microservices Journal, Internet of Things Journal

Cloud Computing: Article

Cloud-Oriented Architecture and the Internet of Things

There’s nothing in the definition of Cloud that specifies anything about the physical location of Cloud resources

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.

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 21st 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

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).