How to achieve application reliability

[Sean Donelan <sean () donelan com>]

On Sat, 04 December 1999, James Smith wrote:
> The unfortunate reality is that there are a lot of businesses that need
> 99.99% reliability and uptime, but aren't big enough to get a /19.  
>
> My previous company was a credit card processing gateway.  If they went
> down, their customers were screwed.  But they hadn't even used a Class C,
> so they weren't eligible for a /19 or /20 from ARIN.  
>
> My point is that the current requirement that a network must have a large
> chunck of IP space to be multi-homed is not ideal.  According to the
> status quo, while an e-commerce company such as a credit card processor
> may be big in the business world and worth millions, but insignificant on
> the Net and left vulnerable because it can't be multi-homed.

Sigh, when you have a hammer everything looks like a nail.

There are several different ways to achieve 99.99% application reliability
which do not require 99.99% network reliability.

In your credit card application, the keyword I see is "gateway."  This implies
there is already some seperation between the front-end and a back-end application.  One method to improve application 
availablility is have multiple
gateways spread around on different networks, instead of depending on a single
gateway being multi-homed.  Clients could find a working gateway in several
different ways, pre-configured addresses, DNS and multiple A records, an
application specific discovery protocol.  "Its only a small matter of
programming."

This works best for applications with very small address requirements, such
as your credit card company which wouldn't qualify for a /19 or /20 from
ARIN.  It doesn't make sense for larger address use applications, since it
essentially requires addresses be duplicated N times.

While this lowers demand on routing table entries, it increases demand for
addresses.  Depending on which one people think we will run out of first,
will change your point of view.

Pick your trade-off.