5 ms·

Google is just horrible, when it comes to any form of support, paid or not. They make paypal look helpful by comparison. I really can't understand why anyone

by b112 4y ago

Google is just horrible, when it comes to any form of support, paid or not. They make paypal look helpful by comparison. I really can't understand why anyone would use any of their services. Support counts. It's one of the first things I look at, when evaluating any external partner. What does it cost, how long does it take for it to happen, etc? Whatever anyone else says in this thread, that's what you need to determine for yourself. Whatever company, what is the support channel like, how responsive is it? If you don't know? If you can't get immediate emergency response and support, and I mean immediate, then why are you even hosting there?

vbezhenar 4y ago
Google tech is the best. Google invented k8s, their k8s cloud is the best in the world. There's nothing similar to GKE Autopilot. Similar things could be said about some other services. People want the best cloud and they hope that those issues won't affect them.
- unity1001 4y ago
  You can just use default K8 without any added service. It works well enough. There is no obligation to use GC for K8. There are a lot of good base K8 providers.
- jhugo 4y ago
  We're heavy k8s users at work. We used to use GKE, now we use a mixture of EKS and bare metal after migrating most stuff away from GCP. Honestly, GKE isn't better than k8s anywhere else in any meaningful way at all.
- andix 4y ago
  K8S runs well on all major cloud providers. You can run it on premise without licensing costs quite well (for example k3s, rancher, …). Or fully managed with Open Shift. AWS, Azure and GC are all on the same level. Any of them gives you „the best“ technology.
  - bavell 4y ago
    Last time I used AKS (~1yr ago) it was a joke compared to GKE.
  - vbezhenar 4y ago
    https://www.reddit.com/r/kubernetes/comments/wuboxb/best_kubernetes_cloud_platform/ https://www.reddit.com/r/kubernetes/comments/wuboxb/best_kub... This is recent topic and you can see that so many people prefer GKE. That's not my opinion. Sure, any cloud works good enough.
- billythemaniam 4y ago
  Yeah I agree overall. BigQuery, Spanner, Cloud Run, Pub/Sub, Vertex AI. Like all clouds, some of the services suck, like Data Fusion, but overall the services work well and work well together. In particular, the way Google Cloud makes authentication and permissions seamless is amazing. Google does struggle with support though.
- htrp 4y ago
  > Google tech is the best. True, but unfortunately they are literally the worst at customer service.
- valenterry 4y ago
  Google has some good tech and then most part of the cloud is just years behind. Want an example: you can't configure the gcp docker registry [EDIT: artifact registry] to cleanup images automatically (after a number of days or number of images or anything). This is total standard in AWS and the ticket for this on GCP has been open for many years now.
  - derefr 4y ago
    Isn’t GCR backed by a GCS bucket in your own project? Can’t you configure object lifecycle management on said GCS bucket?
    - valenterry 4y ago
      GCR is deprecated and I'm using Artifact Registry. (sorry for the confusion) That is not backed by GCS buckets - if it were, I'm sure that I would have found this solution while searching the web. But even if: I would like to e.g. keep the latest 100 images always. I doubt this would be possible with a simply GCS polcy without writing custom code or something like a cron job.
      - derefr 4y ago
        > But even if: I would like to e.g. keep the latest 100 images always. I doubt this would be possible with a simply GCS polcy without writing custom code or something like a cron job. https://cloud.google.com/storage/docs/lifecycle#numberofnewerversions https://cloud.google.com/storage/docs/lifecycle#numberofnewe... > GCR is deprecated and I'm using Artifact Registry. (sorry for the confusion) You're right that this functionality seems to not be built into the Artifact Registry backend (and that's weird†), but it does still exist: see https://github.com/GoogleCloudPlatform/gcr-cleaner https://github.com/GoogleCloudPlatform/gcr-cleaner (found linked from https://cloud.google.com/artifact-registry/docs/docker/manage-images https://cloud.google.com/artifact-registry/docs/docker/manag...), and specifically the `keep` flag for it. Note also how the project is hosted under the GoogleCloudPlatform GH org. To me, when I see GCP projects that are set up like this (in the GH org but disclaimed as "not official" in the GCP docs), this suggests that Google engineers built it knowing it's a pain point; and those engineers will support it to the best of their ability in the capacity of being maintainers of this open-source project; but Google as a company don't want to officially support it (yet), and so your GCP support contract won't get you any business-level support for it. It's sort of like how, in Postgres, there is code which is maintained by the Postgres maintainers, but which lives under contrib/ as an extension. It's essentially a lability-waiver for that component. --- † I do have a guess as to why Google do things this way. At least where dev tools are concerned, Google seems to eschew the usual distributed-systems architecture for long-running jobs (of having a thin API client binary that submits jobs to a cloud-side control-plane daemon, which then drives the job forward, and which can then be polled/subscribed for job status by said client.) Rather, Google seemingly have a philosophy of designing local fat clients that reach into the cloud to drive backend processes as the "control node" for those processes. The Cloud Dataflow (⇒ Apache Beam) architecture is designed this way, for example. I believe it's the reason that the Google Cloud SDK ships with so many binaries — there are a lot of fat clients in there that actually drive logic, rather than just sending messages to daemons that drive the logic. And, presuming developers are issued good workstations, I can see the advantages of this architecture. A local control node synchronously knows its own status, rather than having to poll for it; a local control node can use local resources (like how Cloud Dataflow can consume and produce local files on the ends of the pipeline with the same streaming efficiency as a regular CLI text-processing shell command); and an operation started by mistake, with local control, can be cancelled by just ctrl+c-ing the control process. Depending on how you design the client, it can also "mandate manual usage" — i.e. ensure that the developer is interactively running the process for the process to proceed, and therefore that said dev is available in case anything goes wrong. (I've personally dropped [async daemon-driven] Continuous Deployment, in favor of this sort of "synchronous dev-workstation-driven deployment.") I wish someone at Google would write up a paper on this philosophy; it's pretty clearly implicit in a lot of their work, but I've never seen it mentioned explicitly anywhere. (Maybe it's just one dev-tools lead who has influenced a lot of these projects, doing what they think is "obvious"?)
markbnj 4y ago
> Google is just horrible, when it comes to any form of support, paid or not. They make paypal look helpful by comparison. We have been running production on Google Cloud for six years. We are not a large customer: our spend is in the low five figures. We pay for a middle-tier support plan and support has been excellent during this entire period. We very rarely need to take advantage of it, since the underlying systems are extremely stable and almost never cause us any issues (compute engine, GKE, GCS, Memorystore, Firebase, CloudSQL, etc). Just thought casual readers of this thread could use a counterpoint.
- davidspiess 4y ago
  Exactly our experience too. We are extremely happy with the stability and quality of their services.
- herdcall 4y ago
  Good for you, but if you used the service only "very rarely," I don't think you've experienced the problems that are being discussed here. I had signed up for paid support for a project a while back and remember having so much trouble even paying for it (some trouble with invoices), let alone get any value out of it, that I ended up canceling it.
_fat_santa 4y ago
> I really can't understand why anyone would use any of their services. I can speak to this because a few months ago when I started a project, I went with Firebase. At the time the rationale was, I need something more complex than Netlify/Vercel, but not AWS that will suck up all my time figuring out IAM roles and other dumb stuff. It helped speed things up in the prototyping stage, but I will likely move my infra over to AWS soon.

by b112 4y ago

vbezhenar 4y ago

Google tech is the best. Google invented k8s, their k8s cloud is the best in the world. There's nothing similar to GKE Autopilot. Similar things could be said about some other services. People want the best cloud and they hope that those issues won't affect them.

unity1001 4y ago
You can just use default K8 without any added service. It works well enough. There is no obligation to use GC for K8. There are a lot of good base K8 providers.
jhugo 4y ago
We're heavy k8s users at work. We used to use GKE, now we use a mixture of EKS and bare metal after migrating most stuff away from GCP. Honestly, GKE isn't better than k8s anywhere else in any meaningful way at all.
andix 4y ago
K8S runs well on all major cloud providers. You can run it on premise without licensing costs quite well (for example k3s, rancher, …). Or fully managed with Open Shift. AWS, Azure and GC are all on the same level. Any of them gives you „the best“ technology.
- bavell 4y ago
  Last time I used AKS (~1yr ago) it was a joke compared to GKE.
- vbezhenar 4y ago
  https://www.reddit.com/r/kubernetes/comments/wuboxb/best_kubernetes_cloud_platform/ https://www.reddit.com/r/kubernetes/comments/wuboxb/best_kub... This is recent topic and you can see that so many people prefer GKE. That's not my opinion. Sure, any cloud works good enough.
billythemaniam 4y ago
Yeah I agree overall. BigQuery, Spanner, Cloud Run, Pub/Sub, Vertex AI. Like all clouds, some of the services suck, like Data Fusion, but overall the services work well and work well together. In particular, the way Google Cloud makes authentication and permissions seamless is amazing. Google does struggle with support though.
htrp 4y ago
> Google tech is the best. True, but unfortunately they are literally the worst at customer service.
valenterry 4y ago
Google has some good tech and then most part of the cloud is just years behind. Want an example: you can't configure the gcp docker registry [EDIT: artifact registry] to cleanup images automatically (after a number of days or number of images or anything). This is total standard in AWS and the ticket for this on GCP has been open for many years now.
- derefr 4y ago
  Isn’t GCR backed by a GCS bucket in your own project? Can’t you configure object lifecycle management on said GCS bucket?
  - valenterry 4y ago
    GCR is deprecated and I'm using Artifact Registry. (sorry for the confusion) That is not backed by GCS buckets - if it were, I'm sure that I would have found this solution while searching the web. But even if: I would like to e.g. keep the latest 100 images always. I doubt this would be possible with a simply GCS polcy without writing custom code or something like a cron job.
    - derefr 4y ago
      > But even if: I would like to e.g. keep the latest 100 images always. I doubt this would be possible with a simply GCS polcy without writing custom code or something like a cron job. https://cloud.google.com/storage/docs/lifecycle#numberofnewerversions https://cloud.google.com/storage/docs/lifecycle#numberofnewe... > GCR is deprecated and I'm using Artifact Registry. (sorry for the confusion) You're right that this functionality seems to not be built into the Artifact Registry backend (and that's weird†), but it does still exist: see https://github.com/GoogleCloudPlatform/gcr-cleaner https://github.com/GoogleCloudPlatform/gcr-cleaner (found linked from https://cloud.google.com/artifact-registry/docs/docker/manage-images https://cloud.google.com/artifact-registry/docs/docker/manag...), and specifically the `keep` flag for it. Note also how the project is hosted under the GoogleCloudPlatform GH org. To me, when I see GCP projects that are set up like this (in the GH org but disclaimed as "not official" in the GCP docs), this suggests that Google engineers built it knowing it's a pain point; and those engineers will support it to the best of their ability in the capacity of being maintainers of this open-source project; but Google as a company don't want to officially support it (yet), and so your GCP support contract won't get you any business-level support for it. It's sort of like how, in Postgres, there is code which is maintained by the Postgres maintainers, but which lives under contrib/ as an extension. It's essentially a lability-waiver for that component. --- † I do have a guess as to why Google do things this way. At least where dev tools are concerned, Google seems to eschew the usual distributed-systems architecture for long-running jobs (of having a thin API client binary that submits jobs to a cloud-side control-plane daemon, which then drives the job forward, and which can then be polled/subscribed for job status by said client.) Rather, Google seemingly have a philosophy of designing local fat clients that reach into the cloud to drive backend processes as the "control node" for those processes. The Cloud Dataflow (⇒ Apache Beam) architecture is designed this way, for example. I believe it's the reason that the Google Cloud SDK ships with so many binaries — there are a lot of fat clients in there that actually drive logic, rather than just sending messages to daemons that drive the logic. And, presuming developers are issued good workstations, I can see the advantages of this architecture. A local control node synchronously knows its own status, rather than having to poll for it; a local control node can use local resources (like how Cloud Dataflow can consume and produce local files on the ends of the pipeline with the same streaming efficiency as a regular CLI text-processing shell command); and an operation started by mistake, with local control, can be cancelled by just ctrl+c-ing the control process. Depending on how you design the client, it can also "mandate manual usage" — i.e. ensure that the developer is interactively running the process for the process to proceed, and therefore that said dev is available in case anything goes wrong. (I've personally dropped [async daemon-driven] Continuous Deployment, in favor of this sort of "synchronous dev-workstation-driven deployment.") I wish someone at Google would write up a paper on this philosophy; it's pretty clearly implicit in a lot of their work, but I've never seen it mentioned explicitly anywhere. (Maybe it's just one dev-tools lead who has influenced a lot of these projects, doing what they think is "obvious"?)

markbnj 4y ago

> Google is just horrible, when it comes to any form of support, paid or not. They make paypal look helpful by comparison. We have been running production on Google Cloud for six years. We are not a large customer: our spend is in the low five figures. We pay for a middle-tier support plan and support has been excellent during this entire period. We very rarely need to take advantage of it, since the underlying systems are extremely stable and almost never cause us any issues (compute engine, GKE, GCS, Memorystore, Firebase, CloudSQL, etc). Just thought casual readers of this thread could use a counterpoint.

davidspiess 4y ago
Exactly our experience too. We are extremely happy with the stability and quality of their services.
herdcall 4y ago
Good for you, but if you used the service only "very rarely," I don't think you've experienced the problems that are being discussed here. I had signed up for paid support for a project a while back and remember having so much trouble even paying for it (some trouble with invoices), let alone get any value out of it, that I ended up canceling it.

_fat_santa 4y ago

> I really can't understand why anyone would use any of their services. I can speak to this because a few months ago when I started a project, I went with Firebase. At the time the rationale was, I need something more complex than Netlify/Vercel, but not AWS that will suck up all my time figuring out IAM roles and other dumb stuff. It helped speed things up in the prototyping stage, but I will likely move my infra over to AWS soon.