Same with kubernetes ;)
It doesn't, you can't. Because you don't buy in to some nebulous clouds. You buy in to services and capabilities. This tweet sums it up the best: https://twitter.com/coryodaniel/status/1412645383876927492
I haven't used any services that have lock in, I've been able to ship services efficiently and meet deadlines, and have an abstracted compute layer.
I've also multiple times spun up demo environments with docker-compose on a bare metal machine to demo clients without networking.
Kube abstracts the compute and load balancing capabilities to a bare level. Everything else can be implemented within kube for at-cost prices.
> Everything else can be implemented within kube for at-cost prices.
Until you need something more than a bare service with nothing in it: anything from messaging to databases to storage.
Companies don't usually run a bare-bones service in a kubernetes cluster. It needs to connect somewhere and do stuff. For example, we use BigQuery on GCP. Any idea how it "can be implemented within kube for at-cost prices"?
If it's abstracted behind an agreed upon industry standard protocol (MySQL, pg, mongo connections or S3/NFS storage, etc)? Sure. If it's special sauce? No way.
My $Job-1 is migrating the stack I setup from Azure to GCP and it's been fairly painless from what I heard (only taking a few weeks to make an account, test, then move everything over).
Why, if they bring value?
> Instead use a layer that abstracts that.
How can I "abstract" BigQuery?
> If it's abstracted behind an agreed upon industry standard protocol (MySQL, pg, mongo connections or S3/NFS storage, etc)?
This still doesn't answer the question of "can be implemented within kube for at-cost prices."
BigQuery is amazing at processing enormous amounts of data at fraction of time and cost it would take, say, MySQL to process the same data. How can I "abstract it away" and "implement it at cost with kube".
Even if it's purely standard stuff like PubSubs, or Apache Beam, there are value-added options that are hard to get from other providers (or implement yourself): anything from monitoring to management to scaling to...
I'm not to crazy about vendor lock-ins myself, but "abstract everything away and you can easily move over if needed" is largely a myth.
- Some servers: you need servers to run a bare metal cluster.
- CoreOS: This is just a minimal OS that's designed to be PXE booted. Think of it as a docker container for a bare metal machine.
- Kuma: Multi-cluster mesh network. This makes it easier to write services that talk to `foobar:8080` and have it automatically fail over to other pods in other regions. I wouldn't use kuma, there's a few other options, but this is very helpful. Good service meshs will allow you to do Canary deployments. If you are multi-cluster than this sort of reliability is probably important to you.
But, an important part of this is that you don't need these if you're ok with running on another cloud's infrastructure.