Feds To Adopt 'Cloud First' IT Policy 142
theodp writes "The White House Thursday announced plans to restructure IT by consolidating federal government data centers and applications, and adopting a so-called 'cloud first' policy. Unveiled by federal CIO Vivek Kundra, the 25-Point Plan (PDF) calls for cutting 800+ data centers by 2015, as well as shifting work to cloud computing systems. The new 'Cloud First' policy cites the ability of Animoto.com to scale vs. the government's short-lived Cars.gov (Cash for Clunkers), although Google Trends suggests this may be somewhat of an apple-to-oranges comparison for justifying a national IT strategy. As long as we're talking clouds, a tag cloud of the 25-Point Plan underscores that the Feds are counting more on IT Program and Contract Management rather than Computer Science wizardry to deliver 'the productivity improvements that private industry has realized from IT.' Not to be a buzzkill, but those of you celebrating CS Education Week might be advised to consider an MBA if you want a Federal IT career."
What cloud? (Score:4, Informative)
"Cloud" is just a way of saying you have a standardized, generic way of scaling your systems. The new buzzword adds an excuse to outsource the whole thing to a "reputable" supplier and avoid taking any responsibility. If your needs are small this is a great concept. You get to use the same iron as the big boys, without the up front investments.
For someone the size of the government however, I think it's rather strange they are not using clouds already. They may never have called them clouds, but surely they have some reasonable in-house systems architects, no?
Re:What cloud? (Score:5, Informative)
In short, "Cloud computing is a model for enabling 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".
It doesn't have to be necessarily hosted on external providers. It may very well be an internal, Private Cloud. And if it's built on top of open standards such as the vCloud API [vmware.com], you may end up with vApps that can be moved from internal to external clouds and back, as well as hybrids.
Re:Vivek Kundra is a fraud (Score:5, Informative)
Re:We had that setup in the 1960s and the 1970s. (Score:5, Informative)
There's some truth to that, I agree. I think one major reason for the changeover, though, was a period in which there was no great centralized solution. By the late 1990s, and especially early 2000s, the centralized big-iron stuff that many universities ran was just not that impressive compared to commodity x86: we could buy a relatively cheap x86 server for $2000 that ran circles around the UltraSPARC behemoth that the department was still maintaining. But virtualization and clustering on commodity hardware circa 2001 was not that great, so it wasn't particularly easy for central IT to switch. I mean, their UltraSPARC was slow, but it had 64 gigs of RAM and could support dozens of simultaneous users, something that was hard to replicate on a 2001-era x86 machine. So there was a period when everyone just bought a Dell machine and stuck it under their office desk, as the easiest upgrade path.
It's not clear to me that's still the optimal solution, though. If I just want some server that's always on and has decent hardware, we're back again at the point where central IT can fairly easily provide it to me, by giving me a VM. Or I can buy that VM myself from Amazon or some VPS provider if I want. I'm sympathetic to the argument that everything old is new again, but for my needs, the Dell-under-the-desk approach to server provisioning just doesn't seem optimal currently, though there were a few years where it was.
Re:We had that setup in the 1960s and the 1970s. (Score:4, Informative)
All very good points. I would add that there's a big difference between the old days where you had one local mainframe, and a situation where you have a dozen cloud providers. Even within a single cloud provider (say, Amazon), the service is run across several geographically-distributed datacenters. The failure of one shouldn't take everything down. In an ideal world you could move your server images from place to place, provider to provider, and even to local hardware if that proved necessary. This is a benefit of modern virtualization.
Of course this isn't exactly how things work yet --- you can't easily migrate between services and local hardware. But it's early days and some clients will probably demand that kind of flexibility.