North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Networking Pearl Harbor in the Making
- From: Warren Kumari
- Date: Mon Nov 07 17:06:39 2005
On Nov 7, 2005, at 11:15 AM, Tom Sands wrote:
Something that often makes management understand the benefit is
explaining how much more attentive your current vendor will become
once you start implementing a competing vendor. I have had vendor
that would barely give me the time of day suddenly give me 2-3 full
time onsite SEs, a large pile of onsite spares, an additional 5-7%
blanket discount, free training credits, T-shirts and and around
$750k of "free" hardware to try and stop me moving to their
competitor (as tempting as it may be, don't just cry wolf to get free
We have that exact problem, if one considers it to be a problem.
We have only vendor X, and we've often wanted to try out others.
However, the management arguments and opinions are often difficult
Well, in that case you should make sure that you are keeping
management informed as to the deficiencies of the current vendor -
as long as you know that your replacement vendor will not have
similar issues :-)
For one, we have very few problems that are ever seen by customers
So, convincing them that diversity could buy us better reliability
is near impossible. Then the additional cost of training and spare
Talk to the new vendor - most vendors will be more than happy to give
you free training credits to get you as a new customer, same goes for
spares. Play up the free training to management - explain the
importance of ongoing education, how eager the network engineers are
to learn more, etc. This way they can give everyone training with no
out of pocket expense!
We also have the customer opinions/perception to deal with
(accompanied by marketing), where they think having a "Cisco
Powered Network" would automatically mean it's the best.
I think that you might be pleasantly surprised by the increasing clue
factor of your customers - they will understand that best-of-breed
means that you get to choose the best device for the purpose. Your
customers are involved in technology - while some of them like Linux
and some like Windows, they all understand that different
technologies have different strengths and weaknesses (ok, so maybe a
true Linux zealot won't agreee that Windows is useful for anything -
maybe emacs vs vi... hmmm, maybe not that either...)
With multiple vendors you get to choose the device that best fits the
requirements - if devices from multiple vendors fit equally well, you
get to choose the one with the fewest bugs. You suddenly also have a
lot more pull with your vendor to get your current "bugs" addressed.
Despite not having service impacting problems, we do have a number
of "bugs", however would those issues get better or worse when
having to deal with multiple vendors, various platforms per vendor,
I personally haven't found interoperability to be a major issue
(providing you are not relying on any proprietary protocols) - the
ability to choose the best device for the task more than pays for
any interoperability concerns - you also get to call up the vendors
and say "Fix this or I'm replacing it with a $other_vendor box".
There are also some things that certain vendors just don't do well -
being limited to just choosing devices from a single vendor limits
what you can do.
Well, the last time I just whined a lot ? <grin>
We covered only a couple of these areas, and maybe addressing some
of the others might make a better case.
Seriously, we actually put together a presentation that described
a series of major events that have occurred through the use of
monoculture networks/systems and stated that for many financial/
security reasons it is best to maintain at least two vendors.
We covered the following
o Security Implications: How monoculture networks/operating
systems are prone to attack.
o Financial Impact: How managing multiple vendors can reduce
long term expense.
o Stability: How monoculture networks/systems are prone to
network/ system wide failures.
o Viability: How existing technology is capable of interop and
how we, the engineering team, were capable of making it happen.
o Customer demand: How our customers actually "felt better" about
our service as a result of it's genetic diversity.
Chief Network Engineer
Rackspace Managed Hosting
"He who laughs last, thinks slowest."