Comment by Lewisham | Hacker News Reader

Comment by Lewisham | Hacker News Reader

Parent Full thread

Disclaimer: I work on the Cloud SQL team, but everything here is a completely my own

FWIW, the Google products that are subject to the deprecation policy [1] will give a year's heads-up before they are shut down.

We aren't doing our job well enough if you can't easily transition off Cloud Platform (at least for the components that have obvious competitors... something like BigQuery is necessarily less simple). You should stick with us because you believe in the product, not some sort of lock-in, so you should find it easy to leave within that year.

As for whether that deprecation is likely, it would require a sea change. In the Wired article that came out yesterday [2], the quote is '“We will spend the majority of our development efforts on this New World,” wrote Hölzle.' And this is true, Google really is throwing Technical Infrastructure behind Cloud Platform. That's not to say Cloud Platform going away can't or won't happen, but I feel confident in my job sticking around.

[1] https://developers.google.com/cloud/terms/deprecation [2] http://www.wired.com/wiredenterprise/2014/03/urs-google-stor...

The problem though is that if there is even a chance a service will be shut down (with a year's notice or otherwise) then on a financial basis alone, the cost savings up to that point will be drowned out by the switching cost.

I agree entirely with @bcantrill's comment. I look at Google's PaaS services with the very real concern that they may be switched off or changed at any time.

The reality of this is not just that it will have a financial cost but may well deal a mortal blow to the business. Unless Google makes a long term implicit (big customer) or explicit (rock solid 5-year SLA) commitment to these services they're just too risky to build a complex business on (unless it's a business which is enabled by the marginal cost savings).

Sorry but I have to disagree with this and the above. There is a fundamental difference in the Google Cloud platform which caters to (paying!) customers and has (paid!) support vs. a playground free service for end users like Google Reader.

The "meh" of GCE so far has really just been that it is behind the times vs. AWS kicking out new features monthly and is years late to the game.

When they keep adding features to their ecosystem (and driving down prices like the crazy cheap $0.02/GB cost of storage vs $0.68/GB for S3) usage will keep increasing.

I haven't had or heard of a single customer not choosing GCE because they are worried it is just going away, it is just lack of an ecosystem and knowledge/awareness from the end-user that these Google services are something worth looking at.

Well, here you go. I would never choose GCE, because I'd be worried about it going away, or Google increasing the price by some absurd amount with little warning and no feedback period, making my initial assumptions untenable, and leaving me to do a massive rewrite due to lockin on their proprietary features. Google did this with Maps (before backing off, perhaps due to backlash), and has done this with GAE in the past. Trust is a fragile thing, and hard to rebuild.

> I think the point is though that if there is even a chance that a service will be shut down in a year then even on a financial basis, the cost savings up to that point will be drowned out by the switching cost.

There is always a chance that a service will be shut down in a year no matter who the provider is.

And when that chance is perceived to be particularly high at Google people will act accordingly.

Even if you think it's equal, we're probably in a regime of "nobody got fired for building on AWS".

AWS DevOps here (besides my many other jobs titles/responsibilities).

When was the last time AWS EOL'd a service? Honestly, I can't remember, and I've been using AWS (S3/EC2 to start) since 2007.

GAE, storage, etc could be close to free, and I'll still stick with Amazon; I'm paying for consistency and the long-term lifecycle of AWS as a system.

> When was the last time AWS EOL'd a service?

When was the last time Google Cloud Platform EOL'd a service? I mean, if you are asking about AWS and not Amazon, you should ask about Google Cloud Platform, and not Google.

Amazon has deprecated & disabled old API versions, SOAP & security issues and the like. I think they removed some of the old SimpleDB eventually consistent Query calls & made strongly consistent Select. Some of the regional API implementation around S3 and the original "us-standard" region were changed. But yeah, AWS has never turned off a service or major feature that I canrecall.

"rock solid 5-year SLA"

File that with "will always be free we promise".

Just so you know there is no such thing as "rock solid" with respect to legal contracts. There is always wiggle or weasel room. Better predictor is past behavior (which is what everyone is discusssing).

Not only that but a company like google has the finances to take any kind of legal action hit if they do decide to go against the contract even w/o a leg to stand on. And a band of users and a class action won't stop the process. [1]

Even Apple has in the past killed products (clones, xserve, newton for example). I remember specifically that a close friend told me that "they will never kill xserve" he was a big rep in sales and had tons of business in that area. Yet they killed it. Oh yeah mobileme also. I know I'm forgetting many other things.

While it's not unusual that companies kill products or services and there is never an explicit guarantee there are definitely companies that are more likely to do so if the product doesn't meet certain goals or fit in.

[1] Re-read this part. In other words promise one thing, do another thing, then simply clean up the resulting mess.

i filed an issue awhile ago asking for a longer deprecation period.

https://code.google.com/p/googleappengine/issues/detail?id=9...

I'm not sure if I'm misunderstanding you or this is just a culture mismatch, but are you serious about the one year warning?

For context, the Windows Server 2008 R2 Lifecycle has mainstream support dedication from 2009-2015. The extended support date is 2020.

I'm serious in that:

a) That's what is written in the contract

b) I think you should be able to migrate off the platform within that timeframe, and you shouldn't join our platform if you don't think we're making it easy enough for you to leave again (I deeply believe in initiatives like Google Takeout)

I didn't make any comment, nor will I, on whether I perceive that time frame to be long enough. I think it's smarter to stick to the facts when it's my own job I'm talking about. I would like to continue engaging with the Hacker News community (which, you'll see from my history, began many years prior to my joining Google) and offering context and information. But I can't do that if I don't stick to facts, lest my opinions be bent around to imply something I didn't mean that could put the job (that I enjoy very much) in jeopardy.

Someone at Google is making a big mistake here then. Enterprise can take a year to migrate off their current coffee machine. Migrating off their infrastructure provider is not something they are going to accept having to do within a years timeframe. Some of the QA testing these guys do can take over a year.

The reason Google's whole cloud division doesn't take off in the same way as pretty much everything else Google releases is because it feels like you guys have no idea what you're doing. Which is incredible considering you obviously know what you're doing - you keep Google running! Would you give your Search team 1 year notice to migrate all of their servers off their current hardware and datacenters to AWS or DigitalOcean? Obviously not, they would probably fire the lot of you and run it themselves. Why do you think other enterprises would think any differently?

I think it is pretty clear that keeping Google running has not helped Google to understand most enterprise customers. I think part of the problem is that Google IS a company that could decide to (and spend all the money and time) to migrate from one cloud platform to another if they decided they needed to. The margins are so big, the market share so dominant, the workforce so resilient and compliant, that they could actually turn on a dime. But most companies are nothing like Google, and their infrastructure products have not caught on in large part because of this mindset problem.

Fair enough! Thanks for the information!

The Windows Server lifecycle comparison is interesting, but makes me curious about what Azure does, as a more apples-to-apples comparison. Is there some kind of guarantee of what notice you'd get before major changes or deprecation to services? I can't find one explicitly in some quick searching.

Azure in it's entirety doesn't (1 year notice of changes coming), but Microsoft has a separate "private cloud" IaaS offering, which has a similar lifecycle to server. This is definitely not my area of expertise, but the word I've heard is this is pretty attractive to the big businesses that are most worried about that.

For example, I know a major hospital/research center who has said that they will 100% never let anything onto the public Internet, but are about to clear use of a Microsoft private cloud.

>For example, I know a major hospital/research center who has said that they will 100% never let anything onto the public Internet, but are about to clear use of a Microsoft private cloud.

until they run a private fiber [which don't also have NSA's splitters attached] directly to the MS datacenter, they are being sold a snow in Antarctic [ie. mutually exclusive dichotomy between "100% never let anything onto the public Internet" and "use of a Microsoft private cloud"].

I work in Azure.

We are happy to talk about the actual location of your data for privacy purposes: http://www.windowsazure.com/en-us/support/trust-center/priva... I don't know how often this is actually done, but it's not out of the question that a large customer might prefer to run their own fiber to our datacenter(s).

The reason it's called a private cloud is because it's hosted at the client premises, not in the MS datacenter.

http://arstechnica.com/business/2012/04/a-sysadmins-view-of-...

As a Microsoft cloud services user, I know what metropolitan areas our services are hosted out of, and I believe that we can request a physical tour of one or more of those datacenters can be arranged. If you are a large customer, you can also arrange for dedicated connectivity to the Microsoft network via a peering connection.

Re the NSA splitter issue, that's just a reality of life. If you've run a large email, backup or similar system for a length of time, you've inevitably come across requests from law enforcement or litigating attorneys for data. So don't assume that nobody is accessing your stuff because it's in a room in your building.

Wow. A member of the team addresses the longevity fears by assuring that a years notice would be given if the service were deprecated.

It's ... 12:55 PST ... do you still have a job ?

a year's notice in enterprise space. That shows one more time how deep Google's [mis]understanding of B2B business is.

Google understands on some level how B2B works ... for a while, they only made money through B2B channels, especially via sales of the Google Search Appliance.

I think that the people directing the App Engine lack a clear vision. They should know that price isn't what's stopping GAE. It certainly makes a statement about Google's vision for the App Engine if they have all of their good product people working on something else.

>Google understands on some level how B2B works ... for a while, they only made money through B2B channels, especially via sales of the Google Search Appliance.

during last 14 years i've worked in 3 BigCo's and 1 mid-size. The corporate portal search in all of them i can describe only using long sequences of Russian unprintable words. Google not being able to penetrate these companies when these companies have during last decade bought so much of other enterprise software, incl. a lot of junk, is a very indicative in my view.

>I think that the people directing the App Engine lack a clear vision

another possibility would be that they calculated how much it would cost Google to implement the AWS's level of features/support/quality, and thus how much they would need to charge to break even, and probably they just balked at it as it is hard to beat Amazon in margin/pricing business. I mean, all these anecdotal "horror" stories about overworked Amazon engineers vs. Google guys enjoying the life/work balance :)

Reply on news.ycombinator.com