Is it, though? I feel like the nuts and bolts of cloud services are super commoditized and I can pick up and leave whenever I want. Kubernetes on Amazon (where I am) is going to be close enough to Kubernetes on GCP, and even close enough to just buying some servers and running Kubernetes myself. I don't know all the details of how I will do load balancing when doing it myself, but I work at an ISP and I'm sure the network engineers will help with that. Overall, I'm super non-worried about cloud providers. They're like credit cards, when someone offers you more cash back or more miles or whatever, you just switch to them and don't even think about it. (Why do I even use Amazon? Sheer laziness. Having servers in my own datacenters would probably be much cheaper, but I honestly just want to program and not randomly take a week to install some critical patch to MetalLB, or upgrade the Linux kernel, or find that the Intel EM2384732FOO NICs I got have some bug where they drop every 9878th TCP session.)
That's only true if you limit yourself to the base infra offerings, or offerings that have direct mostly-compatible alternatives elsewhere.
If I use DynamoDB, I'm stuck with AWS, absent an expensive, difficult migration.
Even with Kubernetes, moving from EKS to your own cluster means spinning up your own k8s masters, which might not be in $RANDOM_DEVELOPER's wheelhouse. And IIRC AWS has their own special things for doing ingress that you'd need to change as well.
Even just going from EC2 to Google's analog might mean rewriting private tooling that specifically uses AWS APIs.
But that's not a cloud provider thing, that's just the same-old locking yourself into proprietary software that we've been doing since computers were first invented. "We have to renew the license on our Fortran compiler because nothing else has the features we use" is exactly the same "I'm stuck on DynamoDB".
As for Ingress, Amazon does have an ingress controller that configures an Application Load Balancer with kubernetes Ingress API objects. I feel like this locks you in less because again, Ingress is standardized. The problem with Ingress specifically is that the standard doesn't cover things people actually want their ingress controller to do, so every implementation has their own set of features. We use nginx... you better believe there are literal nginx.conf snippets inside the Kubernetes API objects to get things to do what we want. So this is just a case of Kubernetes being bad, not really cloud provider lockin. I'm more stuck on nginx than on Amazon.
(As for load balancers; again, Amazon has proprietary configuration parameters that won't be portable, but they don't really do anything important. You can make your Amazon load balancer terminate TLS (a bad idea), and pick which of the 3 Amazon load balancer types you want to use.
Switch to Google, and that won't work... but you also probably won't care. The Load Balancer API spec seems to do what people want, so it's relatively commoditized and you won't be sad when you switch providers. We actually have to have a wildcard certificate specifically because Amazon's classic load balancers are so bad. Would be happy to not terminate TLS in the load balancer and have Envoy or Nginx terminate TLS and ask letsencrypt for a new certificate every couple months.)
> Is it, though? I feel like the nuts and bolts of cloud services are super commoditized and I can pick up and leave whenever I want. Kubernetes on Amazon (where I am) is going to be close enough to Kubernetes on GCP
Sure Kubernetes is an open GCP product, but what about datastore, Spanner, Cloud SQL, their memory cache, urlfetch, and a host of other closed source and private services. Kubernetes seems to be the exception to the rule.
A world where front ends are deployed on a CDN and the back ends are all containers is very commodity driven. Also infrastructure being set up with code on platforms that target multiple providers like Terraform provides more ability to move systems.
It'll be really interesting to see if AWS can keep their margins in such a world.
Given that MS make huge amounts of money from email and have virtual lock in on corporate email it's very possible, but on the other hand perhaps it won't happen if everyone is, as they tend to be, using open frameworks and generally open systems.
> randomly take a week to install some critical patch to MetalLB, or upgrade the Linux kernel, or find that the Intel EM2384732FOO NICs I got have some bug where they drop every 9878th TCP session
This is hardly the case if you stick to reputable hardware and Linux distros, e.g. Dell servers + CentOS.
That's why the cloud providers are building higher-level services that ultimately speed up development and increase laziness. They're already higher than k8s now so ultimately that too is an unnecessary time suck from "just programming".
