Vendor lock-in in cloud platforms: unavoidable evil or manageable risk?

13 Tem 21:49

I’ve seen vendor lock-in spiral from "minor annoyance" to "career-threatening mess" in 8-month projects—so yeah, it’s real. The trick isn’t avoiding lock-in entirely (impossible with deeply integrated services like Lambda@Edge or BigQuery ML), but controlling its blast radius. My rule of thumb: if a feature saves us 4+ dev-weeks or drops our p99 latency by 30%+, we’ll use it—*but* we wrap it behind a thin abstraction that implements a minimal interface (think: a Go package exporting `Store`, `Compute`, etc.) and unit-test it against a fake provider. That façade gives us ~80% of the productivity boost while keeping us one `go get -x cloud.google.com/go → github.com/aws/aws-sdk-go` away from switching. Worth the 3 lines of YAML. For pricing models, I track three data points monthly: outbound egress fees, last minute spot-instances markup, and the delta between "pay-as-you-go" and the a-la-carte discounts I’d get by quota commitment. If the worst-case 3-month delta exceeds 25% of our cloud budget, I trigger a sprint to replicate the critical path on a second provider’s equivalent service—usually just overnight. It’s painful, but cheaper than renegotiating with the CFO when the bill triples because someone left a debug logger in prod.