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

Snap commits $2B over 5 years for Google Cloud infrastructure

techcrunch.com

Post reply on HN
Print view View original

141–150 of 311 posts

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#141

Post by late2part »

patrickg_zill wrote: post #107
010a wrote: post #104

Earlier quoted context omitted.

No. In what world would Snapchat be paying the rates that you pay at your Denver colo center? Why is that even relevant? They pay what Google charges them, which is $0.08/GB egress. Probably less due to negotiated bulk discounts.

8 cents per GB is thus approximately $15 per Mbps (8 cents time 190)that Snap is paying, while Google is paying far less than 50 cents per Mbps. Is my math off?

Your units are off.

If I push 1 GB per month, https://www.google.com/search?q=1GB%2Fmonth+in+mbps&oq=1GB%2...

You can assume they are not paying list rate when they buy $400M of service.

If they push ~40gbps on average, that's 13PB - https://www.google.com/search?q=40gbps+*+30+days+in+PB&oq=40...

13PB is 13M GB. 13M GB @ .08/GB = $1.04M

$1.04M/40gbps = 1.04M/40000 = $26/Mbps.

I pay less than a 10th of that outside.

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#142

Post by treblig »

andrewstuart2 wrote: post #91
randartie wrote: post #50

Needing this amount of resources implies that Snap is expecting huge growth. This sounds like a really bad move on their part and they should have committed to building out their own infrastructure on 'bare metal' over the next 5 years instead. If you read their S-1, they list a dependence on Google cloud as one of their big risk factors. Yet they then go ahead and make this commitment instead of working towards elim…

Facebook reported $27 billion in revenue in 2016. Snap reported $400 million. You're talking two orders of magnitude lower than Facebook and almost three lower than Google. Snap simply does not have the resources to pour into custom data centers, even if they can raise $2 billion for infra over 5 years. Unless they have serious talent already, they're not going to match Google's massive 15 year investments by a long…

Yep, agreed. Snap only has 1900 employees.

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#143

Post by late2part »

chrissnell wrote: post #138
late2part wrote: post #126

Earlier quoted context omitted.

That random person is right. One can run a DC at scale of 50 racks at least 20% cheaper than GCP. That's $80M a year to hire 20 smart people at $2M a year and 200 reasonably smart people at $200k per year. Snap will vanish like their pictures.

I think you're very conservative on that estimate. We run an infrastructure on dedicated leased hardware (Rackspace). Our infrastructure costs are a fraction of what the equivalent public cloud footprint costs. With technologies like Kubernetes and CoreOS, our private cloud practically runs itself. We focus on apps and the developer pipeline, much like we would do if we were on GCP/GKE. We have approximately 60 dedic…

Agreed. I've become immured to paint the least rosy picture that makes the point.

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#144

Post by puranjay »

xux wrote: post #99
randartie wrote: post #50

Needing this amount of resources implies that Snap is expecting huge growth. This sounds like a really bad move on their part and they should have committed to building out their own infrastructure on 'bare metal' over the next 5 years instead. If you read their S-1, they list a dependence on Google cloud as one of their big risk factors. Yet they then go ahead and make this commitment instead of working towards elim…

I love Hacker News, where a random person can tell a company their $2 billion plan on infrastructure is "a really bad move" with authority

Assuming that large companies can't be wrong is the reason why we have Enron and Bear Stearns

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#145

Post by mjolk »

cookiecaper wrote: post #103
paulddraper wrote: post #54

Earlier quoted context omitted.

Precisely. Google Cloud is a good idea when you don't know how much infrastructure you need. Of course, maybe they got some killer promotional deal with Google. Seems likely.

Having a basic scaffolding in place on a hosted cloud and making sure your devops scripts are up to snuff is a good idea when you don't know how much infrastructure you need, because then when the situation calls for it you can fire up a new node on-demand. But unless you're still "in the garage" and a couple of DigitalOcean droplets are good enough, it's going to be much, much cheaper and usually much wiser to run y…

> Script your stuff out in Ansible or something similar, run it on your own hardware, and use GCloud/EC2 as secondary data centers for failover/backup/support/emergency bursts/whatever. You can have the flexibility without paying through the nose.

Except then you have to run your own networking and when shit fails (as disks, links, and switches are want to do), it's now "your problem". Hybrid clouds and not being a tenant is nice, but not without time and monetary costs -- by the time you have geographically distinct failover, you've also spent a non-trivial amount of opportunity costs making phone calls, flying around, and writing lines of code and config for things customers don't even know exist.

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#146

Post by toong »

_m8fo wrote: post #139

What's the back-end equivalent of "free scaling?" For example, with the front-end, if you have a SPA or a website that's completely static, you can serve static files and JavaScript in a way that scales horizontally for free. Is there a back-end designed (with compromises and all) in a way where scaling horizontally is free, at the expense of compute power or some other sacrifice? I want to say Erlang/Elixir, but I h…

Stateless applications are a big part of the answer. "Serverless" (like AWS Lambda) is an extreme impl of stateless that gets "free scaling".

You will need to keep state somewhere and AWS has some pretty decent solutions for that.

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#147

Post by mjolk »

stevenj wrote: post #74
georgeott wrote: post #44

Earlier quoted context omitted.

Will Snap exist in 5 years?

Yes. If anyone wants to bet against them existing, I'll take the bet.

What are the terms? I'd take that action if we're talking in their current form/focus.

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#148

Post by alex-mohr »

hosh wrote: post #101
hatred wrote: post #90

Earlier quoted context omitted.

> Also them starting the project along with the knowledge they have internally scaling containers helps. FWIW, Most of this are advertising gimmicks though and Google has a pretty different internal infrastructure for orchestrating containers that has hardly much to do with K8s.

Google Kubernetes Engine still runs Kubernetes. I never looked at the Borg or Omega source code and had never been worked on a Google team. It is my understanding that there are some key insights developed from Borg and Omega that became part of the core concepts of Kubernetes that gives it an edge over other open-source orchestration systems. These include grouping containers into pods and using label selectors.

Yes, many of Google's technical leads working on Kubernetes and Container Engine are former members of the Borg and Omega teams, so Kubernetes and our hosted version, Container Engine, both benefit from what we learned building those other systems. (I think our 5 most-senior engineers have ~40 years of container management systems experience between them now?)

And it's not just the rather-large core team directly on GKE and k8s, nor the related products like Container Registry [1], Container Builder [2], and Container-Optimized OS [3]. GKE and k8s benefit in other ways too: Google's internal kernel team helps debug customer issues when we trace them to the kernel, and people like Kees Cook are helping with the upstream Kernel Self-Protection Project [4] that make container technology more secure. In addition to that kernel work, Google also has rather-decent security teams and they work with us to improve security in other ways too.

Finally, re: toomuchtodo's question, "Why opt for Google if you're going to use containers in Kubernetes?" Because we hope you find that Container Engine is the best place to run Kubernetes -- and benefit from the other parts of Google Cloud Platform. If you ever find GKE is not that place, and you don't derive value from the rest of GCP, then exactly as toomuchtodo puts it: "You can even move to your own datacenter at some point (relatively) easily."

[1] https://cloud.google.com/container-registry/

[2] https://cloud.google.com/container-builder/docs/

[3] https://cloud.google.com/container-optimized-os/

[4] https://www.linux.com/news/google-developer-kees-cook-detail...

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#149

Post by mastazi »

From the article:

> Access to Google, which currently powers our infrastructure, is restricted in China.

What does this mean exactly? I could read the sentence above in two ways:

A- if a website is on Google infrastructure, then it will not be accessible in China

B- if a website is on Google infrastructure, then the cloud control panel will not be accessible to the IT operations personnel based in China

I think that it's the latter, I find it hard to believe that the scenario described at point A corresponds to reality. If that was the case it would have huge implications in terms of competition between Google and other providers.

Re: Snap commits $2B over 5 years for Google Cloud infrastructure

#150

Post by mjolk »

user5994461 wrote: post #47
pbarnes_1 wrote: post #27

Earlier quoted context omitted.

That's... just normal expenses. This is how things operate.

Nope. Not at all. Normal expenses are things you pay, and then you declare how much you just paid. This is not a normal expense, it's a long term contract. It states how much they'll pay IN ADVANCE over a long period of time. That can be used to make all sort of accounting magic , adjusted per year over multiple years however you like it.

Where cloud-hosting costs are recurring, it's something that won't amortize.
Post reply on HN