Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spotify moves its back end to Google Cloud

news.spotify.com

Post reply on HN
Print view View original

331–340 of 397 posts

Re: Spotify moves its back end to Google Cloud

#331

Post by oaktowner »

lobster_johnson wrote: post #283
boulos wrote: post #181

Earlier quoted context omitted.

The old App Engine / API / Admin console era is over. All tasks have been migrated to https://console.cloud.google.com/ including some of the last App Engine specific administration things.

Slightly off-topic, but not too off-topic question: Does GCE have a text format for its configuration? My pet peeve with cloud services and their web-based admin GUIs is that you have to use the GUI or the APIs to do anything. You can't capture the current configuration and then replay it if anything is misconfigured. You can't save or restore the config. You can't diff the config across versions. Most SaaSes don't e…

Check out Deployment Manager...I think it has what you're looking for.

(I work at Google but not on Deployment Manager)

https://cloud.google.com/deployment-manager/overview

Re: Spotify moves its back end to Google Cloud

#332

Post by ec109685 »

snowwrestler wrote: post #294
abrookewood wrote: post #182

Earlier quoted context omitted.

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 y…

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 i…

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

Re: Spotify moves its back end to Google Cloud

#333

Post by ranman »

duaneb wrote: post #269
S4M wrote: post #57

Earlier quoted context omitted.

Man, you should consider remote options at least for the Customer Success given how low you're paying (is $50K really livable in San Francisco?).

$50k is livable, but on the other hand you have to live In a city full of people who don't shut up about the Internet. I'd say that's a definite net loss.

net loss -- see what you did there?

Re: Spotify moves its back end to Google Cloud

#334

Post by boulos »

boundlessdreamz wrote: post #321
boulos wrote: post #157

Earlier quoted context omitted.

I don't agree that AWS and Azure are actually competitively priced with Compute Engine anymore. Following our price cut last May and our custom VM shapes, we're often 40% cheaper: http://googlecloudplatform.blogspot.com/2016/01/Happy-New-Ye... that's a massive lead (and it's sadly not commonly known). So I agree with you, we need to do better in the perception war, but Compute Engine is hands down the leader in cloud…

GCE pricing is great but GCS is not. It is much more expensive than S3 or cloudfront (2.5x - 1.3x) when you consider per request costs. I have brought this up a couple of times on HN to Google cloud employees but nothing has changed. 1. https://news.ycombinator.com/item?id=10442654 2. https://news.ycombinator.com/item?id=10187600 Other problem areas for GCS compared to S3/Cloudfront 1. SSL support for custom domains…

That's fair, our native egress pricing is higher. We've chosen to partner with folks like CloudFlare for what we call CDN Interconnect (https://cloud.google.com/interconnect/cdn-interconnect) although this was a somewhat recent announcement.

As far as GCS pricing goes (rather than egress), I think we've been more cautious on the "cost per op" but really led again on cost per byte. This was especially true when we launched Nearline, triggering AWS to launch S3-IA (but with lots of caveats like small files and still a 25% higher base rate).

While not integrated directly into GCS / GCP, does going through CloudFlare alleviate some of your concern?

Re: Spotify moves its back end to Google Cloud

#335

Post by boulos »

Mayzie wrote: post #329
latchkey wrote: post #35

What Google Cloud needs is a better sales story. AWS consistently beats out Google in this respect. This story is welcomed and there should be more success stories published like this. My business is a heavy GC user (AppEngine, Datastore, CloudStorage, BQ, ComputeEngine, ManagedVM) and I couldn't imagine achieving what we have achieved in such a short amount of time on any other platform. We (myself and another guy)…

The only thing that is stopping us from having Google Cloud is lack of an Australian data centre. I'd love to be on Google Cloud, but requirements prevent us from doing so unfortunately :-/

Legal requirements? Internal company ones? Latency? ;)

Re: Spotify moves its back end to Google Cloud

#336

Post by boulos »

lobster_johnson wrote: post #283
boulos wrote: post #181

Earlier quoted context omitted.

The old App Engine / API / Admin console era is over. All tasks have been migrated to https://console.cloud.google.com/ including some of the last App Engine specific administration things.

Slightly off-topic, but not too off-topic question: Does GCE have a text format for its configuration? My pet peeve with cloud services and their web-based admin GUIs is that you have to use the GUI or the APIs to do anything. You can't capture the current configuration and then replay it if anything is misconfigured. You can't save or restore the config. You can't diff the config across versions. Most SaaSes don't e…

In (most?) places throughout the web-based console you can click a little link to show you the REST API equivalent of your resource (whether it's an instance, a disk, or a command you're about to do). You might be able to make the job of "exporting your infrastructure" somewhat straightforward from those, though I think I'd personally just write against the handful of APIs in Go. All of our newer offerings (meaning GCS, GCE, etc.) have really sane object models that just map directly to a fairly obvious, autogenerated struct in the Go client library. Here's the struct for an Instance:

  https://godoc.org/google.golang.org/api/compute/v1#Instance

Re: Spotify moves its back end to Google Cloud

#337

Post by ec109685 »

abrookewood wrote: post #190
milesward wrote: post #183

Earlier quoted context omitted.

Disclaimer: I work on GCP. AWS and Azure are not price competitive with GCP, we're routinely seeing a a 40% advantage. Check out HTTP://cloud.Google.com/pricing/tco

Seriously, go and talk to your marketing guys ... Everyone comes out better if there is a third horse in this race, but Google needs to step up your marketing etc. AWS has a massive presence in terms of conferences, documentation and mind share. Azure has a massive sales team that are offering huge discounts to buy business. Google has ... what exactly?

Yes, compare this to a typical Amazon high quality blog post: http://googlecloudplatform.blogspot.com/2016/02/Google-and-R...

You have no idea what is actually being offered after reading that. Is it a managed service, a recommended configuration of what.

Almost every Amazon blog post includes a walk through on how you actually use whatever they are talking about. To be fair, this post does link to more documentation, but it's general purpose and describes a variety of solutions.

Re: Spotify moves its back end to Google Cloud

#338

Post by benjaminRRR »

boulos wrote: post #335
Mayzie wrote: post #329

Earlier quoted context omitted.

The only thing that is stopping us from having Google Cloud is lack of an Australian data centre. I'd love to be on Google Cloud, but requirements prevent us from doing so unfortunately :-/

Legal requirements? Internal company ones? Latency? ;)

Latency is a huge one for AU. With AWS in SYD you can easily cover BNE, SYD, MEL and even AKL. The difference from SIN or TPE is very noticeable. SYD to PER and SIN to PER is negligible.

Re: Spotify moves its back end to Google Cloud

#339

Post by ec109685 »

jamesblonde wrote: post #169
nrh wrote: post #144

Earlier quoted context omitted.

Spotifier here. This is an important point. I have nothing bad to say about Cloudera or HWX (disclaimer: we're an HWX customer - we've had a pretty good experience), but I don't really see a compelling reason at this stage to manage your own cluster(s) (HIPAA/regulatory constraints, maybe?) Getting shared-storage and indepedently operated/scaled compute clusters on top of that storage isn't easily achievable with the…

In fact, I don't think large orgs like you (Spotify) really want independently operated clusters. That prevents easy sharing of data, causing data silos to appear. You really want to have true multi-tenancy, which isn't in Hadoop yet. Hadoop has worked more on Kerberos support at the cost of features like easy-to-use access control - Apache Ranger or Sentry anybody!?!?

Yahoo's Hadoop clusters operate in a multi tenant fashion for precisely this reason: to ease sharing of data between groups.

Re: Spotify moves its back end to Google Cloud

#340

Post by rtpg »

lisbakke wrote: post #326
bshanks wrote: post #310

Earlier quoted context omitted.

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).

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.
Post reply on HN