Live data from Hacker News

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

techcrunch.com

41–50 of 311 posts

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

#41
post #36

Earlier quoted context omitted.

Ha! Assuming we're discussing the US, I'm consistently amazed at how complicated it is. The number of tax accountants and wide success of TurboTax lend credence to the idea that it's more complicated than a lot of people want to deal with.

I guess I should have been more specific. Really I mean the basics like how tax brackets and deductions work.

Even deductions can get pretty hairy, in my experience. And frankly, if you have to say "just the basics", you're talking about a system that has more than just the basics. :)

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

#42
post #19

This makes no sense. One cannot spend $33M a month on Google Cloud. (Remember that it's half the price of AWS, and given a contract of that magnitude it's possible that they negotiated yet another half off). The amount of hardware and services one would get for that bill is insane. Snapchat doesn't need that much computing power and storage.

I'm not so sure. $33M would buy 412PB of egress alone. At 160M daily active users, that's roughly 2GB per user. In just bandwidth. That's high, and they've probably negotiated some deals to lower their bills, but also consider instances, storage (photos and videos), 10% of their bill is easily support... $33M a month is the right magnitude. The more I think about it, the more I wonder if it's actually way too low, an…

[deleted]

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

#43

So they hit $400m of revenue in 2016 and have committed to spend at least that much on infrastructure each year for the next 5 years? After all the costs for staffing and everything else they better I hope they achieve amazing growth if they ever intend to profit.

I think Techcrunch read: We have committed to spend $2 billion with Google Cloud over the next five years and decided "that's $2B/5=$400M per year." In reality, it's probably more like $200M, $300M, $400M, $500M, $600M

The filing says:

> On January 30, 2017, we entered into the Google Cloud Platform License Agreement. Under the agreement, we were granted a license to access and use certain cloud services. The agreement has an initial term of five years and we are required to purchase at least $400.0 million of cloud services in each year of the agreement, though for each of the first four years, up to 15% of this amount may be moved to a subsequent year. If we fail to meet the minimum purchase commitment during any year, we are required to pay the difference.

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

#44

So they hit $400m of revenue in 2016 and have committed to spend at least that much on infrastructure each year for the next 5 years? After all the costs for staffing and everything else they better I hope they achieve amazing growth if they ever intend to profit.

Will Snap exist in 5 years?

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

#45

Can I get someone's opinion on Snap? Is it worth paying attention to? My understanding is that it's a package manager that installs applications in their own isolated Linux sandbox, meaning you can install/distribute them on any distribution.. right? Does that mean software like node.js or nginx/apache will be available via Snap?

I think you're confusing the company formerly known as Snapchat, now called 'Snap Inc.' with the 'Snappy' package manager (hosted out of 'snapcraft.io') which makes linuxy packages called 'snaps'. The two are unrelated.

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

#46
post #45

Can I get someone's opinion on Snap? Is it worth paying attention to? My understanding is that it's a package manager that installs applications in their own isolated Linux sandbox, meaning you can install/distribute them on any distribution.. right? Does that mean software like node.js or nginx/apache will be available via Snap?

I think you're confusing the company formerly known as Snapchat, now called 'Snap Inc.' with the 'Snappy' package manager (hosted out of 'snapcraft.io') which makes linuxy packages called 'snaps'. The two are unrelated.

I am getting confused and you nailed it. I'm referring to Snappy

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

#47

Earlier quoted context omitted.

There is surely a way to turn that into "accounting debt" that will cancel lots of taxes and save a lot of money one way or another.

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.

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

#48

This makes no sense. One cannot spend $33M a month on Google Cloud. (Remember that it's half the price of AWS, and given a contract of that magnitude it's possible that they negotiated yet another half off). The amount of hardware and services one would get for that bill is insane. Snapchat doesn't need that much computing power and storage.

I guess that speaks about the scale at which they are operating in Google Cloud. Diane Green mentioned in a recent conference that one of their healthcare customers collect about 2 PB / user. Lot of companies struggle with managing / extracting value from data. Thats where the bottle neck is usually. If they have capability to handle more data, overtime their services evolve to collect, store and process more data. O…

By "user", you mean an entire company that houses data on thousands or perhaps millions of patients, right?

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

#49

Earlier quoted context omitted.

Why opt for Google if you're going to use containers in Kubernetes? You then become cloud agnostic. You can even move to your own datacenter at some point (relatively) easily. Dropbox built out their own environment (and did it migrating 500PB out of S3) [1] [1a]. As did Twitter [2]. And Facebook [3]. And GitLab [4] (too soon?) As well as Mixpanel [5]. Even Twilio is multi-cloud (last time I checked it was split betw…

Easily move? It seems to me that you have no serious experience in the real world. There's something called "data gravity", and the non-secondary issue of how to migrate a "live" system (in production) from one cloud to another over the course of typically several weeks. Moving from one cloud to another, even with containers, is never easy at large scale. (source: I have worked at AWS for 6 years, at VMware for 2, an…

I consider 'toomuchtodo a voice of authority on operations based on much reading and discussion (particularly on moving to physical, which we've discussed before), have performed the very exercise being discussed four times in my own career ranging from a couple cabinets to a couple hundred million in capital, completely agree with the entire comment to which you are replying, and feel that your jab about "serious experience in the real world" was totally unnecessary.

If moving operations around is insurmountably difficult, you built operations incorrectly. Put another, even broader, way with a few more implications: if you are totally reliant on one vendor for continuity of any part of your operations, you built operations incorrectly and are introducing unnecessary risk. If us-east-1 goes down and you cease generating revenue as a result, you have built operations incorrectly. That's really all there is to it. And yes, I realize this means 80%, maybe more, of the operations in in the world is built incorrectly. We just learned Snap's is[0]. Maybe even yours! And that's fine as long as you're working on it. Good news: said exercise is a good chance to fix it!

Now that half the crowd is inhaling to bombastically retort that undoubtedly controversial, yet completely true, paragraph, allow me to quickly redirect:

What's "the real world," anyway? Most of HN forgets a Windows/.NET ecosystem exists, not to mention extra-valley gigs in, say, Nebraska. Would you say the lone sysadmin holding together a hospital in Des Moines is gaining "real world" experience and able to meet you in discussion? Seriously, I hate "the real world" and the people who fire it as a volley during an argument. Even your career is not indicative of "the real world." (Nor is mine.)

[0]: Flagrantly so. I've spent the better part of an hour trying to concoct a scenario where that deal is even remotely in the win column for Snap. Still trying. You enshrined a business disincentive (nay, prohibition!) toward optimizing your opex into a five year contract and $400mm a year operating Snap was some kind of win? ... How on Earth? Even with a quarter billion DAUs...

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

#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 eliminating it.

There's so many advantages to owning your stack and if Snap thinks that it's going to need 2 billion dollars to pay for cloud infra, they're at the scale where it makes sense to build your own infra. Just look at Facebook, they're able to create tailor made data-centers that fit precisely what they need. The success of Snap relies on huge scale on the consumer side, if they want to scale their infra to support that 5 years down the line then this sounds like a poor move since they will either need to play catch-up later on or prepare to pay serious dough to Google.

Paying for cloud services seems like a great idea when you are not able to predict your needs in the coming years, given a deal like this I don't think that's the case.

Post reply on HN