Friday 27 December 2024
Font Size
   
Friday, 04 November 2011 05:00

Why NIST should scrap the cloud entirely

Rate this item
(0 votes)
Why NIST should scrap the cloud entirely

Illustration: Richard Perez

The National Institute of Standards and Technology (NIST) has published a new volume of its roadmap aimed at accelerating the adoption of its previously released Federal Cloud Computing Strategy. The report lays out a set of ten requirements for further federal cloud adoption, most of which will be familiar to any CIO who has the standard slate of worries about cloud’s interoperability, security, data portability, standards compliance, and privacy. Or, as NIST puts it:

In the technology vision of Federal Cloud Computing Strategy success, [US government] agencies will be able to easily locate desired IT services in a mature and competitive marketplace, rapidly procure access to these services, and use them to deliver innovative mission solutions. Cloud services will be secure, interoperable, and reliable. Agencies will be able to switch between providers easily and with minimal cost, and receive equal or superior services.

The only thing I’d add to this list is, “And every child should have a pony.”

Of course, it’s easy to poke fun at NIST’s pie-in-the-sky wishlist for cloud computing, but the authors themselves know that the document is more aspirational than operational. The plan is to identify priorities, to define goals (however lofty), and to foster discussion that will hopefully nudge to this whole cloud thing forward to the point where the government can start saving money with it. Nonetheless, the challenges that the authors face in trying to help “the cloud” are fundamental, and they’re rooted in the fact that it’s not really clear what, if anything, “the cloud” is.

I’ve talked before about the confusion around definitions of cloud, and I generally think that people should just stop trying to define the term. The NIST publishes its own definition of “cloud computing,” which features in most definitional discussions of the topic. Few people adopt the NIST definition without alteration, and indeed few adopt almost any definition unaltered.

But as much as it would make me happy to never spend another five minutes of my life listening to or reading someone’s attempt to survey the various definitions of “cloud” before offering their own, it’s clear that confusion reigns even among insiders. So the only point at which this definitional is going to stop is when everyone gets tired of it and moves on—there will be no final definition that ends the debate, and the discussion won’t die as a result of technological shifts because the such shifts are what sustain it in the first place.

So “the cloud” is a moving target, and nobody can agree on what it means, which is why the NIST’s attempt to first define “cloud computing” and then build a detailed roadmap around that definition will ultimately prove futile. If the people who are building this ever-changing collection of technologies and services called “the cloud” can’t agree on what it is, then how can one agency define that nebulous abstraction and then give an implementation roadmap? It’s not possible.

An alternative approach: scrap “the cloud”

I’d like to humbly suggest that if NIST really wants to help government agencies save money, it should get out ahead of the private sector and do what all of us will eventually do one day, which is completely scrap “the cloud” as an useful abstraction.

Instead of framing a discussion of the proper allocation of scarce government IT resources around some notion of “cloud,” NIST should instead focus first on the kinds of things that users want to do with computers, i.e. email, telephony, archival storage, data distribution, publication, content creation, content management, etc.. Then, for each application type, the agency should use an agreed-upon set of metrics to evaluate the full range of options that modern computing supplies, from old-fashioned shrink-wrapped software to apps to client-server to SaaS to roll-your-own using PaaS or IaaS.

So instead of asking, “what’s this cloud thing and how are we supposed to think about it and take advantage of it?” CIOs would ask, “how are we doing email this year? Are we still storing it locally for compliance reasons, or is Google Apps now approved for agency use? And what’s currently my cheapest option for publishing new regulations internally and taking feedback? Are we putting stuff up on Slideshare.net and embedding it in a blog with comments enabled, or has some other agency rolled their wiki-based own solution that I can then re-purpose?”

The great thing about this approach is that NIST could reuse much of its existing cloud work to get started. Most, if not all, of the agency’s ten “cloud” requirements could be re-framed as general software requirements and used to evaluate the best way to deliver a domain-specific compute experience for government end users. So a future NIST report might identify, say, twenty things that people want to do with their computers and mobile devices, so that a subsequent set of twenty reports (putting these in a wiki would be great) could deal with each thing as its own entity.

I for one would actually love to read the definitive NIST wiki on government email, or content management, or text-based chat, or off-site backup, or publishing, and so on. Such a living repository of up-to-date evaluations of actual, real-world solutions would be a great resource for the private sector, as well.

Authors:

French (Fr)English (United Kingdom)

Parmi nos clients

mobileporn