5 ms·

Sometimes though, the scale of these things is enough to make programming (and operations if your into that) completely exhilarating. Things that seem extremel

by spotman 10y ago

Sometimes though, the scale of these things is enough to make programming (and operations if your into that) completely exhilarating. Things that seem extremely trivial, like chat, or the ability to upload photos, become quite an engineering feet when your measuring the amount of photos uploaded at terabytes per hour or more.

gjolund 10y ago
Snapchat runs on Google infrastructure, and brags about having 0 devops employees. Scale these days is a solved problem, there is nothing they are doing scale wise that I can't do in a couple weeks using AWS. AWS Lambda functions make on demand filters and photo editing trivial. It is one of their demo functions.
- lotso 10y ago
  >Scale these days is a solved problem, there is nothing they are doing scale wise that I can't do in a couple weeks using AWS. Excuse me for being blunt, but this to me seems like a statement someone would make who has never worked at this scale.
  - gjolund 10y ago
    I have. Both high burst scale after Super Bowl ads and long running massively multiplayer games. I am not saying that building services that operate at a massive scale is easy, but there is a wealth of talent and tools out there to help you achieve it. The fact that all of snapchats infrastructure is provided as a service makes my point for me.
- vgt 10y ago
  I think you vastly underestimate Snapchat's scale and vastly overestimate AWS out-of-the-box scaleability. Someone like Snapchat periodically surprises GCP with millions of QPS, something AWS would deem akin to DDOS. With AWS, you'd need to carefully setup infrastructure that statically accepts such scale. You need to plan, test, deploy resources, measure, etc etc. Snapchat has to do absolutely 0 of that - they deploy code. This is a major difference between Google and AWS - with one you can setup scale, but you pay for it, and with the other you get scale as part of your service, out of the box.
  - gjolund 10y ago
    Great response. Out of the box I agree with you, GCE is much more capable than AWS. However in my experience AWS is just as capable and much more flexible once it has been setup. Also AWS Lambda functions give you the ability to "deploy code" and has proved to be massively scalable. I feel that "carefully setup infrastructure that statically accepts such scale" is not an accurate way to describe top tier deployments on the AWS platform.
    - vgt 10y ago
      Minor correction: Snapchat runs on GAE, not GCE. PaaS, not IaaS, so nearly EVERYTHING is taken care of. Something like this is impossible on AWS without pre-warming, pre-setup, or maybe even calling someone - https://www.youtube.com/watch?v=xT6tQAIywFQ&feature=youtu.be https://www.youtube.com/watch?v=xT6tQAIywFQ&feature=youtu.be Here's another example: EMR versus Dataproc. Dataproc has per minute billing + very fast startup times (sub 90s for decent-sized clusters). So with Dataproc, you can rethink how you run Hadoop. Rather than starting with a cluster, which you fill up with jobs, you can have "cluster setup" as part of the job path. This is possible because you don't pay a large penalty in startup, nor do you pay a large penalty in per-hour billing granularity. Oh and Google is much more inexpensive (http://fortune.com/2016/01/08/google-amazon-cloud-price-war/ http://fortune.com/2016/01/08/google-amazon-cloud-price-war/).

by spotman 10y ago

gjolund 10y ago

Snapchat runs on Google infrastructure, and brags about having 0 devops employees. Scale these days is a solved problem, there is nothing they are doing scale wise that I can't do in a couple weeks using AWS. AWS Lambda functions make on demand filters and photo editing trivial. It is one of their demo functions.

lotso 10y ago
>Scale these days is a solved problem, there is nothing they are doing scale wise that I can't do in a couple weeks using AWS. Excuse me for being blunt, but this to me seems like a statement someone would make who has never worked at this scale.
- gjolund 10y ago
  I have. Both high burst scale after Super Bowl ads and long running massively multiplayer games. I am not saying that building services that operate at a massive scale is easy, but there is a wealth of talent and tools out there to help you achieve it. The fact that all of snapchats infrastructure is provided as a service makes my point for me.
vgt 10y ago
I think you vastly underestimate Snapchat's scale and vastly overestimate AWS out-of-the-box scaleability. Someone like Snapchat periodically surprises GCP with millions of QPS, something AWS would deem akin to DDOS. With AWS, you'd need to carefully setup infrastructure that statically accepts such scale. You need to plan, test, deploy resources, measure, etc etc. Snapchat has to do absolutely 0 of that - they deploy code. This is a major difference between Google and AWS - with one you can setup scale, but you pay for it, and with the other you get scale as part of your service, out of the box.
- gjolund 10y ago
  Great response. Out of the box I agree with you, GCE is much more capable than AWS. However in my experience AWS is just as capable and much more flexible once it has been setup. Also AWS Lambda functions give you the ability to "deploy code" and has proved to be massively scalable. I feel that "carefully setup infrastructure that statically accepts such scale" is not an accurate way to describe top tier deployments on the AWS platform.
  - vgt 10y ago
    Minor correction: Snapchat runs on GAE, not GCE. PaaS, not IaaS, so nearly EVERYTHING is taken care of. Something like this is impossible on AWS without pre-warming, pre-setup, or maybe even calling someone - https://www.youtube.com/watch?v=xT6tQAIywFQ&feature=youtu.be https://www.youtube.com/watch?v=xT6tQAIywFQ&feature=youtu.be Here's another example: EMR versus Dataproc. Dataproc has per minute billing + very fast startup times (sub 90s for decent-sized clusters). So with Dataproc, you can rethink how you run Hadoop. Rather than starting with a cluster, which you fill up with jobs, you can have "cluster setup" as part of the job path. This is possible because you don't pay a large penalty in startup, nor do you pay a large penalty in per-hour billing granularity. Oh and Google is much more inexpensive (http://fortune.com/2016/01/08/google-amazon-cloud-price-war/ http://fortune.com/2016/01/08/google-amazon-cloud-price-war/).