Networking Pearl Harbor in the Making

Mon Nov 7 22:05:36 UTC 2005

On Nov 7, 2005, at 11:15 AM, Tom Sands wrote:
>
> 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  
> to sway.

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  
stuff though!)

>
> For one, we have very few problems that are ever seen by customers  
> or management.

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 :-)

> So, convincing them that diversity could buy us better reliability  
> is near impossible.  Then the additional cost of training and spare  
> equipment.

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...)

>
> 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,  
> and inter-operability?

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.

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.

Warren

>
>
>> Well, the last time I just whined a lot ? <grin>
>> 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.
>>
>
> We covered only a couple of these areas, and maybe addressing some  
> of the others might make a better case.
>
>
>
>> Regards,
>> Blaine
>>
>
> -- 
> ------------------------------------------------------
> Tom Sands
> Chief Network Engineer
> Rackspace Managed Hosting
> (210)447-4065
> ------------------------------------------------------
>
>

-- 
"He who laughs last, thinks slowest."
     -- Anonymous