Least Common Denominator APIs

Often, our instinct is to build for optionality. What if we change databases? What if we change clouds? We target the Least Common Denominator (LCD) interface to avoid vendor lock-in and make sure our software is portable – after all, Optimization is Fragile. LCD interfaces look like targeting the S3 API, a generic PubSub implementation, or vanilla ANSI SQL.

LCD interfaces are good enough most of the time, but when we need to run a specialized workload, sometimes they don't perform how we'd like. We could solve our problem quickly by narrowing the API – coupling it to a specific cloud or managed service, but that destroys our optionality. Here, you should probably fight your instinct to stick with the pure implementation and weigh the trade-offs – how many developer-hours and pain can you save by narrowing the interface?

Optimization and optionality are inherent trade-offs. There's a way to architecture services to be efficient and generic but also practical.

But switching costs are real and shouldn't entirely be forgotten. If you have to use a platform-specific feature or product, isolate the lock-in as best you can, or chart a path to a more generic interface (Don't Use Kubernetes, Yet). You might migrate some workloads to a specialized database or use a different cloud for a particular function (e.g., AI APIs on Google Cloud).