Use k8s exactly for the reason of either being federated across cloud providers or simply portable across cloud providers. You can't do that with vendor specific solutions e.g. elastic beanstalk
What keeps people highly coupled with could provider is not where their code is running but rather other "here only" solutions like custom DBs or infrastructure.
You can rewrite code deployment script for any provider in few days worth of work, but switching between other tech stack will be near impossible.
> You can rewrite code deployment script for any provider in few days worth of work
I've directly experienced the counter example to this at a major SaaS company. Beyond methods you'd use for < 20 machines this just isn't true. Your orchestration of machine lifecycles will be tied up into the particular cloud no matter what kinds of abstractions you try to put in. Unless you start running on multiple clouds or you write to k8s instead of the cloud APIs, you will be locked in.
> What keeps people highly coupled with could provider is not where their code is running but rather other "here only" solutions like custom DBs or infrastructure.
I agree, and the advent of k8s adoption is one less thing that locks you into a provider.
