3 ms·

Wait what? Good support? Not in my experience. Leader in k8s? Not for production. I defy you to do a gcp gke deployment without using beta or alpha features (t

Wait what? Good support? Not in my experience. Leader in k8s? Not for production. I defy you to do a gcp gke deployment without using beta or alpha features (that specifically say don’t use this for production). Stackdriver error reporting springs to mind. And working with SSL certs/let’s encrypt is a close second. If you want a couple more peeves for your list how about documentation? I regularly find documentation heavy on theory light on specifics. GCP is my favorite thing that is almost good enough to use. I’m hoping the change of leadership actually improves things. GCP could stand to re-focus on a “customer first” philosophy.

metildaa 8y ago
Lack of IPv6 support is what keeps us off GCP or AWS, HTTP fronting is great, but when it comes to realtime interactive streams to mobile devices, the ability to save significant latency and avoid the hot mess of CGNAT is invaluble.
- becauseiam 8y ago
  IPv6 is not a first-class protocol on AWS, but it is absolutely doable for most scenarios. It still requires having something of a dual-stack network in place (you definitely can't have a v6 only network of anything meaningful).
- halbritt 8y ago
  Where do you go for first class IPv6 support? I find it a bit ironic that the mobile and web side of the house are pushing very heavily for IPv6 adoption and yet they expect their cloud customers not to need it.
  - metildaa 8y ago
    We're on OVH for most things that aren't latency sensitive. For things where every millisecond counts for quality, we either find a 2nd tier cloud provider with decent peering to most of our end users in that area, or less common colo or rent a server (some areas just don't have 2nd tier cloud providers).
regnerba 8y ago
I feel like their support has really been improving. 4 years ago it felt like it was non-existent. Been pretty happy with it the last few times I have had to contact them. I don't think we use any Alpha features, I know there are a couple Beta APIs from Kube we use, but we would be using those no matter where we ran our Kube deployment. We use fluentd for our log collection and Prometheus for metrics and alerting combined with Elastalert. So don't have any experience with Stackdriver. Why is working with SSL certs an issue? We use the NGINX Ingress with cert-manager and have yet to have an issue. We only have a couple domains pointed at the cluster though, not sure if thats where your issue comes from. The two just worked though with very little tweaking.
tshanmu 8y ago
We have been getting good response to support and it's true PAYG for support. k8s is really good and good for prod ..
halbritt 8y ago
My team is running a couple thousand cores on GKE and have been in production there for a year. These are multi-tenant clusters with several dozen deployments of my company's application. "production" tenants get automatically configured SLA monitoring via Pingdom which it's a health endpoint every 30 seconds and has something like a 30 second timeout. Average availability for the year across those environments is 99.99%. I'd say that's decent enough to use. Their support is hilariously bad at times, though.
luka-birsa 8y ago
For me support is: 1. Reasonably priced (especially now, with role based) 2. Fast 3. Helpful That was my experience when we needed something. Dont get me started on docs and operations. Eg: Using Azure we found out the hard way that the Firewall was cutting connections after 5m of inactivity. Changing that setting? Their docs are wrong, stack overflow kindof helps, but to fix it we had to use windows based tooling in a vm since their linux based stuff didnt work. I know this will happen sooner or later with anybody, but on average the experience with GCP was superb. I do agree re: certs. That is the only thing I really hate, doing LE when they could run this for you. But they will launch an SSL solutio since they have one now for AppEngine.
- bogomipz 8y ago
  >"Eg: Using Azure we found out the hard way that the Firewall was cutting connections after 5m of inactivity." Could you elaborate on this? Which firewall is this? I remember something similar with their load balancer but I thought this was fixed years ago. Might you have some link to the issue? Thanks.
wikibob 8y ago
Amazon has nothing in the category of exception tracking. StackDriver error reporting is a lite product intended mostly for folks with small applications on AppEngine. There is a recent post by Corey Quinn entitled CloudWatch Is of the Devil, but I Must Use It discussing the extremely poor usability of Amazon CloudWatch [0]. Here’s another story about the general weirdness of the product [1] I would strongly recommend using a dedicated exception tracker like Sentry.io, they have an excellent full featured product at a extremely reasonable price. GCP has clearly documented Platform Launch stages for Alpha, Beta, and General Availability [2]. The Kubernetes project itself follows the same definition for these identifiers as GCP. Specifically Beta is considered to be acceptable for most production use-cases, but it is not guaranteed that the API will remain backwards compatible. So if you’re running the majority of cloud services, beta is fine. If you’re running a system that will cause permanent harm to humans, don’t use beta. One last note, GCP has just released a fully managed certificate product for their global load balancer. There is fully integrated Kubernetes support which has not yet been announced formally [3]. Certificates for Kubernetes on Amazon are less integrated than the above. There’s several options, it’s not clear without extensive research and testing what the tradeoffs are, and in the end it turns out that there is not an officially supported Amazon option. [0] https://www.linuxjournal.com/content/cloudwatch-devil-i-must-use-it https://www.linuxjournal.com/content/cloudwatch-devil-i-must... [1] https://www.circonus.com/2016/10/no-fixed-glitch/ https://www.circonus.com/2016/10/no-fixed-glitch/ [2]https://cloud.google.com/terms/launch-stages https://cloud.google.com/terms/launch-stages [3] https://github.com/GoogleCloudPlatform/gke-managed-certs https://github.com/GoogleCloudPlatform/gke-managed-certs

metildaa 8y ago

Lack of IPv6 support is what keeps us off GCP or AWS, HTTP fronting is great, but when it comes to realtime interactive streams to mobile devices, the ability to save significant latency and avoid the hot mess of CGNAT is invaluble.

becauseiam 8y ago
IPv6 is not a first-class protocol on AWS, but it is absolutely doable for most scenarios. It still requires having something of a dual-stack network in place (you definitely can't have a v6 only network of anything meaningful).
halbritt 8y ago
Where do you go for first class IPv6 support? I find it a bit ironic that the mobile and web side of the house are pushing very heavily for IPv6 adoption and yet they expect their cloud customers not to need it.
- metildaa 8y ago
  We're on OVH for most things that aren't latency sensitive. For things where every millisecond counts for quality, we either find a 2nd tier cloud provider with decent peering to most of our end users in that area, or less common colo or rent a server (some areas just don't have 2nd tier cloud providers).

regnerba 8y ago

I feel like their support has really been improving. 4 years ago it felt like it was non-existent. Been pretty happy with it the last few times I have had to contact them. I don't think we use any Alpha features, I know there are a couple Beta APIs from Kube we use, but we would be using those no matter where we ran our Kube deployment. We use fluentd for our log collection and Prometheus for metrics and alerting combined with Elastalert. So don't have any experience with Stackdriver. Why is working with SSL certs an issue? We use the NGINX Ingress with cert-manager and have yet to have an issue. We only have a couple domains pointed at the cluster though, not sure if thats where your issue comes from. The two just worked though with very little tweaking.

tshanmu 8y ago

We have been getting good response to support and it's true PAYG for support. k8s is really good and good for prod ..

halbritt 8y ago

My team is running a couple thousand cores on GKE and have been in production there for a year. These are multi-tenant clusters with several dozen deployments of my company's application. "production" tenants get automatically configured SLA monitoring via Pingdom which it's a health endpoint every 30 seconds and has something like a 30 second timeout. Average availability for the year across those environments is 99.99%. I'd say that's decent enough to use. Their support is hilariously bad at times, though.

luka-birsa 8y ago

For me support is: 1. Reasonably priced (especially now, with role based) 2. Fast 3. Helpful That was my experience when we needed something. Dont get me started on docs and operations. Eg: Using Azure we found out the hard way that the Firewall was cutting connections after 5m of inactivity. Changing that setting? Their docs are wrong, stack overflow kindof helps, but to fix it we had to use windows based tooling in a vm since their linux based stuff didnt work. I know this will happen sooner or later with anybody, but on average the experience with GCP was superb. I do agree re: certs. That is the only thing I really hate, doing LE when they could run this for you. But they will launch an SSL solutio since they have one now for AppEngine.

bogomipz 8y ago
>"Eg: Using Azure we found out the hard way that the Firewall was cutting connections after 5m of inactivity." Could you elaborate on this? Which firewall is this? I remember something similar with their load balancer but I thought this was fixed years ago. Might you have some link to the issue? Thanks.

wikibob 8y ago

Amazon has nothing in the category of exception tracking. StackDriver error reporting is a lite product intended mostly for folks with small applications on AppEngine. There is a recent post by Corey Quinn entitled CloudWatch Is of the Devil, but I Must Use It discussing the extremely poor usability of Amazon CloudWatch [0]. Here’s another story about the general weirdness of the product [1] I would strongly recommend using a dedicated exception tracker like Sentry.io, they have an excellent full featured product at a extremely reasonable price. GCP has clearly documented Platform Launch stages for Alpha, Beta, and General Availability [2]. The Kubernetes project itself follows the same definition for these identifiers as GCP. Specifically Beta is considered to be acceptable for most production use-cases, but it is not guaranteed that the API will remain backwards compatible. So if you’re running the majority of cloud services, beta is fine. If you’re running a system that will cause permanent harm to humans, don’t use beta. One last note, GCP has just released a fully managed certificate product for their global load balancer. There is fully integrated Kubernetes support which has not yet been announced formally [3]. Certificates for Kubernetes on Amazon are less integrated than the above. There’s several options, it’s not clear without extensive research and testing what the tradeoffs are, and in the end it turns out that there is not an officially supported Amazon option. [0] https://www.linuxjournal.com/content/cloudwatch-devil-i-must-use-it https://www.linuxjournal.com/content/cloudwatch-devil-i-must... [1] https://www.circonus.com/2016/10/no-fixed-glitch/ https://www.circonus.com/2016/10/no-fixed-glitch/ [2]https://cloud.google.com/terms/launch-stages https://cloud.google.com/terms/launch-stages [3] https://github.com/GoogleCloudPlatform/gke-managed-certs https://github.com/GoogleCloudPlatform/gke-managed-certs