[148764] in North American Network Operators' Group
Re: Megaupload.com seized
daemon@ATHENA.MIT.EDU (Michael Thomas)
Sun Jan 22 01:16:27 2012
Date: Sat, 21 Jan 2012 22:16:01 -0800
From: Michael Thomas <mike@mtcc.com>
To: George Bonser <gbonser@seven.com>
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C8CE85@RWC-MBX1.corp.seven.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 01/21/2012 12:19 PM, George Bonser wrote:
>> Sure, but balance that with podunk.usa's possibly incompetent IT staff=
?
>> It costs a lot of money to run a state of the art shop, but only
>> incrementally more as you add more and more instances of essentially
>> identical shops. I guess I have more trust that Google is going to get=
>> the redundancy, etc right than your average IT operation.
>>
>> Now whether you should *trust* Google with all of that information fro=
m
>> a security standpoint is another kettle of fish.
>>
>> Mike
> I agree, Mike. Problem is that the communications infrastructure that =
enables these sorts of options is generally so reliable people don't thin=
k about what will happen if something happens between them and their data=
that takes out their access to those services. Imagine a situation wher=
e several municipal governments in, say, Santa Cruz County, California ar=
e using such services and there is a repeat of the Loma Prieta quake. Th=
eir data survives in Santa Clara county, their city offices survive but t=
here is considerable damage to infrastructure and structures in their jur=
isdiction. But the communications is cut off between them and their data=
and time to repair is unknown. The city is now without email service. =
Employees in one department can't communicate with other departments. Ac=
cess to their files is gone. They can't get the maps that show where tho=
se gas lines are. The local file server that had all that information wa=
s retired after the documents were transferred to "the cloud" and the sam=
e happened to the local mail server. At this point they are "flying blin=
d" or relying on people's memories or maybe a scattering of documents peo=
ple had printed out or saved local copies of. It's going to be a mess.
>
> The point is that "the cloud" seems like a great option but it relies o=
n being able to reach that "cloud". Your data may be safe and sound and =
your office may have survived without much wear, but if something happens=
in between, you might be sunk. And out in "Podunk", there aren't often =
multiple paths. You are stuck with what you get.
>
> Or your cloud provider might announce they are going out of that busine=
ss next week.
The problem is that the local infrastructure might just as easily get tak=
en out too.
Here in SF, I'm sure that the entirety of the data center capabilities ar=
en't, say,
housed in city hall itself, so we're just as vulnerable to partition whet=
her they run
their own infrastructure as we would be if we hosted in the "cloud" too. =
The larger
issue here is diversity and resilience. The internet is guaranteed to fai=
l us at the
worst possible time, full stop. We need to make certain that we keep at l=
east _some_
terribly inefficient and thoroughly antiquated means of doing the same th=
ing viable
for critical tasks. When I was at Cisco, there was a push to getting emer=
gency responders
to coordinate their communication infrastructure both for cross coordinat=
ion as well
as of course cost down. Makes perfect sense... so long as the unthinkable=
doesn't
happen (ie the internet failing us). That's why our new IP monoculture so=
rt of gives
me the creeps.
Mike
