G'day Leo, On 28 December 2016 at 07:10, Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Fri, Dec 23, 2016 at 03:36:10PM -0500, Chris
Grundemann wrote:
If you have a case study, lesson learned, data point, or even just a strong opinion; I'd love to hear it!
I think the high level items are pretty clear here:
[...]
2 Vendor
Can be implemented multiple ways, for instance 1 vendor per site alternating sites, or gear deployed in pairs with one from each vendor up and down the stack.
Harder to implement, staff needs to know both, all configs must be done for both, vendors will always blame the other vendor for interop issues. Twice as much chance of needing to do emergency upgrades.
More resilliance to a single bug, can compare real world performance of the two vendors. Both vendors will compete hard to get more of your business, but have a harder time justifing bennies internally due to lower spend. [...]
I agree with many of the points you made but here's another data point on the topic of bugs -- I watched a presentation [1] from a couple of guys from Facebook at AusNOG 2016 and one of the takeaways from their talk was that "multivendor is hard". When you have two vendors, you get Vendor A's bugs, Vendor B's bugs, and the Vendor A+B interop bugs. In theory this only gets worse with 3+ vendors. Cheers, Dale [1] < http://www.ausnog.net/sites/default/files/ausnog-2016/presentations/2.10.6_Z...