Make sure you've read the service terms[1] if you plan on building apps for speakers, cars, TVs or smart watches...
12.1 The following terms apply only to current and future Google Cloud Platform Machine Learning Services specifically listed in the "Google Cloud Platform Machine Learning Services Group" category on the Google Cloud Platform Services Summary page:
Customer will not, and will not allow third parties to: (i) use these Services to create, train, or improve (directly or indirectly) a similar or competing product or service or (ii) integrate these Services with any applications for any embedded devices such as cars, TVs, appliances, or speakers without Google's prior written permission. These Services can only be integrated with applications for the following personal computing devices: smartphones, tablets, laptops, and desktops
I have a hard time imagining who this wouldn't be a dealbreaker for. These terms also mean you can't use it for open source, and you can't use it if you don't know what the ultimate application is going to be. And you probably can't resell technology you create, because no one who buys it is going to want that restriction, either.
Don't forget huge retail chains. Infinitesimal improvements in their operations can leverage, especially when compounded, sizable improvements to profit margins.
For instance, as GigaMart, if your ML system finds that you are going to need widget-x in region y two weeks ahead of time, you can plan for that including the logistics and inventory.
Hospitals? I'm sure there are lots of things in the day-to-day operations that correlate with patient outcomes that currently go unnoticed.
Etc etc. It's not about creating a huge new invention, mostly it's about creating improvements to operations of current incumbents.
That's how my company would apply the platform to our work. My boss is there now, will be interesting to see what he find out vs what we're doing with our current IBM platform.
Health care. If you're running on-prem, it does a good job of integrating Kubernetes where it's not something my data scientists have to worry about. Also fairly easy to tie in our data mart and all of our databases - MS, Oracle, DB2, MongoDB, etc.
But why would you choose this solution with those terms rather than something without those terms, even if it is an in-house application if significant investment is put towards it that is an asset that your enterprise now has and those terms are now in your enterprise poisoning it. Actually I can think of the large enterprises I've worked for and Legal would probably not have allowed those terms.
No, because using it to get the prototype going is "using these Services to create (directly or indirectly)". Frankly, those terms look poisonous - you could be liable if any part of your service has origins in Google's platform. If you infringe on the GPL, you can remove the offending code. Here, you have no way to disentangle yourself from Google's trap.
I would imagine most prototypes would be made in a Jupyter notebook. I don't see any point in tying yourself to a platform intended for training/deploying models at scale if you're planning to switch off of it.
That's fascinating. When you have that many services, platforms, company divisions, etc you end up naturally competing with yourself, or enabling your competition.
To be fair, Amazon has a way of eventually becoming a direct competitor of many of the companies they initially present themselves as a middle man for.
This is being announced now in the Google Next keynote.
This platform focuses not on the this-AI-is-magic-and-can-solve-everything like many AI SaaS startups announced on Hacker News, but focuses on how to actually integrate this AI into production workflows, which is something I wish was discussed more often in AI.
The announcements here, including AutoML Tables (which is coincidentally similar to my own Python package: https://news.ycombinator.com/item?id=19492406), the new BigQuery BI tools, and the new Google Sheets integrations, make me a very happy data scientist.
I'm taking the rest of the week to figure out how to integrate everything announced into my team.
Hi @minimaxir, I just checked the readme of your project. It looks great, there's a mention to integrate Polyaxon[0] for running jobs in distributed way on Kubernetes. Let me know if you need any help with that.
Are you guys quite embedded into the Google Cloud system?
We’re a startup that helps with AI deployment management (our only focus is production AI - embedded everywhere) and I wonder how many companies are who’d be interested in their end-to-end offering.
Looks like Google is taking over Cloud (from AWS) for AI by building an ecosystem and building tools for non Data scientists - consumer level product. Surely IBM can do similar thing with their recent Redhat acquisition, but will they ?
I might be missing something but AWS seems to have analogous products for everything in this article. Or is your point that AWS tools are less consumer friendly?
I've tried using Google's AutoML to classify medical images as part of a Kaggle competition just to see what their process is like and how well it performs. This was Q4 2018, so things might have changed slightly.
In brief, my experience was quite frustrating. First, getting my dataset to the cloud required quite a bit of manual labor. Uploading my 25GB of images on my 40mbit/s wasn't really ideal so I ended up spawning an virtual machine on GCP and downloading directly from Kaggle. Unzipping the files and writing it to Google Cloud storage with some terminal commands.
Furthermore, to get the label data into AutoML I had to write some generation script that generated the exact format CSV that AutoML requires - which was hidden in their documentation somewhere with no mention in the AutoML environment itself.
Nothing too cumbersome but generally not a very user friendly experience, or something I wish to repeat many times if I get a new/different dataset.
Ultimately, when the data with labels was in the model started training. Then I found, that I didn't really have the tools and information to assess the model performance. They did a decent job of characterizing model performance through precision recall graphs and displaying incorrect predictions but that didn't really satisfy me. I was interested in getting more details about where it was misclassifying images, specifically how classification performance was distributed across the 28 classes the model was predicting (in a multi label context).
This is the point where I think the downside of working with a platform such as AutoML starts showing. I tried reaching out to someone about gaining more insight into model performance by opening a ticket, since there was no phone number. After a couple of days I finally received an email from a product representative that told me that for any assistance I should contact one of their local cloud partners.
These are third party vendors that typically assist companies in deploying cloud based applications in the GCP. However, after calling two of these companies that were highly recommended by Google's vendor page I was told that they don't have any experience with AutoML and that I was on my own. The other company didn't reply at all.
In my view, choosing a product such as AutoML - for a company that is serious about adopting AI to improve their business - is currently not a good path (yet). And I see this space as being wide open for competition with current solutions not cutting it from my point of view.
It’s so disingenuous for Google to brand these efforts as “democratizing AI.” It is precisely the opposite.
This is classic commoditization of your complement. On one hand, Google is pushing to centralize the integration, data management and computing platforms for machine learning, so that these things become as much of a commodity as possible.
On the other side, they are offering massive compensation packages or acqui-hiring as much AI talent as they can, not really because they have useful work for these folks to do, but to artificially reduce the supply of statistical algorithm talent, making their consulting and pre-packaged AI solutions go up in value in a manner that is pretty much the same as De Beers pushing silos full of diamonds to keep diamond prices artificially high.
This is very much the opposite of democratization, and my advice to anyone considering services like this or like Amazon’s out of the box models, don’t do it!
If you think it’s going to save you money over paying competitively to get your own in-house machine learning staff, you’re wrong, and you’re going to waste probably hundreds of thousands of dollars before you learn you’re wrong.
>> It’s so disingenuous for Google to brand
>> these efforts as “democratizing AI.”
Exactly. NVIDIA building fast consumer GPUs and CUDA/cuDNN is "democratizing AI". FB (and Google) releasing open source deep learning toolkits is "democratizing AI". People releasing reproducible research code and datasets are "democratizing AI".
Cloud vendor lock-in and proprietary hardware, software, _and_ datasets is not in any way "democratizing" anything.
>> not really because they have useful work for these folks to do
This, however, is where your argument flies off the rails, IMO. They offer this much because there's very limited supply of people who can do both research and development at the same time. Meaning, they don't just write papers, but also can code pretty well. It's usually one or the other, and hardly ever both. And the total in this case is much greater than the sum of its parts.
I agree with you that the supply of those workers is low (I am one of them! And hiring more is extremely hard!) ... but it doesn’t mean Google / FB / etc have meaningful work for them. A friend of mine was hired as a senior ML person at Facebook and ended up working solely on cartoon avatars and page responsiveness / latency optimization (not using ML).
When he raised the issue to managers that he wasn’t working on anything related to his specialization (deep learning for NLP) and this made him unhappy, the response was essentially, “Get in line.” I’ve heard similar stories about Google from a former boss who had been a long time manager in Google.
You essentially get paid super well to be put out to pasture so that your skill isn’t being used by other companies (leading to more demand for Google’s managed AI solutions).
In order to get career-developing work, you have to play political games or get hired in a non-standard way, like acqui-hire or poached, where you can negotiate your projects as part of your hiring conditions. Eventhen it will probably only be respected for a short time while it’s convenient for Google, and they’ll find a way to manage you out of that situation when they want to.
There are some tremendously talented AI engineers in places like Google. Some of them create awesome products and tools. A bunch of others sit around and atrophy working on dumb shit locked in golden handcuffs just to ensure they’re not on the market and able to help a company build things in-house more cheaply / more optimally than if they needed to buy it through some managed services through Google.
As an ex-Googler, that's not how you're supposed to operate at those companies. You find something you like to do, talk to the team, ensure the other team has open spots and would like to take you on, and move your shit from one desk to the other. Done. You're working on your specialization, if that's what you like to do.
Discussing stuff with your manager is utterly pointless because your interests aren't really aligned. You want to do something else. Your manager wants you to do whatever you're doing now because finding a replacement for you is a bit of a pain in the ass. She gets no brownie points if you leave.
It is true that Google has a ton of PhDs who just copy one protobuffer into another and browse memegen all day while earning half a million dollars a year. But they also have a ton of PhDs who do meaningful work, too. It's not really Google's problem that someone can't be bothered to look around and find something meaningful for themselves to do. Or to be more exact, it is a problem _for_ Google, because there are a lot of people who can be deployed in higher leverage occupations, but not one that Google itself can solve, because one of the main tenets of how they operate is _nobody tells you what to do_. You're supposed to figure it out on your own. A lot of people can't deal with that.
Well yeah, you have to tell your manager of course, but _they can't stop you_ from moving to another team.
Don't know about Apple or Amazon but Google/FB are like that. If you're very senior, a few months (no more than 6 no matter how senior) delay might be imposed so that you hand off your stuff, if you're less senior, a few weeks is usually enough. It is also expected (at Google, don't know about FB) that you'll stay on each team for at least a year, and that you'll wind down your obligations in an orderly fashion, which I think you'll agree is not unreasonable.
But _nobody_ will force you to do work you really don't like to do. In contrast, at most other companies it's easier to get a job _at another company_ than to move to another team.
There are many ways at Google to stop people from moving teams. For me it was a code yellow. I am hazy, but it was either referred to as indentured servitude or more politely stated as such by our senior director who expected 3 year stints. This was at MTV, probably a toxic environment due to CxO visibility.
Code yellow is by its very nature a finite-duration thing. I've never been a part of one that was longer than a month. It's reasonable to not allow transfers for the duration, if it helps to resolve the code yellow IMO.
We had 4-6 month cyclical code yellows. It's not unlike the game where 20% projects could only be within the same team without significant blowback. Things are only reasonable when used as designed, which is not how all of Google operates for everyone. You can talk in the general sense, but you cannot speak definitively especially when such actions are blessed by the executive team.
Googler here. This is how it works. If you find a team with an open position you want to work on, and you and the teams hiring manager agrees it's a good fit, your manager can't do anything to stop it.
I did something like this myself. I found the team I liked, talked to the team a bit about the work I'd be doing, and at my next one on one with my manager I told him I'd be leaving the team in two weeks.
There’s a difference between an orderly discussion leading to change of team/focus in a timely manner and just doing whatever you want whenever you want, which is the point I was making.
You can certainly find yourself a better team fit and organise to move to it proactively, that’s true of any organisation, with greater or lesser degrees of red tape.
...but the parent assertion was basically, if you don’t like your job, just get up and walk off and drop your stuff on some other interesting teams table. Job done!
Nah dear HN reader, don't move the goalposts now. That's not what I said at all. And it's not true of _any_ organization. It's actually _not_ true of most companies I worked for.
It's certainly been my experience. I mean not exactly that level, but yeah. I told my manager the work I was doing was boring, and that I'd consider switching teams, and he worked to find work that was more interesting to me.
Then I also started working with one of the other teams I find interesting, and I now spend (more than) 20% of my time working with that team on various things.
I just want to say that if this describes anyone that's reading this, then please join us at AWS. We're doing a ton of ML, and your talents won't be wasted.
Sitting around and stagnating your career for a nice salary is a profoundly short-sighted thing to do.
I have tried Google AutoML, Microsoft cognitive services and looked at Clarifai for image labeling and classification. I ended up writing my own system. Maybe this new Google product will be better... definitely room for improvement in this space.
This will make a bunch of startup's life really hard. I think it makes it harder to justify investing in your own ML pipeline or even building your own models for many use cases.
I'm running a startup which offers the same solution as Google AuotML Tables. Recently I decided to go open source. I will need to compare my solution with Google AutoML Tables (compare in terms of final model accuracy). But anyway I think many times the best model accuracy is not the most important in ML solutions.
Any ideas what can I do with such a situation with my solution? Can I compete with Google?
Usually google is good in the initial release of a product, but they lack good customer care and support. They have non transparant pricings and they disrespect privacy. Those are something's you can differentiate on
Thank you! I've just played with AutoML Tables and I got feeling that my service is way too much better than google beta in case of the UI.
I'm waiting right now for their model performance score. But I got feeling that they are only tuning Neural Networks. (however I cant find info about algorithms they are using).
Maybe this is crazy, but I feel that I can compete with them on model accuracy and UI. For sure, I cant compete with them on marketing.
Far from it. If you have an actual sow and contract with them, you can define your support terms and get better support than if you just sign up with a business account and avoid talking with salespeople.
Also, ride on Google's marketing campaign. When Google does this, a lot of uninitiated clients want to get on the bandwagon and use something similar. Before Google, they might not even understand what your platform really offers. I saw the same thing happen when they advertised Stadia.
Below is an excerpt their T&C, use those to your advantage. I can't imagine any serious enterprise customer wanting to tie them down to Google. Just tell the market that you do exactly the same as this platform without tieing them down, without privacy violation and without letting them down by abandoning the product (yours is open source)
God speed!
12.1 The following terms apply only to current and future Google Cloud Platform Machine Learning Services specifically listed in the "Google Cloud Platform Machine Learning Services Group" category on the Google Cloud Platform Services Summary page:
Customer will not, and will not allow third parties to: (i) use these Services to create, train, or improve (directly or indirectly) a similar or competing product or service or (ii) integrate these Services with any applications for any embedded devices such as cars, TVs, appliances, or speakers without Google's prior written permission. These Services can only be integrated with applications for the following personal computing devices: smartphones, tablets, laptops, and desktops
Go vertical rather than horizontal with your solution. Google, and the other large players, need broad swaths of customers/users to get to a viable total addressable market at their scale. That is your advantage over them: you can survive and thrive in much smaller markets. Also, see ricklamers take in this thread (https://news.ycombinator.com/user?id=ricklamers)... it's not the be-all, end-all and never will be. If you've already decided to open source your tools, then is that really even your primary value add[1] or is it some expertise/service on top of your tools? Figure out what that is, be a cockroach and find a market that's too small for them to be bothered with and then super-serve that market.
[1] If the tool is your primary value add, I think you're making a mistake in open sourcing it.
The tool is primary value added but I would like to have wide adoption. It's my goal to see people using it. I hope I will make money on companies that would use the tool (will make money on additional features and support).
That's obviously your choice. Just be aware you're prioritizing (hopefully) getting more widespread adoption most likely at the cost of the business. The people likely to make money on it will be someone other than you. That's just the harsh reality of open source.
I am too building a new automl platform on top of kubernetes,
I do not think that you can compete with google on alg accuracy, since most of the underlying ML alg are open source (scikit learn or tensor flow). This is not a secret sauce.
That said, to get better models, you will probably need to find better hyper parameters tuning method, which depends on the number of models that you are willing to run per model tuning session. So if you have a unique model search method, you can save 10X-100X search time, which translate to real saving.
In addition, the solution lacks in model management. In general, most business people would like to understand why a specific model make a specific prediction. Most ops people want to track the training data version, model version, alg version etc.
Moreover, The product itself has "best practice" page :
which include a list of features that are not in the product.
And one of the biggest differentiation should be on-prem vs cloud. Are customers willing to put their data in google (or any other cloud, for that matter) ? Can they legally do that?
I think that this product actually benefit the ecosystem since it helps to create a category of auto ml for tabular data, backed by google marketing budget.
Yeah I don't think I agree with the assessment that better models are a function of finding better hyper parameters (entirely). Like, in my limited experienced,stacking and packing models (the 'lift' required by individual models), adjusting ones thinking regarding 'how' they go from data-in >> product out and 'what' it is were trying to predict, pipe-lining annotation and scaling its distribution, are far more effective at generating better ML models than tuning hyper parameters.
Generally, if a model is not performing or generating unexpected results, its almost always the data or how the question is being structured.
Google educates the market for a solution like theirs (or yours). Then, for everyone who thinks they don't wanna rely on Google due to their history of product abandonment or can't send their data to Google, they look for open source solutions that they can self-host. You want to be there for those people as the best open source solution. This may not be a death-knell. This may be your biggest opportunity to get traction in this space!
You might consider a strategy where you offer a drop-in compatible service for people not reading Google's terms and not understanding the limitations. Let Google do the marketing for you, people will come to you, when Google kicks them out of their smart TV
There’s plenty of room to compete with Google and it makes things easier when it comes to market education.
We’re also a startup in the ML space but solely focused on production deployment.
You’re right in that model accuracy is not the most important thing. There are many other considerations as to why a model should be used including training time, processing costs, value.
Furthermore, as someone mentioned earlier, Google’s service is horrendous and provides another angle to address. Their reputation as a company to be trusted with data is also somewhat shaky given all the privacy concerns.
Like anything you will need to focus on your differentiation and doing what others cannot or will not do. For instance Google requires you to bring your data to them (GCP). In many cases it may be better/easier to move the compute rather than the data. Perhaps you can bring your system to a customer's data more easily?
Check this comment in the thread https://news.ycombinator.com/item?id=19627515 . If your solution allows for embedded devices and other use cases that the solution from Google prohibits (which is a lot of scenarios, actually), then your offering has a chance. Considering that it isn't a matter of choice at this point, with many companies legally not being able to use their offering, you will be doing quite fine.
Add on top of that better customer support, like other replies suggested, and your product won't be dying due to competition from Google any time soon.
Most people including ones here don't understand the value prop. In ML, the model (and modeling) is an afterthought that takes 3 lines of code. The value-add isn't the model or modeling, it's the feature generation and methodology. When (and if) this gets automated then yes, it will make life hard on many data scientists. But I don't see it happening within 20 years and most likely not within my lifetime.
I am not sure why you do not see that happening. Driverless AI from h2o does a full feature engineering search. Also, I assume that you want to automate the features search in order to prune the non signal.
I am not sure what you mean by methodology?
The one thing that I, as a tool developer, do not understand is how humans would be able to handle hundreds of models, including retraining/monitoring and deployment without automl.
This will make a bunch of startups' lives really hard... when Google gets bored with it and kills it just when a lot of startups have come to depend on it.
It depends on how the market responds. While AI will be here in 10 years this product will be outdated long before that point looking ahead it almost begs to be shutdown and replaced with a newer version.
If you build your business on this platform your business must be willing to evolve with it.
Paraphrased from the article: AutoML tables takes a generic table and predicts can predict a columns value (for an unseen partial row, I assume). Their product page emphasises how easy it is: for developers with limited machine learning experience. What are the consequences of using such structured data predictions devoid of interpretation or quantified uncertainty? Presumably such predictions could be from a set of discrete values, how is that smoothed? What is the result of providing definite results in the absence of intention?
AutoML is essentially training a ML model using some heuristics or optimization algorithm to select model architecture and train a model. Feature engineering / feature synthesis as well as interpretability remain open challenges.
If I'm understanding your questions correctly, the main problems I see with this are:
- Using raw data instead of feature engineering (less of a problem given feature synthesis libraries like https://www.featuretools.com/ and other heuristic methods). I'd expect Google to do a good job of basic things like normalization of raw input features before training.
- Using features that it really shouldn't (if you just throw ML at your database for say, loan applications, then sensitive
/ personally identifying information can/will be used as features)
- Lack of insight / understanding as to what is driving the model. This can be partially overcome with post-training methods like LIME, Shapley values, etc.
I wouldn't expect predictions to be from a set of discrete values - if (say) predicting housing values and training a NN, the output should be continuous and based on the input features.
Another common error I see is timing (e.g. using data from the "future" to predict an event). To build on your loan example, if you inadvertently included the current FICO score of an applicant that applied 12 months ago, it will be unfairly correlated with the loans current performance.
I work in building and deploying production ML/AI models but I'm having a lot of trouble cutting through the marketing jargon in this article and on Google's website as well.
Can someone explain what this does in engineering terms? How does this differ from something like AWS Sagemaker?
This is where Google really has a big lead on AWS -- the AI space. AWS has AI tools, but Google's are better and easier to use.
The big question is: If all your data sits in AWS, because your app that generates the data is there, do you reach across and try to use the Google AI tools, or are their tools compelling enough to get you to move your app and all your data to GCS?
Please don't post glib cliched comments. There's a valid point behind this but the same one-liner appearing several times on every Google product announcement is just tiresome.
Google states it's a beta tool, that should set expectations right.
Its worthwhile reminding consumers to not jump on the next Google bandwagon blindly. Its Google's job to convince us wrong, looking at this should help get perspective:
https://killedbygoogle.com/
Given that it essentially takes ML product/tool and removes literally all agency and control or tuning you have over it and puts it entirely in Google’s hands, I’d avoid it anyway.
Does any of this announcement affect Google Datalab? It feels like they keep Datalab as some second class citizen, that doesn't even get a spot in the menu bar in the cloud console and doesn't get any love when all of these let-us-build-the-model-for-you products get all of these announcements and upgrades.
The point of autoML from what I've gathered is to make it as easy as can be to get a model working in production. AutoML at least AutoML Vision is using transfer learning to retrain X number of layers from their algorithm (the one google uses is escaping me right now). The number of layers it has to retrain is the value they offer, it tries and tries optimizing for accuracy.
I've had good results with it, but you do have to do things their way and its not always well documented. If you want more control you should create your own model and host it on google app engine, otherwise AutoML is what it is, no way to customize or tune it other than changing the training data you give it.
I'd be curious to know who has used one of these end to end "AI" services in production for a successful, market fitting product.
From my experience doing this for a handful of companies, it's almost always better long term to use ML libraries that fit into the organizational architecture that exists, rather than outsource the whole ML pipeline. It's a serious amount of lock in to do that.
Maybe it's a an easier sell if your entire pipeline is already built into GCP and you're just tacking this on as a parallel path.
Agreed with the long term benefits on fitting into existing architecture.
I did speak with someone in financial services who’s been all GCP and they are quite impressed by the way everything is integrated and how they do not have to shift data from storage to train.
TMForum are developing an end to end standard for model dev and management, unfortunately it's closed but I really think that standardised components (feature store, model store, model registry) and model non functionals (identity, use history, status) with standardised API's are pretty necessary. BTW : deployed to prod is only 50% of the story; someone poor fool has to manage (and account for) these things in life!
I'm thinking of integrating this into Polar for people that use our cloud sync support.
I should be able to use the documents and their tags to build more derivative tag data so that when I'm given a new document I can compute a set of automated tags for the user.
This way when you save a document to your repository it's given some suggested tags.
Only a fool would use any of these platforms and large companies never will. The ml industry is full of fledgling products that no one should ever use and clearly if you use this you will be locked into google forever
> Please don't impute astroturfing or shillage. That degrades discussion and is usually mistaken. If you're worried about it, email us and we'll look at the data.
> Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.
I wish that people would stop with this unproductive line of commentary. Google shuts down consumer products sometimes. Pruning back the set of unprofitable things you're working on is good business. Expect to see Google and literally every other successful company continue to take this approach to unprofitable lines of business.
Also, how would putting ads on a developer platform be profitable? It's far more likely that they would charge money for it.
What it feels like is:
An engineer at google builds something cool. Management decide it could be a product, and a bit of tooling here and there and BAM it’s released.
It goes well, then it stays. It goes poorly or even just average, then it gets thrown out. And what of the users who put faith in the new product? Screw them it’s not profitable enough.
Compare to AWS, an engineer writes something cool, it gets evaluated by a project team, the business benefit and support infra is put in place, its trialed with a few users, its honed, then if it gets good KPIs then it’s generalised and released as a product. They subset very slowly and always make sure there’s a clear migration path, with humans in support to help the developers if need be.
Saying “Google and literally every other successful company continue to take this approach to unprofitable lines of business” is too reductive : nobody is contesting that a business shouldn’t cut out unprofitable actions, but the repeated, drastic culling and the “f-you we know best” attitude they take makes developers distrust google.
Google is too whimisical with both releasing and retiring products.
AWS is not a consumer-facing organization. The standards there are entirely different. Google Cloud has a much more stable offering than Google writ large. Very few of the products on gcemetery.co are cloud-related.
How is AWS not being consumer facing relevant? Both Google and Amazon started out being consumer facing and now have a cloud division. Their cloud divisions not being consumer facing is irrelevant.
The person I'm responding to is comparing product shutdowns between AWS (a cloud services divsion of Amazon) to Google (a company that contains both a cloud services division and a vastly larger consumper products division). This is an apples to oranges comparison. That's how it's relevant.
Before you say, "Amazon never shuts anything down, even outside of cloud." A) They do [1]. B) They have a tiny range of products compared to Google, so of course the absolute frequency of shutdowns will also be lower.
And before you say, "Well, better to have nothing than to have something and have it shut down." A) Some people [2] would disagree. B) Just don't use products in the category (consumer services) that Google tends to shut things down in.
But, please, whatever you do, don't spam every single thread where Google launches a cloud product (a category where they have a decent track record) with your gripes about Google Reader or whatever. It's not helpful and it's not relevant.
It's worth noting that earlier in the Google Next keynote, they had a slide on Privacy and that they will not access your data in GCP unless you request that they do so.
3) How many times a month will the API you're using get deprecated and how much developer time will you have to dedicate to keeping up with Google's API changes?
I'm really not happy to see this. This further entrenches people into Google's AI platform where all the input data will be harvested for ad revenue and even further profiling of human data. Laws enshrining natural rights of privacy of personal data can't come soon enough.
Google Cloud does not use customer data for Google's search graph. No cloud does this.
From Google: "At Google Cloud, we do not access customer data for any reason other than those necessary to fulfill our contractual obligations to you. Technical controls require valid business justifications for any access by support or engineering personnel to your content. Google also performs regular audits of accesses by administrators as a check on the effectiveness of our controls."
12.1 The following terms apply only to current and future Google Cloud Platform Machine Learning Services specifically listed in the "Google Cloud Platform Machine Learning Services Group" category on the Google Cloud Platform Services Summary page:
Customer will not, and will not allow third parties to: (i) use these Services to create, train, or improve (directly or indirectly) a similar or competing product or service or (ii) integrate these Services with any applications for any embedded devices such as cars, TVs, appliances, or speakers without Google's prior written permission. These Services can only be integrated with applications for the following personal computing devices: smartphones, tablets, laptops, and desktops
[1] https://cloud.google.com/terms/service-terms#12-google-cloud...