Kube gives you portability. You can move away if you need to. Very difficult to do that with AWS Fargate.

> Kube gives you portability. You can move away if you need to.

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

In my experience I haven't bought into anything like that. The most I've done is paid for a hosted DB which is a complexity I could offload to many different companies.

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.

> Kube abstracts the compute and load balancing capabilities to a bare level.

> 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"?

Don't use services that lock you in. Instead use a layer that abstracts that. In the past I think I have heard of people using Presto for similar operations and that can be self hosted. I would never build a company on top of tech I can only get from one place. Regardless of the layer in the stack.

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).

> Don't use services that lock you in.

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.