4 ms·

Obviously the cloud vendors will try hard to foist lock-in on customers, and savvy customers should be trying hard to avoid those proprietary high level service

Obviously the cloud vendors will try hard to foist lock-in on customers, and savvy customers should be trying hard to avoid those proprietary high level services But what percentage of cloud programmers are wise to this? The individual programmers make the decisions that cause lock in Cloud vendors know how locked in you are when you negotiate discounts, but by that time the key decisions are long past

simonh 5y ago
Erik's contention is that the second part after the 'and' isn't obvious at all. There's no point avoiding lock in because you're locked in anyway. You might as well just use the features and services that best suit your needs, because that way you'll make best use of your developer time and resources. I think he's right, the costs of any migration to a new cloud service are so high that it's pointless making gestures pretending you're preparing for it.
- paulsutter 5y ago
  There are huge discounts available. You don’t get them by moving, you get them because you’re not locked in
  - simonh 5y ago
    Every now and then you need to stand up a completely new system, or replace an existing system. At those times you get to pick what platform you will build it on, and Amazon wants you to pick AWS. Therefore AWS needs to be competitive. In the vast majority of cases that decision really isn't going to be influenced by whether your existing system on AWS does or doesn't use Amazon specific tech. If you're "moving" your service from AWS to Azure those kinds of implementation details just don't matter, in most cases you're effectively going to build a replacement system and not really migrate an existing one. The costs of such a migration would in most cases dwarf any possible savings, no matter how carefully you tried to avoid lock-in. I'm obviously generalising a fair bit, but the exceptions are likely to be less complex systems that are perfectly fine using fairly generic services.

simonh 5y ago

Erik's contention is that the second part after the 'and' isn't obvious at all. There's no point avoiding lock in because you're locked in anyway. You might as well just use the features and services that best suit your needs, because that way you'll make best use of your developer time and resources. I think he's right, the costs of any migration to a new cloud service are so high that it's pointless making gestures pretending you're preparing for it.

paulsutter 5y ago
There are huge discounts available. You don’t get them by moving, you get them because you’re not locked in
- simonh 5y ago
  Every now and then you need to stand up a completely new system, or replace an existing system. At those times you get to pick what platform you will build it on, and Amazon wants you to pick AWS. Therefore AWS needs to be competitive. In the vast majority of cases that decision really isn't going to be influenced by whether your existing system on AWS does or doesn't use Amazon specific tech. If you're "moving" your service from AWS to Azure those kinds of implementation details just don't matter, in most cases you're effectively going to build a replacement system and not really migrate an existing one. The costs of such a migration would in most cases dwarf any possible savings, no matter how carefully you tried to avoid lock-in. I'm obviously generalising a fair bit, but the exceptions are likely to be less complex systems that are perfectly fine using fairly generic services.