Are Business Needs Just Excuses for Vendor Shenanigans?

Every now and then I call someone’s baby ugly (or maybe it was their third cousin’s baby and they nonetheless feel offended). In such cases a common resort is to cite business or market needs to prove how ignorant and clueless I am. Here’s a sample LinkedIn comment talking about my ignorance about the need for smart NICs:

The rise of custom silicon by Presando [sic], Mellanox, Amazon, Intel and others confirms there is a real market need.

Now let’s get something straight: while there are good reasons to use tons of different things that might look inappropriate, irrelevant or plain stupid to an outsider, I don’t believe in real market need argument being used to justify anything without supporting technical facts (tell me why you need that stuff and prove to me that using it is the best way of solving a problem).

For example, Amazon has a real need for smart NICs to support bare-metal server instances in their Virtual Private Clouds. That doesn’t justify them being used in any other scenario (see also: you’re not Google).

Just because someone manages to sell something, and other vendors jump on the same bandwagon because their product managers smell new markets, doesn’t mean that anyone really needs it, or that the challenge the new stuff is supposedly solving couldn’t have been solved in a simpler or better way. Let me illustrate this claim with a quick digression into my favorite topic: using long-distance vMotion for disaster recovery (because it wouldn’t work for disaster avoidance anyway).

Business continuity is the unquestionable real business need here.

That business need could be implemented with proper application architecture, disaster avoidance or disaster recovery. Which one of these is still acceptable is another business decision; what can be reasonably done based on the current state of company’s IT, and applications the business runs on, is already a technology fact that cannot be avoided no matter how much pixie dust you sprinkle on it. For example, there’s absolutely no way to implement 99.999% service availability if your application stack rides on a single database instance… and here’s the first opportunity for a vendor to jump in and start selling unicorn farts.

Remember fault-tolerant servers - the super-expensive thingies that had full hardware redundancy, promising non-stop operation of your business-critical applications? Or the software equivalent promoted by VMware? There’s just a bit of a problem with that approach: most failures experienced today are software failures, and two copies of a buggy program running in sync on two independent pieces of hardware will consistently crash at exactly the same time. Some of those fault-tolerant servers lived up to vendor promises because the vendor also shipped the properly designed operating system, database servers, and transaction handling environments. Cheap knockoffs sold by virtualization vendors were just snake oil… and whoever pointed that out was usually faced with the real business need wall of denial.

But wait, it gets worse… we could use stretched VLANs and long-distance vMotion to implement disaster recovery (or so the $vendor consultants told us). At this point we’re way beyond the sane discussions of actual business needs. The whole idea was created by vendor marketers to sell more of their complex products, and happily adopted by most everyone in enterprise IT because it conveniently allows them to push the problem down the stack until the brown substance lands in the networking team, which is then blamed for being too rigid and too expensive… and ripe to be replaced by another $vendor magic, this time either software-defined, intent-based, or machine-learned.

Long story short: PLEASE, do your homework, and don’t ever use the some vendors are making it, so there must be a real market need for it or some people are using it, so there must be a real business need for it argument. You just might end with an egg on your face (although most people using these arguments happen to be egg-blind so they wouldn’t ever realize what happened).

Addendum based on a tweet by Andrew Yourtchenko:

Obviously most of the products, services and solutions out there solve a real or perceived need (and there’s sometimes a huge gap between the two).

What I’m pointing out in this rant is the reverse reasoning along the lines “vendor X is doing something, which confirms there’s a real market need for it”. I’ve been in IT too long, and seen how the startup/VC sausage is made, to believe that fairy tale… and even when it’s true, it doesn’t necessarily imply that you need whatever vendor X is selling.

For example, just because a mining operation needs huge trucks, it doesn’t mean that everyone else needs them as well, regardless of what the truck manufacturers would love you to believe.


  1. > Amazon has a real need for smart NICs to support bare-metal server instances

    According to teh Internets, Nitro predates .metal instances by ~4 years, having been launched in 2013 to support the C3 instance types.

    Apart from the hardware offload/acceleration, there's real value in having an ability to handle network security policy enforcement outside of the VM OS or a hypervisor.

  2. Why does this article make me think to SRv6 ... I think this is the perfect example where vendors try to push hard for a feature, claiming "a lot of customers ask for it", whereas almost everybody still wonder what business cases it solves.

Add comment