Harald Welte seems to be missing the point of the U.S. government announcing the closure of 800 data centers. If you read the NYT article carefully, you’ll see that the relationship between a government move toward cloud computing and these 800 closures is tenuous at best, and it never even mentions moving anything to a public cloud. Let’s look at Harald’s specific complaints.
[As a government, you…] make yourself dependent from a private company to supply essential infrastructure
We don’t even know that’s the case here. They could be moving from these 800 data centers to a wholly government-owned and government-run private cloud that exists across several larger ones. That’s what they have already done in some parts of the government, and what I’m sure they will continue to do for some parts of this program. They will almost certainly outsource some functionality from these data centers to public or semi-public (leased) cloud facilities, but that might not involve any essential infrastructure (Harald’s term). There’s a lot the government does that’s not essential. Would it really be that much of a problem if, for example, some functions of the National Archives and Records Administration moved to a public cloud? I don’t think so. Let’s worry about the government indiscriminately outsourcing military/police/security functions before we worry about selective IT outsourcing.
introduce single points of failure (technically, administratively)
Why assume that there will be more SPOFs than currently? If a particular government department currently hosts machines in one data center it owns, and trades that for resources in several goverment-cloud data centers that it shares with 799 other departments, how is that any worse? The per-application architecture will be more or less free from single points of failure just as it would be if privately hosted, and the fewer/larger cloud centers are likely to be far better run that the lower third (if not all) of those 800 department-private data centers are today. As long as there are at least three or four data centers involved, and there are sure to be more than that, there might well be a net improvement in availability.
give up control over who physically owns and has access to the data
In fact, you will have a hard time even finding anyone at all who can tell you where your data is physically located. Maybe even out of the country?
This is the part that makes the topic relevant for CloudFS. Moving data to the cloud does not have to mean giving up knowledge of its location or control over access to it. Remember, private or leased clouds haven’t been ruled out, and in those you have complete control over location. Even in public clouds, this is often the case; for example, each Amazon EC2 region exists at a fairly well known physical location. Public-cloud providers already cater to users who must comply with rules like HIPPA and SarbOx and PCI and EUPD that set requirements regarding data location, so this could not be otherwise. With respect to access, if you do encryption and key management the right way – as we try to in CloudFS – then you have the same control over data access in the cloud that you do on your own machines. In fact, I’ll bet there are hundreds of government departments whose data centers are less physically secure than those at Amazon or Rackspace, and who either don’t use encryption at all or don’t use it effectively. Moving to the cloud doesn’t solve their encryption problem, but it doesn’t make that problem any worse either, and the effect of this move on their physical security is likely to be a positive one.
So, is a move from 800 mediocre data centers to a couple of dozen world-class ones really such a bad idea? I’d never underestimate the government’s ability to mess something like this up, and any transition creates opportunity for failure, but none of Harald’s objections stand up to scrutiny. Whether this initiative succeeds or not is a matter of execution; fundamentally, the architecture they’re embracing is still far better than the one they’re abandoning.