Hacker News Reader

Comment by thibaut_barrere | Hacker News Reader

I've been relying on multiple Cloud offerings (including PaaS, IaaS etc) outside Google for many years, but for some unclear reason, I cannot manage to consider Google a reliable partner for a type of hosting or another, at this point.

I would love to be proven wrong really, because I often look at their GC offering, and I /really/ want to dive in, yet I feel that I would risk having to migrate quickly in 2 weeks at some point because they are changing things significantly (either shutting down or other major change).

So to my question: for how long have these services been around in a fashion that is stable (feature-wise, quality-wise etc)? Is there anyone here with a longer history of using Google Cloud offering, able to comment on this?

EDIT: thanks to everyone who replied below. I think I'll give it a try :-)

View on HN

For Google Cloud products that have made it to General Availability (GA), we have a one-year deprecation policy (https://cloud.google.com/terms/, Section 7.2). That is, if we're going to make some big change, we give you a 1 year heads up.

Disclaimer: I work on Compute Engine, but I'm not a lawyer ;).

This is good, but I wish Google offered the same policy for most of their other general cloud services.

Promises to do something for a year which you can change or withdraw after 30 days are really promises for 30 days:

"Google may make changes to this Agreement, including pricing (and any linked documents) from time to time. Unless otherwise noted by Google, material changes to the Agreement will become effective 30 days after they are posted, except if the changes apply to new functionality in which case they will be effective immediately. If Customer does not agree to the revised Agreement, please stop using the Services." https://cloud.google.com/terms/, Section 1.7b

Also, Sections 13.1-13.3 means even though Google promises nt to do something, you really don't have any recourse if they do it anyway and cause you damage.

Although in the grand scheme of things, not the worst terms of service document I have read. The mere fact the drafters addressed the issue is worth ... something.

Disclaimer: IAMALBIANYL.

> Disclaimer: IAMALBIANYL.

I like that one. :)

I have a question though, is the prevalence of taglines in any way related to legal requirements? Do you have to stipulate that you aren't a lawyer when stating things because otherwise people to construe it as legal advice, or is it just a fun little identifier of how valid we should consider information to be (like it is in other acronyms of the same type)?

I think it may stem from laws and rules related to practicing law, but there is certainly not any "requirement" to stipulate you are not a lawyer when speaking about legal things. However there are a few things to be mindful of: In the (all of the) United States (and many other countries) the profession of lawyer or attorney is regulated and requires a license to practice as such. In many places to practice law without a license is a criminal offense. Obviously this doesn't contemplate criminal charges against a group of people spouting off about something legal related on the Internet (otherwise we would have to jail perhaps 80% of reddit), but providing legal advice and interpreting the legal effect of contracts, statutes, or regulations is part of the practice of law.

The reason we heavily regulate the practice of law is similar to the reason we heavily regulate the practice of medicine. If you screw something up, the consequences can be bad. If someone takes your advice thinking you know what you are doing, and you are wrong, that person can end up a lot poorer or even in prison. (Though some will argue we regulate it so lawyers can be the only ones charging high fees for legal advice!) Just like one probably shouldn't go around telling folks not to worry about their incredible chest pain and shooting arm pain unless they are a trained medical doctor, the same could be said for those that go around offering home spun legal advice.. ("Yeah man, if you ask the undercover cop if he is law enforcement, he HAS to tell you! Otherwise it is entrapment man...")

Also the reason you always see lawyers preface everything by saying "I'm not your lawyer.. This isn't legal advice... Yadda yaddda yadda" is because once there is an Attorney-Client relationship a lot of stuff happens. The lawyer has a host of duties to the client, from confidentiality, to competence, and many others. That obligation isn't taken lightly and many times if there is any doubt whatsoever whether or not there is an attorney-client relationship, the law will find in favor of one because --- well -- the lawyer should know better. Therefore lawyers will make it annoying clear they aren't your lawyer before spouting off some deep legal thoughts about whatever the topic of discussion is.

That lines up with what I assumed, and the last paragraph is specifically what I was asking about (not the IANAL case so much as the opposite). Thanks!

Great answer. Has the acronym "IANAL" ever been tested in court in such a way, to your knowledge? Now you have me curious, and that'd honestly be quite amusing.

Ha! Interesting question. I just ran an all state/federal Westlaw search for "IANAL" and didn't hit any case law. Two or three briefs, a couple of scholarly articles, but no court opinions. I also searched for "I am not a lawyer", but that brought up about 130 caselaw hits which seemed to primarily be references to various filings by pro se parties actually saying in a court filing "I am not a lawyer".

It may have started as an ass-covering move, but I also think of it as a common courtesy for letting people know that you're offering non-specialist advice and to take it with a grain of salt.

I kind of wish people did that for more things: "I am not theologian/windows user/empathetic person, but..."

That's pretty eye opening. Curious if you have looked at AWS with a similar regard, are they any better?

Not any better, arguably worse:

https://aws.amazon.com/agreement/

"We may change, discontinue, or deprecate any of the Service Offerings (including the Service Offerings as a whole) or change or remove features or functionality of the Service Offerings from time to time. We will notify you of any material change to or discontinuation of the Service Offerings."

"We may terminate this Agreement for any reason by providing you 30 days advance notice."

"We may modify this Agreement (including any Policies) at any time by posting a revised version on the AWS Site or by otherwise notifying you in accordance with Section 13.7..."

Ha, yikes! Thanks for the highlights. I'm guessing Azure has similar (or any IaaS company) leaving us to basically go on trust of the company to support their offerings long term.

Is this really how it works? I guess you have to go to court to find out, but I always thought of it this way:

If I have the same policy (support for 1 year) and I change the contract - the change will only take actual effect after 1 year.

I mean, I'm contractually bound today to provide support for 1 year from today, no? Am I just rambling, or does it make sense?

Google seems to be facing a trust problem here that its competitors don't, due to its history of shutting down popular services, even those that were being used internally and even those that it had been recently hyping to the press. Due to this unusual context, perhaps it would help if Google were to increase this promise from 1 year to 10 years (or 5 years or 3 years).

On the flipside, API's like maps have had stable versions that are deprecated for years.

That's one of the few examples that hasn't burned developer trust. But it's still not a shining example -- there were times of price changes and rate limit changes.

Yep. Their trust problem is also very well earned both from the APIs they've killed/changed and from the long list of Google products in the graveyard.

They've killed APIs/Products, but they've almost always given a very long amount of time to transition.

Also have killed APIs/Products that are extremely difficult to transition from with short notice. For example, they gave ~4 months for the Google Wallet for the web transition, and no data portability for businesses with users on subscriptions.

Stripe, for example, has a data portability clause that allows you to move card data to another payments processor that meets some compliance standards.

https://support.google.com/payments/merchant/answer/6107573?...

Regardless of if you get 4 months notice or 1 year notice you still have to do the work to migrate and you're still stuck with the sunk cost of investing in/learning a doomed platform.

That's why I wouldn't build a business on Google, because they have a long history of killing things when they aren't wildly profitable/successful. A $10m/yr profit product is considered a distraction of valuable engineer time unless it has some ulterior goal for the company.

And I'm not saying they should change -- they do what's right for them. One engineer working on some distraction project could instead be moved to ads quality and end up making a change worth anywhere from hundreds of millions/yr to billions.

But they can't have their cake and eat it.

Google App Engine comes to mind. I'm amazed they would kill of such a product at all.

Google App Engine isn't killed. It's still alive and new features are being added. What are you talking about?

The GP was probably referring to the huge price change that effectively killed it for many people.

Trust is hard to earn and easy to lose. No matter how much power/money you have at disposal.

The problem (I suffer from it as well), is that people naturally feel that the corporate offerings from Google will mirror the experience that they have with the consumer offerings from Google. And the big issue with Google's consumer offerings is that they seem to have limited to no support and that there is a very real chance that Google will just shut them down all of a sudden. This is the exact opposite of what you want in the enterprise space, where Service & Stability are paramount. Even though I know that Google's corporate offerings are treated differently, that little niggling doubt remains. Plus, Google really needs to hire some damn marketing experts to sell the features & benefits of their offerings and make them cohesive - they just have their stuff plastered everywhere.

That's pretty much exactly what my perception is. Add to that, you're account gets shut down and/or frozen without warning and only a kafka-esque system to find out why you were shut down.

It makes sense that isn't true but I have to admit it is what comes to mind.

> And the big issue with Google's consumer offerings is that they seem to have limited to no support and that there is a very real chance that Google will just shut them down all of a sudden.

Express has, IME, excellent support, and I haven't seen any Google product (consumer or otherwise) shutdown "all of a sudden".

The ones people point to as examples of Google products being shut down were shut down with very long notice.

I do think that there is a very loud group of people who like to raise the "Google's just gonna shut it down tomorrow" line every time a Google service is mentioned, but it doesn't seem to be based on any real history of Google being any more prone than any other provider to shut down services (consumer or otherwise) on short notice or without a migration path. Maybe that loud group represents a real and commercially-significant feeling about Google in the market and not just a small, loud group that doesn't real effect the market for Google products. But I don't know what you can really do with that, even if it does.

This is also my impression of Google compute offerings, but it's also my impression of AWS offerings.

I mean, when people think of AWS services, do "service and stability" really come to mind? IME it's impossible to reach a person unless you're a multi-million-dollar org, and Amazon itself tells customers that AWS services can go down at any time and it's up to the customer to architect the application to deal with it.

If I had to peg a reason AWS gets treated differently in the marketplace, I think it's probably some combination of a) AWS was first to market, and b) AWS revenue seems materially important to Amazon, while Google Compute revenue is a rounding error to Alphabet. Therefore, Amazon has a lot more incentive to keep, maintain, and grow AWS.

> IME it's impossible to reach a person unless you're a multi-million-dollar org

I am sorry to hear that, but I can assure you it's not the case. I'm an engineer on a newer (and therefore smaller) AWS service, and I help investigate customer complaints, from customers of all sizes, all the time. I'll also note that not only do we handle cases that come in via our paid support, we also do deep dives for customers who post to our service's forums and indicate issues.

My experience with AWS has been exactly this. I had a Cognito question/issue on IOS that I posted to stack-overflow and got a quick response from an engineer at Amazon. Also I posted a support ticket (zero paid support) to increase my sns API calls limit (which didn't end up being required because I was doing it wrong) and they got back to me over a few days to a week.

On the other hand, Google takes my Android app off the play store with next to zero details on the reason why and I have next to zero methods to contact them. The only way I was able to get my app back was to remove features via trial and error to determine what part was infringing. Why would i partner with Google again for hosting?

You are comparing 2 very different products. Now if you were comparing play store support to Apple App Store support they would be more in line with each other. Or Googles cloud offerings to AWS.

Play is a low margin business per "customer" compared to cloud. This has direct impact on the type of support you can expect.

They have reasonably priced support plans that give you access to a person: https://aws.amazon.com/premiumsupport/

I can't comment on Google, but we pay for AWS business support ($100 per month currently) and we can raise as many support tickets as we like and get nearly instant access to an engineer. Also, the quality of the support has been amazing. They have often gone out of their way to solve problems that are not strictly AWS problems (e.g. MySQL tuning, network issues, VPN questions, etc) without ever questioning it. Our account manager is easy to reach and through him I can get access to solution architects who are happy to advise on pretty much anything. There are also frequent invitations to AWS events, where SAs and account managers are usually keen to meet up and discuss projects. I know this is enlightened self-interest on their part rather than altruism, but it's definitely to our mutual benefit. When pushing to trial AWS I often encountered this view within my org (that is was large, faceless, and inhuman with poor support) but the experience we've had has dispelled that myth.

Anecdotal: AppEngine deprecated their Master/Slave datastore[0] in April 2012, and it was actually shutdown on July 6, 2015. So that's 3+ years to move to newer tech.

[0] http://googleappengine.blogspot.com/2012/04/masterslave-data...

Also worth noting that Google built an automated tool to handle the M/S to HRD datastore migration for you. It was remarkably painless.

Painless eventually; the first versions didn't work at all, at least on the project I was involved with. Fortunately by the time you had to switch, it worked very well.

Being first to migrate to the hot new infrastructure has never worked out for me in any project.

I was mildly annoyed that I had to spend an afternoon "migrating" my app from the M/S datastore, even though I never used it in the first place.

I really struggled around 12 months ago. Lots of weird errors and it took down the service unexpectedly when trying to stage it.

Really made me regret going with app engine a few years ago.

I have been running my website on AppEngine for 6+ years now. No problems at all.

Thank you obulpathi and glad to hear this. Can you also take a look at our new docs here:

cloud.google.com/appengine/docs/

and let me know what you think? This is an iterative effort of course, so more changes to come. Thanks again!

I should add, I've been on top of AppEngine for about 4 years now. This is my second business on it.

I wonder how big you'd have to be to get a real SLA from Google, Azure, or AWS. I imagine 25% off your hosting bill doesn't really cut it for those companies running millions of dollars in revenue through it.

I've had admin on an account that did about half a million USD on AWS monthly in the past; we cut it down a lot by expanding physically and going in hard on reserved instances, but my view into things started around there. I'm unsure if we ever attempted to negotiate a SLA, but we paid for premium support just like you (despite having a dedicated, and great, sales rep) and got kickback credits from the general SLA policy[0] just like you. Nothing special.

If anybody has a special deal, it's probably Netflix. I suspect even half a million monthly is a smaller account to Amazon.

[0]: https://aws.amazon.com/ec2/sla/historical/ specifically, not the current (better) one

Reply on news.ycombinator.com