[140227] in North American Network Operators' Group
Re: Amazon diagnosis
daemon@ATHENA.MIT.EDU (George Herbert)
Thu May 5 13:52:25 2011
In-Reply-To: <a5e145b8-10ad-4d1f-96e5-c4d1866d3331@s2g2000yql.googlegroups.com>
Date: Thu, 5 May 2011 10:52:19 -0700
From: George Herbert <george.herbert@gmail.com>
To: Ryan Malayter <malayter@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Thu, May 5, 2011 at 10:45 AM, Ryan Malayter <malayter@gmail.com> wrote:
>
>
> On May 1, 2:29=A0pm, Jeff Wheeler <j...@inconcepts.biz> wrote:
>
>> What it really boils down to is this: if application developers are
>> doing their jobs, a given service can be easy and inexpensive to
>> distribute to unrelated systems/networks without a huge infrastructure
>> expense. =A0If the developers are not, you end up spending a lot of
>> money on infrastructure to make up for code, databases, and APIs which
>> were not designed with this in mind.
>
> Umm... see the CAP theorem. There are certain things, such as ACID
> transactions, which are *impossible* to geographically distribute with
> redundancy in a performant and scalable way because of speed of light
> constraints.
That specific example depends on how order-dependent your consistency
constraint is; you can have time-asynchronous locally ACID changes
across databases which are widely separate. If your consistency
requires order synchronicity across the geographic DB cluster then
this is a potential epic fail, of course.
The general point is valid.
Being able to tell if your application *really* does require strict
consistency or not, and if it requires strict ordering or not if it
requires strict consistency, is unfortunately beyond most line-level
system designers. A lot of people guess wrong in both directions, and
either cripple the app's performance unnecessarily or end up with
dangerous failure modes inherent in the architecture.
--=20
-george william herbert
george.herbert@gmail.com
