On Mon, Mar 31, 2008 at 11:24 AM, <michael.dillon@bt.com> 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