I think the difference you observe relates directly to the difference between what Google does outside of Cloud Platform and what Amazon does outside of AWS.

Vanilla? Boring?

I read "Vanilla" and "Boring" as "Horray, I don't have to spend time rewriting all this complicated code I already have!"

If I'm just dipping my toes into (say) Caffe or Theano, I don't have to rewrite it from scratch.

That is a huge advantage---not a disadvantage!---of AWS over google.

Your point is valid, but I think what the OP was saying is that Google is offering all this stuff IN ADDITION to the boring stuff.

Google does boring stuff very well too.. and one can argue much better than AWS as well.. take a look at Quizlet's story: https://quizlet.com/blog/whats-the-best-cloud-probably-gcp

(shamelessly biased Googler)

If I recall correctly, it took Google a while to actually offer the boring stuff. For a while, you could get a Google Compute Engine but you couldn't just get a dang VM image, because Google knows better than you and you should do things their way. They've fixed it now, but lost a lot of potential market share for that conceit.

"So"?

If you're evaluating something today, how does it change your decision that we were late to market with Compute Engine (and in this specific case "bring-your-own-kernel")?

If it's about future boring stuff, I think the list of boring stuff isn't too long ;).

Disclosure: I work on Compute Engine.

All given, the fact that Google itself doesn't extensively use GC is kind of a red flag(I know quite a few Googlers from search infrastructure and none of them said their teams used GCE internally).

A solid guarantee with AWS is if AWS goes down, then a multitude of Amazon's services also will go down(ex Amazonian myself), so it gives me a belief that AWS's uptime is more important to Amazon itself that it is for external customers.

Search Infra (and Ads for that matter) is an extreme case. Google Search might be one of the worlds most highly tuned infrastructure projects: a marriage of code and hardware design to maximize performance, scoring, relevance and ultimately ROI.

Before we had custom machine types (November 2015 GA), we wouldn't have been remotely close to what they needed. I'm not even sure we've had anyone evaluate the amount of overhead KVM adds in either latency or throughput.

tl;dr: Don't let Search be your "not until they do it". We've got folks in Chrome, Android, VR, and more building on top of Cloud (as well as much of our internal tooling being on App Engine specifically).

Google Firebase uses GCP including GCE extensively.

(Firebase Engineer here)

"So" Google lost potential business for a while from people who wanted to spin up VMs rather than wanting to ship code to a proprietary execution framework.

I think you're agreeing: We certainly missed a huge segment of the market at the time, but now that we've got GCE new business can certainly come our way.

If I recall correctly myself (getting old!), Google has had the ability to build your own custom image since GCE went GA 2.5 years ago. Now, admittadly, it took a while to get IAM and VPC going, but we done did it now!

I'd love to hear what other boring stuff has been a showstopper for you, in case we missed something dumb :)

Not having Managed Postgres and Managed Redis are 2 main showstoppers for me.

True but There are 3rd party managed services from both...

Minus the massive downtime that just occurred recently. https://status.cloud.google.com/incident/compute/16007

Not implying that AWS hasn't had them. It's just that adopting GCE this early makes you a bit of a guinea pig because GCE isn't used internally at Google.

Meaning even deeper level of vendor lock -- now you cannot even find the chips to run your application elsewhere!

No - tensorflow is open source and you can run it on many platforms. TPUs are about efficiency. You might not be able to do image recognition as efficiently without one, but you can still perform exactly the same tasks.

(I work on TF this year.)

Well, that is good to know. Thanks for clarification.

All of the comparable tools are practically locked into nVidia gpus/CUDA. TensorFlow is rapidly reaching performance parity on that hardware [1] and can now be run on this so it's actually sort of the least locked in framework.

[1] It has been climbing the charts at https://github.com/soumith/convnet-benchmarks for example.

It's possible, but I think that the majority of ML optimization as seen by a programmer using tensorflow is more about optimizing the balance of accuracy, training & inference speed, and memory use, and a lot of the solutions in this space are pretty hardware independent. There's an entire other type of optimization about, e.g., making conv2d insanely fast, but that's not something that a typical data scientist-type user deals with.

(To elaborate -- it's questions like "how deep should I make this convolution? Should I use tf.relu or tf.sigmoid? How many fully-connected layers should I put here, and how big should I make them?". These are really knotty deep learning design questions, but they're often h/w independent. Not always - we certainly have some ops on TF that we only support in CPUs and not on GPUs, for example - but often.)

I am more thinking in terms of:

  1. Best price/performance is tensorflow right now. So, the best software choice is platform X.  
  2. Then in 2 years.. Well we are using Platform X so tensorflow is clearly the best option.

In other words once you pick conv2d, you tend to also stick with whatever conv2d is optimized for. Which also means HW vendors love to help optimize popular platforms.

Others can make TF hardware too. Now that Google has opened the way, they will compete.

- Google Container Engine

- Cloud Shell

to name a couple more.

...are you saying Google isn't a real business?

no it's just that google has so many shiny things that come and go, if you build a business with shiny new things, you will propably fail if you do that over and over again, just because its shiny and new.