Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Kubernetes Engine's third consecutive day of service disruption

status.cloud.google.com

Post reply on HN
Print view View original

361–370 of 419 posts

Re: Google Kubernetes Engine's third consecutive day of service disruption

#361

Post by qbaqbaqba »

laurencei wrote: post #298
manigandham wrote: post #278

Earlier quoted context omitted.

When everything works, GCP is the best. Stable, fast, simple, reliable. When things stop working, GCP is the worst. Slow communications and they require way too much work before escalating issues or attempting to find a solution. They already have the tools and access so most issues should take minutes for them to gather diagnostics, but instead they keep sending tickets back for "more info", inevitably followed by a…

As someone who works for Government and Enterprise - all I care about sometimes is how a company behaves when everything goes wrong. The issue with outages for the Government organizations I have dealt with is rarely the outage itself - but strong communication about what is occurring and realistic approximate ETAs, or options around mitigation. Being able to tell the Directors/Senior managers that issues have been "…

Use AWS and government "region".

Re: Google Kubernetes Engine's third consecutive day of service disruption

#362

Post by vesak »

nstart wrote: post #258
shiftnight wrote: post #74

I have a question. At what point does k8s make sense? I have a feeling that a microservice architecture is overkill for 99% of businesses. You can serve a lot of customers on a single node with the hardware available today. Often times, sharding on customers is rather trivial as well. Monolith for the win! Opinions?

As someone whose daily work happens on k8s, I'd say you better be paining a lot before you move to k8s. I take great care to avoid this, but if you aren't careful, you can end up "feeling" productive on k8s without actually being productive. K8s gives a lot of room for one to tweak workflows, discuss deployment strategies, security, "best practices", etc. And you can get things done reasonably fast. But that's like a…

>The k8s eco system is like the JS framework ecosystem right now - There are no set ways of doing anything.

Given how both the JS and devops worlds seems to be progressing, is there any reason to believe that this will change before the next thing comes and K8S becomes a ghost town?

Re: Google Kubernetes Engine's third consecutive day of service disruption

#363

Post by user5994461 »

Cort3z wrote: post #354
user5994461 wrote: post #346

Earlier quoted context omitted.

As a government or large enterprise, you should get a support contract with the provider and have a dedicated support to contact. Don't get it wrong. AWS is the exact same thing as Google. All you will is log a ticket and receive an automated ack by the next day.

You are incorrect about aws. If your pay for business support, and something is happening to your production environment, they are on a call with you in less than an hour.

How could I be incorrect when that's exactly what I said? You gotta pay for a support contract to have any meaningful support.

Re: Google Kubernetes Engine's third consecutive day of service disruption

#364

Post by BurnGpuBurn »

jkaplowitz wrote: post #210
Fizzer wrote: post #163

Earlier quoted context omitted.

> If they ever do deprecate something people have built on though they're gonna get absolutely crucified. They do this all the time, and they get crucified every time. I built a Google Hangout App and a Chrome App, both of which were platforms eventually shut down. This is where the meme came from, and it's why I personally stopped building on top of Google products. A 1-year deprecation policy is no assurance to me…

Their approach to things like GCP is very different than their approach to those other areas of Google. But they don't separate their branding or unify their deprecation attitudes enough to avoid cross-org-chart reputation damage like this.

So basically they screw you over on either medium or hard, and according to you the real problem is them not telling us clearly whether or not we receive the medium or hard screw over option.

By the way that GCP is so full of loopholes where Google can get out of its obligations its laughable. So it's not even that clear cut that the GCP is really a better alternative.

And even when it turns out to be legally sound, when stuff like this happens, who's going to sue google over it? Nobody, and they know it.

Re: Google Kubernetes Engine's third consecutive day of service disruption

#365

Post by geggam »

scarejunba wrote: post #235
geggam wrote: post #207

Earlier quoted context omitted.

Correct. However written properly you get 90% of the way there. Disaster recovery by switching to another provider is simple when minimal centos/rhel images are used.

Assume I’m not fully informed here. What does “written properly” mean? Sure I can move over route53 to cloud DNS easily but Firehose to PubSub? Lambda to Cloud Functions? DynamoDB to BigTable and moving the data? The syntax for provisioning these doesn’t work that well for some find and replace to work. Are you using a templater to generate cloud-specific HCL from a template or something? Sounds like a pretty big pro…

Quit using vendor lock in resources then asking why its hard to leave that vendor.

Re: Google Kubernetes Engine's third consecutive day of service disruption

#366

Post by Scriptor »

user5994461 wrote: post #363
Cort3z wrote: post #354

Earlier quoted context omitted.

You are incorrect about aws. If your pay for business support, and something is happening to your production environment, they are on a call with you in less than an hour.

How could I be incorrect when that's exactly what I said? You gotta pay for a support contract to have any meaningful support.

You also said that all you would get was an "automated ack". This seems to not be the case if aws provides an on-call support engineer.

Re: Google Kubernetes Engine's third consecutive day of service disruption

#367

Post by geggam »

scarface74 wrote: post #359
geggam wrote: post #207

Earlier quoted context omitted.

Correct. However written properly you get 90% of the way there. Disaster recovery by switching to another provider is simple when minimal centos/rhel images are used.

If all you are doing with your cloud provider are a bunch of VMs, you’re wasting money. There are much cheaper and simpler ways just to host a bunch of VMs than to use one of the major cloud providers. Are you not using any of thier managed services and are you maintaining your own on VMs? If so, you have the worse of both worlds. You’re spending more on hosting and you’re not saving money on letting someone else do…

Going to the cloud thinking you are going to save money is silly. It is more expensive to run things in the cloud, what you are paying for is the ability to scale up and down without a logistics problem.

Re: Google Kubernetes Engine's third consecutive day of service disruption

#368

Post by marcinzm »

onion2k wrote: post #325
Osiris wrote: post #312

Earlier quoted context omitted.

"Support costs" calculation often doesn't include the costs of not having support. When I worked at GoDaddy, there were around 2/3 of the company was customer support. At the current company I'm at, a cryptocurrency exchange, our support agents frequently hear they prefer our service over others because of our fast support response times (crypto exchanges are notorious for really poor support). All of my interactions…

Google hasn't learned this lesson. They have though; they've just drawn the conclusion that they'd rather put massive amounts of effort in to building services that users can use without needing support. This approach works well once the problems have been ironed out, but it's horrible until that's the case. Google's mature products like Ads, Docs, GMail, etc are amazing. Their new products ... aren't.

>Google's mature products like Ads, Docs, GMail, etc are amazing.

Until something goes wrong and the only recourse is to post an angry Hacker News thread or call up people you personally know at Google to get it fixed. For example https://techcrunch.com/2017/12/22/that-time-i-got-locked-out....

Re: Google Kubernetes Engine's third consecutive day of service disruption

#369

Post by antt »

mav3rick wrote: post #229
mbrumlow wrote: post #203

Earlier quoted context omitted.

I really don't know how to reply to you as you have set up a bunch of windmills you assumed from my previous post. Who said anything about poor resource allocation? Who said we need to load people with stress? That being said -- when you are on call -- dropping everything is exactly what is expected.

Many many AWS people have left citing on call as the worst part of their job. Also, it is really a far fetched allegation that interviewers try to fail interviewees to hide their own incompetence. I get that you may not think much of Google SREs but to allege that is just in bad spirit. I hope you do get to see that the people inside Google are one of the best perks of working here. They are smart and motivated and w…

Were they that motivated to help their customers.

Re: Google Kubernetes Engine's third consecutive day of service disruption

#370

Post by wb3tech »

If anyone is interested, here is my documented experience with this issue. I freaking love GCP and GKE, although I have not production environment as it was a HA cluster in us-central1. Working federation now.

https://stackoverflow.com/questions/53244471/gke-cluster-won...

Post reply on HN