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.

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.

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

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

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.

> Honestly I wonder, who the hell buys these overpriced networking appliances?

people that need to switch more packets than what you buy off of newegg can handle.

edit: oh that and when you have a network of thousands of routers and switches that you want to centrally manage in a way that "mass ssh" doesn't scale to and you just want to buy the management software from someone that has written it before and not spend a while getting the software wrong before you get it right.

if you can count the number of routers you need in your head, you probably should just be using beige boxes with a commodity OS...

I think it's mostly about support and SLAs. Some people like to know that if something goes wrong there's a vendor they can shout at.

Sadly though, shouting at a vendor doesn't fix your issues within a couple of hours, and downtime can be a pain.

Running Linux/*BSD/Whatever on off-the-shelf boxen which you can pickup everywhere (and have cheap spares) and fix yourself will let you get back online quickly.

If it's not your money you're spending, then the support contract helps take the heat off you when there are problems. Also, the junior staff can do things when there are problems and you're not in the office.

And it is easier to get someone external, e.g. from an MSP, in to fix or rebuild something.

> Sadly though, shouting at a vendor doesn't fix your issues within a couple of hours

It does if your support contract is expensive enough.

Medium sized stable businesses. Small shops can't afford them. Large shops (Google, Facebook) hire people and use open source software.

At the moment, network switching and routing with open source products + commodity servers can't scale like Cisco and Juniper...if you want to have a fairly standard network (OSPF, BGP, etc).

Google, for example, is able to use commodity hardware because what they are routing works with a non-traditional setup...specifically a Clos network. That works for them only because their app is designed in a way that it can served up like that. It would not work for the typical kinds of traffic that you see at a normal company.

At a certain scale, barring unusual exceptions, you really do have to go with someone like Juniper/Cisco, as the ASIC based acceleration and other features aren't there in the commodity world.

There's certainly some things in progress that may change all of that, like Intel's DPDK, QuickAssist, etc.

The networking hardware that Facebook builds uses ASICs: https://code.facebook.com/posts/717010588413497/introducing-...

For core routing on fast networks, I tend to agree. Outside of that, commodity hardware and open source work just fine.

I would add certain use cases of firewalls to that as well.

Facebook builds their own networking hardware (which runs open source software):

https://code.facebook.com/posts/843620439027582/facebook-ope...

Pointy Haired Bosses who need something to deflect blame onto in case things screw up. It's easier to assign that to an outside vendor than one's own subordinates that they are directly responsible for.

I've seen this many times and it will continue to happen.

The same PHB who gets wined and dined by the sales critters from said vendor down at the country club...

> Commodity hardware and general-purpose systems win every time.

What's latency like on commodity hardware vs dedicated equipment? I've no experience but would expect the dedicated hardware to be better. BSD is a monolithic kernel, so you'd have the overhead of passing through the for each of the routed packets, right?

The packets never go out of the kernel, latency seems fine on my BSD router.

What word should be after "through the" in your post ?

Sorry. "Kernel". Through the kernel. But you were there already - I hadn't twigged that there's no need to jump out of userland in the first place.

> through the [?] for each

BSD pf is interpreted by a kernel module in kernel mode. There is no e.g. kernel / user transition involved.

Many proprietary databases provide significant scalability and/or feature benefits over their open source counterparts. Whether the customer in question actually needs those capabilities is of course often questionable, but they do provide real benefits.

I once worked for a guy who wouldn't buy anything that didn't say Cisco on it, even when the networking guys made a solid case for something different. I often wondered if it was more than a "nice dinner" that he was getting.

Remember that "nobody ever got fired for buying IBM".