Here’s an interesting tidbit from “Last Week in AWS” blog:

From a philosophical point of view, AWS fundamentally considers an API to be a promise. Services that aren’t promoted anymore are still available […] Think about that for a second - a service launched 13 years ago is still actively supported to the point where you can use it today.

Compare that to Killed By Google graveyard, and you might understand why I’m a bit reluctant to cover GCP in my webinars.

But of course it’s not just Google. When I started the Data Center Fabrics webinar in 2011, Cisco talked about VSS (Catalyst 6500) and vPC (Nexus switches). In the meantime they went through (at least):

• FabricPath
• TRILL-will-be-there (but they never delivered);
• Dynamic Fabric Automation (DFA)
• ACI
• VXLAN with EVPN

Hardware platforms fared no better. I have to completely redo the “Cisco hardware overview” slides in the Data Center Fabrics webinar every time I’m running an update session (currently ~18 months apart) because they change gears so fast. In the eight years doing the webinar I’ve seen (ignoring various attempts to revive the Catalyst zombies):

• Numerous Nexus 3000 switches (but those are usually deal-of-the-week platforms);
• Nexus 4000, 5000, 5500, 6000
• Nexus 7000 and 7700
• Old (Broadcom) and new (CloudScale) Nexus 9000 switches

How many of those switches are still being sold? Occasionally the situation gets so bad that Russ White loves to joke that some of his former customers resembled archeological digs.

I know it’s easy to make fun of Cisco - they are a large conglomerate of competing business units - but what about an open-source development team?

Some open-source projects resemble Brownian motion. This is how Ansible networking team decided to deal with user authentication on network devices:

• Let’s add user and password parameters to every network module (even though Ansible core had authentication figured out long ago);
• Oh ****, people hate that. Let’s replace that with provider parameter.
• Hmmm… did you notice Ansible already knows about usernames and passwords? How about we use those and deprecate user, password and provider module parameters? But of course we’ll use our own stuff (authorize networking module parameter) to enter enable mode.
• Here’s another idea: how about using become task-level parameter that Ansible had for years to enter enable mode… but of course with a twist: you have to use become_method: enable because network devices have so many ways of entering enable mode (hint: most of them have exactly one).

Then there’s the local connection and network_cli connection plugin, and multiple ways of dealing with REST API and NETCONF transports… and the idea to use generic network modules that survived just a few Ansible releases before it was replaced with something completely different.

Moral of these stories: maybe you should take long-term product stability into account when selecting a new vendor. Randy Bush called the behavior I described “throwing spaghetti at the wall” and supposedly it’s a fun activity unless you happen to be the wall. Just saying…