The GKE documentation says: "There’s no vendor lock-in, you’re free to take your workloads out of Container Engine and run them anywhere Kubernetes is supported, including on your own on-premise servers."<p>Still, GKE is a managed environment for Kubernetes and I was wondering how difficult it would be to take your workloads out of GKE after 2-3 years and run them on your own hardware.
Disclaimer: I work at Google Cloud on GKE/Kubernetes.<p>My personal opinion is that, how closely you're integrating with storage systems (e.g. databases and blob stores) and APIs (e.g. machine learning, pub/sub, load balancing) of the cloud platform you are running on.<p>Kubernetes already does a great job abstracting the compute infrastructure and networking topology you have on the cloud provider away. There's a lot of work going on in the Kubernetes Service Catalog[1] to make it even more platform-agnostic. With Service Catalog, you will be able to say "I want a Redis instance" and your underlying infrastructure will be able to provide you a Redis instance, you will no longer worry about integrating to GCP, Azure, AWS separately. Service Catalog sounds a lot promising as a step towards eliminating vendor lock-in. That said, it is still a work-in-progress.<p>Note that none of this offer a migration path for your existing databases etc. But I am seeing that many businesses are able to migrate their compute workloads between platforms and on-prem to the cloud a lot easier compared to the pre-Kubernetes era.<p>[1] <a href="https://github.com/kubernetes-incubator/service-catalog" rel="nofollow">https://github.com/kubernetes-incubator/service-catalog</a>