3 ms·

Really? To turn the question on its head a bit, Amazon has EKS, and they don't seem to be any worse off for having not invented it.

harpratap 3y ago
GKE in general seems to be doing better than EKS though. They have a lot of things right and EKS seems to be playing catch-up. For example if you look at any Multi-cluster Kubernetes setup by AWS it's just a giant duct-tape rather than a ground-up solution. GKE worked on fundamentals first like multi-cluster endpoints, multi-cluster services, multi-cluster ingress, multi-cluster config-sync and now bringing it all together under GKE Enterprise.
- hn_throwaway_99 3y ago
  Thanks, this is helpful context, most appreciated.
- danpalmer 3y ago
  I did a migration to GKE at a previous company and it was basically great to work with. At the time we had a few teething issues with the most edge-casey bits of our system, to do with getting ingress and CDNs to work well together I think. The end result was a little more manual Terraforming than would have been ideal, but it all worked, and I believe the improvement needed from GCP was on their roadmap and came a few months later. GKE (with Autopilot) is firmly set in my "day 1 toolbox" if I were to start a new company, assuming K8S was the right tech choice.
paulddraper 3y ago
EKS came years later.
llarsson 3y ago
The point of Kubernetes was to make "run this software on a cloud" trivially compatible across clouds. No specialized code that is needed for load balancers, storage, networking... you should be able to take your containerized application and the set of YAML files that describes what you want to do, and they work on "any" cloud. As long as you don't rely on implementation details like a specific Ingress Controller that needs special annotations, this is exactly what Kubernetes does, and the reason why you have Helm Charts that don't need to take into consideration which the underlying cloud is. Going back to what we had before, you had to be very aware of exactly which cloud provider you'd use. And since AWS had about 80+% of the market then, that meant that instructions for how to run things on Google's cloud were not very good, if they existed at all.
- paulddraper 3y ago
  > The point of Kubernetes was to make "run this software on a cloud" trivially compatible across clouds. That was not the point of Kubernetes. And if it was, it did not realize that point for many years.
marcinzm 3y ago
EKS came later and for a long time was basically barely working. Better now but still has odd things like no free tier. The problem is that GCP for some reason just doesn't align with many corporate customer requirements (ie: support, stability, never kill anything, available resources, etc.) and an engineer friendly product (GKS) does nothing to alleviate that. It makes GCP better in an area it was already better in and doesn't at all fix the tangential reason companies actually avoid it (or rather from what I hear either migrate off of GCP eventually or use it as just a secondary cloud provider).

harpratap 3y ago

GKE in general seems to be doing better than EKS though. They have a lot of things right and EKS seems to be playing catch-up. For example if you look at any Multi-cluster Kubernetes setup by AWS it's just a giant duct-tape rather than a ground-up solution. GKE worked on fundamentals first like multi-cluster endpoints, multi-cluster services, multi-cluster ingress, multi-cluster config-sync and now bringing it all together under GKE Enterprise.

hn_throwaway_99 3y ago
Thanks, this is helpful context, most appreciated.
danpalmer 3y ago
I did a migration to GKE at a previous company and it was basically great to work with. At the time we had a few teething issues with the most edge-casey bits of our system, to do with getting ingress and CDNs to work well together I think. The end result was a little more manual Terraforming than would have been ideal, but it all worked, and I believe the improvement needed from GCP was on their roadmap and came a few months later. GKE (with Autopilot) is firmly set in my "day 1 toolbox" if I were to start a new company, assuming K8S was the right tech choice.

paulddraper 3y ago

EKS came years later.

llarsson 3y ago

The point of Kubernetes was to make "run this software on a cloud" trivially compatible across clouds. No specialized code that is needed for load balancers, storage, networking... you should be able to take your containerized application and the set of YAML files that describes what you want to do, and they work on "any" cloud. As long as you don't rely on implementation details like a specific Ingress Controller that needs special annotations, this is exactly what Kubernetes does, and the reason why you have Helm Charts that don't need to take into consideration which the underlying cloud is. Going back to what we had before, you had to be very aware of exactly which cloud provider you'd use. And since AWS had about 80+% of the market then, that meant that instructions for how to run things on Google's cloud were not very good, if they existed at all.

paulddraper 3y ago
> The point of Kubernetes was to make "run this software on a cloud" trivially compatible across clouds. That was not the point of Kubernetes. And if it was, it did not realize that point for many years.

marcinzm 3y ago

EKS came later and for a long time was basically barely working. Better now but still has odd things like no free tier. The problem is that GCP for some reason just doesn't align with many corporate customer requirements (ie: support, stability, never kill anything, available resources, etc.) and an engineer friendly product (GKS) does nothing to alleviate that. It makes GCP better in an area it was already better in and doesn't at all fix the tangential reason companies actually avoid it (or rather from what I hear either migrate off of GCP eventually or use it as just a secondary cloud provider).