From: Christopher Morrow (no email)
Date: Tue Apr 01 2008 - 00:27:08 EDT
On Mon, Mar 31, 2008 at 11:24 AM, <> wrote:
> Let's make it simple and say it in plain English. The users
> of services have made the decision that it is "good enough"
> to be a user of a service hosted in a data center that is
> remote from the client. Remote means in another building in
> the same city, or in another city.
>
> Now, given that context, many of these "good enough" applications
> will run just fine if the "data center" is no longer in one
> physical location, but distributed across many. Of course,
> as you point out, one should not be stupid when designing such
> distributed data centers or when setting up the applications
> in them.
I think many folks have gotten used to 'my application runs in a
datacenter' (perhaps even a remote datacenter) but they still want
performance from their application. If the DC is 20ms away from their
desktop (say they are in NYC and the DC is in IAD which is about 20ms
distant on a good run) things are still 'snappy'. If the application
uses bits/pieces from a farm of remote datacenters (also 20ms away or
so so anywhere from NYC to ATL to CHI away from IAD) latency inside
that application is now important... something like a DB heavy app
will really suffer under this scenario if locality of the database's
data isn't kept in mind as well. Making multiple +20ms hops around for
information is really going to impact user experience of the
application I think.
The security model as well would be highly interesting in this sort of
world.. both physical security (line/machine/cage) and information
security (data over the links). This seems to require fairly quick
encryption in a very distributed envorinment where physical security
isn't very highly assured.
>
> I would assume that every data center has local storage available
> using some protocol like iSCSI and probably over a separate network
> from the external client access. That right there solves most of
> your problems of traditional jobsets. And secondly, I am not suggesting
> that everybody should shut down big data centers or that every
> application
> should be hosted across several of these distributed data centers.
> There will always be some apps that need centralised scaling. But
> there are many others that can scale in a distributed manner, or
> at least use distributed mirrors in a failover scenario.
>
ah, like the distributed DR sites financials use? (I've heard of
designs, perhaps from this list even, of distributed DC's 60+ miles
apart with iscsi on fiber between the sites... pushing backup copies
of transaction data to the DR facility) That doesn't help in scenarios
with highly interactive data sets, or lower latency requirements for
applications... I also remember a SAP (I think) installation that got
horribly unhappy with the database/front-end parts a few cities apart
from each other over an 'internal' network...
> In addition, there is a trend to commoditize the whole data center.
> Amazon EC2 and S3 is not the only example of a company who does
> not offer any kind of colocation, but you can host your apps out
> of their data centers. I believe that this trend will pick up
asp's were a trend in the late 90's, for some reason things didn't
work out then (reason not really imporant now). Today/going-forward
some things make sense to outsource in this manner, I'm not sure that
customer critical data or data with high change-rates are it though,
certainly nothing that's critical to your business from an IP
perspective, at least not without lots of security thought/controls.
When working at a large networking company we found it really hard to
get people to move their applications out from under their desk (yes,
literally) and into a production datacenter... even with offers of
mostly free hardware and management of systems (so less internal
budget used). Some of that was changing when I left, but certainly not
quickly.
it's an interesting proposition, and the DC's in question were owned
by the company in question, I'm not sure about moving off to another
company's facilities though... scary security problems result.
-Chris
|
|
|