[detaro]

People who want to have support by a large vendor. If your DIY-setup fails you can't blame a vendor. In theory using the same kind of appliance as everybody else means you can easily find an networking guy to work with it, people who are good at both traditional networking gear and BSD/Linux are harder to find. If a dedicated box fails you can just have someone with some experience plop a new one in, reapply the configuration and be done. Correctly replicating a DIY setup is harder, especially if the person building it didn't do a perfect job at documenting it.

Appliances promise all sort of fancy features that might be hard to exactly replicate yourself (if you actually need them often is a different question, but often networking isn't exactly in a position to say "no" to such requests). Although there is more and more a trend of manufacturers also offering the software for virtual environments, many appliances are x86-servers anyways.

+ as the article mentions all those cases where you need specialised hardware, e.g. routing/switching at high speeds, or working in special environments.

[tsmarsh]

Specialist hardware, supported by specialist network engineers should be the smart choice. It invariably leads to a monoculture.

If you buy Cisco and a Cisco specialist, you'll be buying Cisco for as long as the specialist is employed, regardless of any leaps or bounds Juniper et al. make.

Same deal with databases. Oracle is often a smart choice, but so is Postgres, SQL Server, Cassandra, Redis. If I've hired a DBA with 10 years of Oracle experience, the chances are that any move away from Oracle will rub against "Why hire an oracle specialist if you're not going to use them?".

My hope is always "Because they're smart, genuinely understand storage and retrieval and will learn the other systems faster than a smart generalist". But that isn't how it plays out.

I would hope that hiring a specialist means that, at some point, they come to you and say "So, I think I can save us money and increase uptime if we move to X". It happens in software all the time. Its hard to keep devs on any one particular platform before they get twitchy (also a problem).

In my mind buying Cisco is like using Heroku, Rails, Ember. All fine tools, that help you get a job done quickly whilst you figure out what your real problems are but shouldn't be seen as the final solution.

[EvanAnderson]

I've heard the "blame a vendor" argument again and again in my life, but I have yet to see this "blame" ever occur. Granted, I'm dealing with small and medium-sized companies, but I've never seen any kind of tangible financial outcome from "blaming" a vendor (other than that vendor not getting future sales).

[profeta]

"nobody gets fired for buying IBM"

https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

Everyone who says anything like "blame the vendor", have just drank too much marketing cool-aid.

[detaro]

Not tangible financial outcome for the vendor. But for the employee suggesting it, who doesn't have to explain why "his" "cobbled together thing" doesn't work, but can point to all kinds of outside validation for the choice, even if it doesn't work out.