This reads like they've been acquired by Google and are integrating. Now Google just has to write the check and own music streaming.
Spotify moves its back end to Google Cloud
251–260 of 397 posts
Re: Spotify moves its back end to Google Cloud
#252Earlier quoted context omitted.
Google Cloud SQL is no replacement for Amazon RDS in my opinion. Cloud SQL instances run outside of your project's private network, so connections from Google Compute Engine have to be over a Public IP. This means accepting connections from any host (insecure) or whitelisting each Google Compute Engine VM's IP address (pain in the ass). I've resorted to running my own MySQL instance inside of Google Compute Engine an…
Look no further (for item 1 of 2 anyway) — http://googlecloudplatform.blogspot.co.nz/2015/12/the-next-g...
With RDS one can create a postgres/mysql instance that shares the same internal subnet thus negating need to open it up to external IPs, something I had to do after much deliberation because whitelist individual instance IP is just too much pain.
[edit: I looked at the link, and created a test instance to make sure I wasn't missing on a config setting, still unable to use private network to communicate with Cloud SQL AFAIK]
Re: Spotify moves its back end to Google Cloud
#253I have some questions based on previous experience many moons ago experience (3 or 4 yrs). When I tried to port some of our platform to AppEngine I had some issues with various Java libraries (writing tmp files, opening sockets, etc). Once I sort of got past that and used some of Googles own APIs (which is sort of annoying that I had to couple my stuff) I had timeout issues. See we have to integrate with all these en…
The Google Cloud Platform services they are identified as using are: Cloud Storage, Compute Engine, Cloud Datastore, Cloud Bigtable, Direct Peering, Cloud VPN, Cloud Router, Cloud Pub/Sub, Cloud Dataflow, BigQuery, and Cloud Dataproc.
So, its not surprising that they might be doing something that Google AppEngine doesn't support particularly well.
[0] http://googlecloudplatform.blogspot.com/2016/02/Spotify-choo...
Re: Spotify moves its back end to Google Cloud
#254Earlier 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?).
This may shock you, but yes, it's livable. Many people live on $50,000 or less everyday in San Francisco. It may not be a standard of living that we as engineers are familiar with, but it is not poverty either. It's not a salary you'd want as a household income with dependents, but for an individual it is fine.
And many more people live on $50,000 or less everyday working in San Francisco, but commuting from somewhere else in the Bay Area with lower costs.
Re: Spotify moves its back end to Google Cloud
#255Earlier quoted context omitted.
That's why no one does it. They have roommates
As a grown adult, having roommates is not really an acceptable situation.
I know plenty of grown adults that have roomates, because they prefer the quality of accommodations they can afford that way to what they would be able to afford without them. (And not even in places with Bay Area-level high cost of housing.)
If it is unacceptable to you, that's fine, but don't pretend it has something to do with being "a grown adult".
Re: Spotify moves its back end to Google Cloud
#256Earlier quoted context omitted.
What kind of support am I going to get if I'm just tinkering with the platform? Maybe I'm just used to AWS but I always found the GCE interface (at least for launching VMs) a lot more difficult to use.
Sorry to hear that. Is there something specific about our current console you find hard to use? Perhaps I'm used to both (and I'm biased) but I like our create instance page just fine. Like I mentioned above, we do have active communities on Stack Overflow, per-product mailing lists (in this case https://groups.google.com/forum/#!forum/gce-discussion ) and Server Fault.
Re: Spotify moves its back end to Google Cloud
#257Great now they can free up some engineers to bring their Linux client out of beta, which has been in beta since dinosaurs.
Re: Spotify moves its back end to Google Cloud
#258I have some questions based on previous experience many moons ago experience (3 or 4 yrs). When I tried to port some of our platform to AppEngine I had some issues with various Java libraries (writing tmp files, opening sockets, etc). Once I sort of got past that and used some of Googles own APIs (which is sort of annoying that I had to couple my stuff) I had timeout issues. See we have to integrate with all these en…
AppEngine is Google Cloud Platform's PaaS offering. Its the oldest product on Google Cloud Platform, but its not one of the ones mentioned that Spotify is using (the Spotify post doesn't talk much about the products, but Google's [0] does.) The Google Cloud Platform services they are identified as using are: Cloud Storage, Compute Engine, Cloud Datastore, Cloud Bigtable, Direct Peering, Cloud VPN, Cloud Router, Cloud…
I don't really call big data processing "backend" but rather the microservices the backend. Its not clear to me if those are going to be ported over or if they are already.
Does spotify plan on porting everything over or just the heavy computing? A detailed techy case study I hope will follow soon as I am interested (the DevOps pain is very real).
Re: Spotify moves its back end to Google Cloud
#259Earlier quoted context omitted.
App Engine expects your web apps to return almost immediately (in a matter of few ms). For anything that takes longer, you need to use task queues in App Engine. Or maybe try AppEngine Managed VM's?
App Engine requests time out after 60 seconds (that's 60000 ms). https://cloud.google.com/appengine/articles/deadlineexceeded... (I work at Google, but not on App Engine)
https://cloud.google.com/appengine/docs/java/modules/#Java_I...
If you run multiple modules at once (some serving the frontend, some for longer tasks w/task queues), you can have the best of both worlds and use different scaling options for each.
(I also work at Google, but also not on App Engine)