Earlier quoted context omitted.
> wait until the car is basically stopped you mean like an email literally saying they acknowledge the situation and won't suspend your account?
In my experience, when dealing with vendors having an account manager can fix these kind of problems and prevent them. Most places outsource their support to global teams don't have access. If you have an AM , in many places, they receive the same notice you receive, also they will personally send it and address it to you with a reminder. They also have a lot more sway as the sales side of every company has the power…
Tell HN: Google Cloud suspended our production projects at 1am on Saturday
501–510 of 531 posts
Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#502Earlier quoted context omitted.
It sounds more like they looked both ways, they saw a car, they made eye contact and the driver gestured for them to cross, then when they began to cross the driver ran them over. And now they’re getting advice to never cross streets as a pedestrian. Sound advice can also be victim blaming.
If a driver gestures to cross and hits the brakes and the brakes don't work it's hard to blame the driver if they didn't design the car. Just saying it might be more of a technical issue and the behaviour probably wasn't normal/expected.
Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#503Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#504Googler, opinions are my own. I know nothing about this case, but I have a few thoughts about this story. 1) The "full story" is actually rather sparse on exact details. The author quoted just a few words of "Your Projects are at risk of suspension", but doesn't provide more details about what was actually in the email. Did something else potentially cause this shutoff, not just billing? (I agree, based on his wordin…
Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#505Earlier quoted context omitted.
or just cluster over several other providers and make sure to test failover the main problem with azure/aws/gcp is that their parent companies will track everything you and others do, and then close every related thing because they have enough market share to not give a fuck about you. There are more than enough blog posts of enterprise customers running into random issues with the big thing, buying "big three, promi…
> I'd suspect most of those customers have rapid migration plans written up. I can assure you from experience that most large customers do not . For either major cloud, most large customers will have adopted proprietary services like AWS Redshift or GCP's Cloud Bigtable or Bigquery. None of these have anything like the possibility of a "rapid migration".
Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#506Earlier quoted context omitted.
How are you supposed to trust a company who told you they wouldn't screw you because of their own error, then screwed you anyway? Having a relationship with them doesn't matter if they still can't be trusted to do business. The type of payment method you use is not a factor that plays into whether you can trust your vendor.
> How are you supposed to trust a company who told you they wouldn't screw you because of their own error, then screwed you anyway? I mean, it's an error. Sure, it's infuriating, and in worst-case could financially harm (or cripple) your business. But Google didn't intend for it to happen. That makes no sense from a business perspective. So, as others here suggest, you have to plan around the fact that mistakes like…
Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#507Earlier quoted context omitted.
after Azure sunk my employers project with no recourse or discussion allowed, I always advise everyone I meet to run far away from Azure if they value a reliable service.
"No discussion allowed" sounds impressive, almost like legal impetus was involved. What parts of the story can be shared?
=============================
Greetings for the day!
I have received an update from Account Research Team: As part of our strong commitment to the protection of our customers and our interest in preserving the quality and integrity of the Azure Marketplace, we perform supplementary reviews of accounts which may exhibit irregular or suspicious activity. Your account was selected for one of these reviews and after careful consideration, this account will remain closed.
Please understand that we keep security checks like these in place in order to protect the quality and integrity of the Azure Marketplace
=============================================================
The ridiculous thing.. my employer makes huge use of Office365? We signed up for Azure via a slightly different path with no issues.. but I know this could be pure chance it just happens to work as the service could be teetering on a precipice of arbitrary policy application and the rug could be pulled from under it any second with the same infuratingly cheery account deletion..
Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#508Earlier quoted context omitted.
I think an email from support is more like "confirmation that they checked whether the car has seen me". I'm not sure how successfully you've dealt with support with companies, but I have almost never been able to rely on the promises of a support agent, as they are simply not the ones actually making the decisions (in this case on whether your account gets suspended or not).
A support agent is supposed to speak on behalf of the company. If they say "your account will not be suspended for this issue", and the company then suspends the account for that issue, that should be grounds to sue.
Regularly XYZ does not happen, or not exactly in the way you agreed. They cancel your broadband too late, or your internet starts a few weeks too late, etc. You can try to get compensation, or even sue, but some of the damage has already been done at that point. While this okay for temporarily overpaying broadband, this is probably not the case for a company's main production system, where the risk is very high. The company might not even survive to sue.
Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#509Re: Tell HN: Google Cloud suspended our production projects at 1am on Saturday
#510Earlier quoted context omitted.
Which is funny because reduced cost was one of the major selling points of "cloud" way back when. Most companies aren't actually at the scale where they need cloud. Cloud comes with the benefit of minimal to no need for ops/devops, high uptime (when nothing goes wrong lol), integrated DDoS protections, APIs your junior devs can string together, and the illusion of infinite scaling. In reality, it turns out you do nee…
On demand pricing is also a key benefit of cloud. Instead of needing to make a big initial spend on hosting infra you can pay only for what you need. The other big benefit is auto scaling, in 2012 lots of companies would launch and be unable to meet traffic from a big push from reddit or HN or others. Today it’s rare to see a new product’s site go down due to a “hug of death.”
If you do in-colo hosting with leased servers you've already cut the big initial spend drastically (e.g. deploying to a new colo for a past employer involved buying a pair of switches and some cables), though you're still usually tied in to a lengthy contract. Doing managed servers usually comes with little to no upfront cost (sometimes a low setup fee) and often month-by-month contracts.
With respect to the on demand pricing benefit vs. monthly, my experience is that the price differential is so steep vs. the cheaper managed hosting providers that it's only usually viable for loads that run less than ~6 hours a day. Most sites do not have a variable enough load to justify the engineering cost to use cloud to handle their normal day/night cycle that way - usually the variations are too small. Some do.
But note that this only pays for itself if your base load is not on a cloud setup, as the base load tends to dominate and the base load cost of most cloud setups is high enough not to be outweighed by the increased flexibility vs. a pure managed/colo/on prem setup.
It gets worse for cloud: If looking for the most cost effective, they're not competing against a pure managed/colo/on prem setup, but against a hybrid setup which can auto-scale into the cloud but usually won't. If you e.g. deploy containers, all your need is to tie cloud instances automatically into an overlay network and feed data from your monitoring system into a tool that adjust min/max instances in for an autoscaling group in AWS when load exceeds a threshold, for example.
For a typical "pure" on prem setup you'd usually aim for the daily peaks to rarely exceed 50% of on prem capacity. Maybe a bit more if you have a very predictable business, or even less if your traffic is very unpredictable.
But if you add capability to that setup to spin up and tie in cloud instances to handle peaks, and you can push that into 90%+, or even above 100% - basically whichever number turns out most cost effective. Usually if you optimise that for cost, this means you'll end up with a setup which almost never spins up cloud instances, but which is now vastly cheaper relative to a pure cloud setup because it's gained the benefit of auto-scaling at a far higher load factor than would be safe in a pure on prem/managed setup.