3 ms·
This sounds a little like the big sites I've worked on that spent immense amounts of money on being database-agnostic, "so we can switch from Mysql/Postgres/Ora
by zbentley 5y ago
This sounds a little like the big sites I've worked on that spent immense amounts of money on being database-agnostic, "so we can switch from Mysql/Postgres/Oracle to $other if we want".
Nobody ever wanted to switch; the expertise in using one provider created immense inertia. And even when a few folks (fans of $other working side-of-desk) tried to make a proof-of-concept swap, it turned out that the code was anything but agnostic and dependent on the first provider it was built for in pervasive and fundamental ways.
So, too, with service providers and partner businesses. Spending time/money on being able to switch suppliers and keeping all your eggs from being in one basket is a waste of time: you won't switch voluntarily, and if you ever have to switch involuntarily it'll still be about as difficult as it would have been if you hadn't prioritized redundancy/diversity.
- mytailorisrich 5y agoAt a minimum, implementing an abstraction layer around all external services really is software development 101. For some services it's also not just being able to switch, it's having more than one used in production. If you manage that then switching is no longer a problem since it's already implemented! That's important for key services.