3 ms·
>- Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. I feel like this is the most ov
by alien_at_work 9y ago
>- Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present.
I feel like this is the most overstated draw back in cloud computing by far. I don't know how most people write their code but me and most people I've ever worked with have a natural tendency to seperate out abstractions to protect you from "likely to change" parts of your application. In fact, if you use Spring boot in Java it already abstracts away a lot of the differences for various cloud scenarios.
Further, in the worst case you have to rewrite some stuff. Before you skip a solution for fear of vendor-lock-in you should attempt a cost analysis: how much will you save on these platform-specific advantages and how does that offset your cost of rewriting when some other solution becomes more desiable? How long will it take to reach break even and how does that time compare to how often software is just rewritten or abandoned in your organization anyway?
- Vinnl 9y agoI mostly share your view, and hoped not to overstate it: it's clearly a drawback, but in all, not enough to turn me away from it. By being aware of this drawback and keeping an eye on where the lock-in is, it would not be _that_ much work to rewrite the pain points to work with another provider. That said, it's still a good idea to be aware of the drawback. Unfortunately I can't edit my post anymore, but I should've noted that I'm overall happy with my serverless setup.