I think it depends on the type of vendor lock-in -- sure, the trade off of having a managed Postgres instance is obvious, but it becomes less obvious to me when you're using things like a proprietary queueing or deployment service.
Writing service API integration code instead of code that interfaces directly with the technology that service is doing makes code quite brittle. If/when the vendor deprecates the service, introduces backwards incompatible changes, or abandons development of the product, you're left on the hook to engineer your way out of that problem. Often times that effort is equal to or greater than the effort of an in-house solution in the first place.
I had the same mentality as you until this happened to the SaaS product I work on for a few different services. Now at very least I try to make sure solutions are cloud agnostic.
My use case is that for the past 5 years I’ve built several API integrations in a vendor agnostic way. We never changed vendors.
Actually, we did once and we found that our abstraction was so tightly coupled to the underlying API that we had to remake it anyway. The core concepts between those APIs were just too different.
And I’ve had at least 2 cases where our attempt at being vendor agnostic made the integration completely fail and never work right. To the point the vendor told us “You’re holding it wrong, please stop”
Writing service API integration code instead of code that interfaces directly with the technology that service is doing makes code quite brittle. If/when the vendor deprecates the service, introduces backwards incompatible changes, or abandons development of the product, you're left on the hook to engineer your way out of that problem. Often times that effort is equal to or greater than the effort of an in-house solution in the first place.
I had the same mentality as you until this happened to the SaaS product I work on for a few different services. Now at very least I try to make sure solutions are cloud agnostic.