Cooperating Services in the Cloud

When I tell people my work involves the cloud they often quite reasonably ask: "What is the cloud, anyway?" I explain that -- like the web -- it is a layer of services built on top of the Internet. This often leads to another question: "There's a difference between the Internet and the web?" Yesterday, for example, an acquaintance said that he'd heard the web had something to do with DARPA, but he'd also heard it had something to do with CERN, which was it? Both, I said. The Internet, which is the web's substrate, emerged from DARPA-funded work in the 1970s; the web was invented by Tim Berners-Lee at CERN in the early 1990s. The same question came up after a class I taught at Virginia Tech back in April. A student wrote on her blog: "Who knew that the web and the Internet were different things? I thought they were simply interchangeable words."

Those of us who've worked with these technologies for decades know how the layer cake was made. Most people don't, though, and that's generally OK. Like other infrastructures on which civilization depends, our data networks shield us from vast complexity while delivering services that we take for granted -- except when they sometimes fail. Still, I've been asking myself lately what people really ought to know about the Internet, the web, and the cloud. It boils down to just two things: standards and services. Knowing about such things matters less in other realms where we are mainly consumers of standards-based services. But when it comes to modern data networks we are also producers of services that are, or anyway should be, based on standards.

One of the touchstone examples I use when discussing the elmcity project is my local high school's weekly calendar, which is a PDF file. It does provide a service: you can read it online and find out what's happening this week. And it does employ an openly-specified standard: the Portable Document Format. But it's a poor excuse for the service the high school could be providing, because it's based on the wrong kind of standard. PDF is for documents that people read and write. Since 1998 we've had iCalendar, an Internet standard that enables computers to read, write, and exchange calendar data. More recently, we've gained the ability to use popular services that support iCalendar. And yet most people and organizations that put calendars online don't use iCalendar-aware services to do so. Why not?

There are many reasons, but among them is a failure to appreciate that the Internet's core data communication services, and the layered services riding on top of them, are in fact computer-mediated at all levels. When you post an event to a public online calendar, it isn't (or shouldn't be) like sticking a notice on a kiosk downtown. What you really want is for the data to be packaged up by your computer, travel through various data networks (where it can merge with other streams of information), and then arrive at my computer where it can be unpacked, reorganized, and made useful to me.

It used to be that phrases like "your computer" and "my computer" meant machines in our homes and offices, or more recently in our pockets. Computers that worked for us lived at the edges of our data networks; they were clients; they consumed but did not provide services. Mostly that's still true. But now some of the computers that work for us live in the cloud; they are servers; they provide as well as consume services. This shift is most apparent to businesses whose computers are being virtualized and moving off-premises. But the cloud is becoming personal too. Computers that work for us live in the cloud, alongside computers that work for other people and organizations. How effectively our computers can work for us depends partly on how well they provide services accessible to those other computers. When they don't use the right standards, they can't provide those services, and so they can't do the job we hired them to do.

As part of the elmcity project I've been making a list of content management systems guilty of that charge. Here are five of them: Constant Contact, PeopleCube, ServiceU, SchoolWorld, ChamberMaster. Organizations hire these cloud-based services to manage, among other things, their public calendars. But the services don't publish those those calendars in the standard iCalendar format, so the data can't syndicate. Why don't these providers support iCalendar? "Customers aren't asking for it," they say.

What's the cloud? A place where computers that work for you, and computers that work for other people, participate in an ecosystem of standards-based services. If you're paying for cloud-based services that don't participate in that ecosystem you're not getting your money's worth. Ask for it.