Comment by stephen | Hacker News Reader

Comment by stephen | Hacker News Reader

Wow. Kind of surprised such a borderline-desperate sounding post was allowed on the official Google blog.

I basically read this as "we're so technically superior in several ways ... wtf is everyone still using AWS instead of us?"

It reminds me of the attitude of one Google engineer I know, which is basically Google is such an amazing place, with such visionary leaders, and across-the-board smart engineers, that they can wander into any domain they want, and just assume they'll succeed/print money like AdWords.

I'm paraphrasing and also probably putting words into his mouth, so apologies for phrasing it in the extreme to make a point.

Part of me wishes it was that way: as long as you had the smartest people + biggest warchest (which they basically do), victory would be pre-determined. But capitalism has a way, if anything, of handicapping the existing giants, and you can't just wander into a field "because we're really smart" and assume you'll win.

</armchair business insight>. Feel free to correct my assumptions/biases.

disclaimer: I am the author, and work at Google Cloud Platform

Stephen, thanks for the direct feedback, seriously! We weren't shooting for desperate, if anything I had a bit of geek pride in my voice when saying it at our GCP Next events, and then typing it down for this post. As I've been helping folks onboard and understand the platform, I found myself explaining these facts pretty frequently, so I figured having it written down might be helpful for others. Any suggestions on what kinds of content you'd like to see us deliver? Things you'd want to know? I'm game!

Style in writing is about standpoint. Where are you coming from?

Leading with:

> Google Cloud Platform delivers the industry's best technical and differentiated features

Is clearly the standpoint of someone trying to convince you of something and the tone certainly put my hackles up. It's often more effective [1] to adopt the position of someone sharing what they find most interesting about a topic.

Instead of:

> How can a cloud platform be both Better AND Cheaper? > Easy: it turns out that the same technology ...

Maybe something like:

> What's fascinating is that the same technology that allows cloud platform to perform better for these workloads also allows it to be cheaper.

[1] http://www.amazon.com/Clear-Simple-Truth-Writing-Classic/dp/...

disclaimer: i'm the OP and work for GCP

That completely makes sense to me, and yet runs in mild conflict with the feedback below where at least some users want us to do a bit more "selling". I've heard numerous times from customers and prospects that they'd like for GCP folks to just "spell it out and tell me why I should pick you", so this was my take at doing exactly that.

I'm definitely trying to convince you of something, but I don't want my/our tone to have you come away with a negative impression, or for you to read it as anything other than an excited nerd happy about his tools. Thanks for the feedback!

You're backfilling your standpoint and it's working!

But yup, different forms for different audiences and this works well as supporting material for an investment in GCP.

blush

Would a little fun autobiography from folks on my team give the context/backfill required for us to make sense while being a little assertive?

Thanks for the book link, ordered up!

# Why I think it was bad

Saying "we're the better cloud" is a frail argument. Both GCP and AWS has strengths and weaknesses. People know that. Saying "we're the best" feels simplistic (and insincere).

Second, some of the things you mention (live migration, scalability, etc) are things that AWS also provide.

# What is good

The last part of your post, So, how can you optimize, was good. It wasn't bashing AWS, it was general, sound advice on how to build things for a cloud platform. More of that would have resulted in a better post.

Nearline is another good offering. You got great publicity on that when it was released recently. I think many felt it had better and simpler pricing, and a better structure for retrieval than glacier. That's what you should focus on.

No need to criticize your competitors or arguing that you're better than them in every dimension. Instead, build good products and let the customer decide.

disclaimer: I'm the OP and work for GCP

Sandstrom, thanks for the detailed feedback. Spending most of my day talking with customers, I've found that many, many folks don't really know those strengths and weaknesses very well. This post was written really in direct response to questions we get every day about "why should I choose GCP?"

A great example; in your comment you describe AWS as having live migration, which they do not. It's exactly this kind of misinformation that we were aiming to clear up.

I hear you loud and clear on more technical guidance; my team has been building http://cloud.google.com/solutions for the last year, let me know if that helps or if you have any ideas on what we should build next!

Thanks again!

Yes, you are right regarding live migration. I though that's what they used to avoid reboots for one of the Xen-vulnerabilities earlier this year. But it wasn't, it was a hot-patch of some sort. Thanks for clarifying.

> if anything I had a bit of geek pride in my voice

:-) Cool. It is impressive to beat AWS at a game that everyone assumes they are the best at.

> Things you'd want to know?

This is kind of weird...but no, not really...for my team, I think we're zealously happy with AWS and it's their game to loose.

And "only" 40% cheaper/x% faster isn't enough, given the switching costs of moving everything over. As long as AWS remains good enough.

So, basically my "it doesn't really matter that you're cheaper" attitude is what made the connection to "a great business/adoption rate doesn't come solely from technical excellence".

Which, as a programmer/technologist, is frustrating. If I knew what it did come from, I'd be off doing that, instead of kibitzing on HN. :-)

First off, I'm super happy that you're having a great experience in the cloud: given where we are in the overall adoption cycle for public cloud tech any win for cloud is a win for all of us.

>"given the switching costs" Perhaps that's the crux of the question right there; what if it was trivially easy? What if you couldn't tell beyond a different (lower) bill? Wouldn't it be awesome to run on several providers, load balance between them, and up your availability game to be redundant across providers? This is an area of real focus for my team, let me know if it's something of interest!

> what if it was trivially easy?

Yes, in theory that would be awesome...I think in practice, the limitations would be:

- Cross-provider latency for micro-services that are interdependent (e.g. right now we assume everything is in the same AWS region)

- API compatibility/codebase coupling, as our code is littered with "new AmazonXxxClient"

- Feature parity would have to be near-100%...e.g. we use the regular things like EC2, S3, Dynamo, RDS, but also IAM and Kinesis (...and, and...). Not to say "oh you just need IAM & Kinesis", but that for any feature, current or future, that doesn't have a direct comparison across all providers, makes cross-provider harder to do.

- Increased devops complexity; different ways to get into machines, different places to look for logs, different places to look for metrics (CW), different logins, different admin UIs...

If you're team is focusing on this, these are likely things you've thought of...

I would not be surprised if "cross-provider" becomes like "cross-platform", technically possible but rarely done.

E.g. in the 90s cross-platform Microsoft/Apple/Linux (or today cross-iOS/Android/web) applications existed, if the programmers were very diligent, smart, and worked behind API abstractions that hid any platform-specific, platform-differentiating features.

...but in reality, 95% of programmers didn't, and were coupled to one platform or the other. And that was basically fine/just the way things were.

GCP would probably have been better off if the "AWS marketplace" had worked out...

E.g. instead of "GCP runs machines + offers PaaS databases/caches/etc." and "AWS runs machines + offers PaaS databases/caches/etc.", then now both the "run machines" + "PaaS offerings" must be identical, it'd be much easier if cloud providers got out of the PaaS business.

That way both GCP and AWS just "run machines", and instead there is some sort of vendor / marketplace API where database vendor X can run in both AWS and GCP, and caching vendor Y can run in both AWS and GCP.

And so you use the db APIs and the cache APIs, with some sort of service discovery within each cloud, and ideally the management UIs for the db and cache are both hooked in the GCP/AWS consoles.

So, it's not "use Dynamo in AWS" vs. "use Bigtable in GCP" and they're kinda/sorta the same, it'd be "use (say) Voldemort in both" and they really are the same, and managed by the same vendor.

(And not "you start vendor X's AMIs/images in your account and then play sysadmin", but "you use vendor Xs already-running/multi-tenant APIs from your app".)

That said, it's not in AWS's interest to let others provide the PaaS part of the machine in a generic way.

And, realistically, I don't think other (non-cloud) vendors could have successfully provided the PaaS offerings that AWS has, at the same multi-tenant scale. E.g. pre-AWS, all of the vendors (like a DB startup) were focused on "scale single-tenant solutions", and not "scale multi-tenant solutions", which is likely an order of magnitude or more harder. So it made sense for AWS to do it instead (plus the obvious benefit to them of more AWS lock in).

Reply on news.ycombinator.com