
Snap commits $2B over 5 years for Google Cloud infrastructure - samaysharma
https://techcrunch.com/2017/02/02/snap-commits-2-billion-over-5-years-for-google-cloud-infrastructure/
======
randartie
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.

~~~
xux
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

~~~
late2part
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.

~~~
chrissnell
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 dedicated servers. We're almost at the scale where it
makes sense to leave leased baremetal for colocation. For a company like Snap,
it's hard to believe that they couldn't save a few hundred million by building
their own footprint in leased datacenter space.

The days of needing massive ops teams to run on owned and colocated hardware
are long gone.

~~~
charlesdm
For a company that has always been handed (basically free) money at obscene
valuations, why would you assume they care about two billion? Maybe it's just
as simple as that?

It's an excellent argument as to why I will not be purchasing this stock.

------
whalesalad
If I could do it all over again I would probably opt for Google. The
Kubernetes support is wonderful and the overall user experience blows AWS out
of the water.

~~~
toomuchtodo
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 between AWS and Rackspace; this was several years ago during an
interview, so maybe its changed). Sure, start in Google, or AWS, but at some
point you will either need to use multiple compute/storage providers
(redundancy) or go to your own gear (redundancy and cost).

Example: "In 2014, Moz CEO Sarah Bird said that it was spending “$6.2 million
at Amazon Web Services, and a mere $2.8 million on [its] own data centers.”
Simply put, the cloud killed its margins." [6]

EDIT:

simonebrunozzi: Forgive me, but when you're talking about hundreds of millions
of dollars in spend, "easy" is relative. It is _much easier_ when you're not
relying on underlying primitives that are difficult to reproduce on your own
at another provider (witness how terrible Open Stack is; no one wants to do
that if they don't have to).

Am I minimizing the effort involved for this discussion? For sure. But the
money involved...it solves most problems you would have migrating between
providers.

> It seems to me that you have no serious experience in the real world.

You are entitled to your opinion. I have seen the pain, and it is relative.
Its easier when someone says, "Here is the budget, just fix the problem", and
your vendor's (AWS/Google) margins are 20-40% (these are real margins pulled
from earnings reports); that's a lot of money you can put back in your own (or
your shareholders') pockets.

If you we're spending $2 billion dollars, and I told you I could save you $400
million by spending $100 million, wouldn't you take that deal? Even at $200
million, its a bargain!

For less than what Snap is spending on Google cloud infrastructure, SpaceX
built a rocket that can take a payload to orbit and return the first stage
successfully (SpaceX has taken on ~$1.2 billion in funding over the last 14
years). Moving out of a cloud provider is comparatively hard?

EDIT: Maybe this is a roundabout way to kick back to Google in order to get
preferential treatment on the Ad network. It sure isn't a logical decision.

EDIT 2: @ashayh: I'm not saying go back to good ol' bare metal. For $2
billion, you could build your own cloud provider out as an internal operation.
The amount that's being spent on Google Cloud is egregious, and worse yet,
common shares have no voting rights to push back against poor decisions like
this.

EDIT 3: @hueving: HN throttles my posting; editing this comment is my only way
to respond. Sorry about that!

[1] [https://www.wired.com/2016/03/epic-story-dropboxs-exodus-
ama...](https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-
empire/)

[1a] [http://www.informationweek.com/cloud/cloud-storage/how-
dropb...](http://www.informationweek.com/cloud/cloud-storage/how-dropbox-
moved-500pb-of-customer-files-off-aws/d/d-id/1325721)

[2] [https://blog.twitter.com/2016/overview-of-the-twitter-
cloud-...](https://blog.twitter.com/2016/overview-of-the-twitter-cloud-
platform-compute)

[3] [https://code.facebook.com/hardware/](https://code.facebook.com/hardware/)
| [http://www.zdnet.com/pictures/facebooks-data-centers-
worldwi...](http://www.zdnet.com/pictures/facebooks-data-centers-worldwide-by-
the-numbers-and-in-pictures/)

[4] [https://about.gitlab.com/2016/11/10/why-choose-bare-
metal/](https://about.gitlab.com/2016/11/10/why-choose-bare-metal/)

[5] [https://code.mixpanel.com/2011/10/27/why-we-moved-off-the-
cl...](https://code.mixpanel.com/2011/10/27/why-we-moved-off-the-cloud/)

[6] [http://www.thewhir.com/blog/moving-away-from-aws-cloud-
dropb...](http://www.thewhir.com/blog/moving-away-from-aws-cloud-dropbox-isnt-
an-anomaly-and-heres-why)

~~~
simonebrunozzi
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, and I've seen
hundreds of clients go through this exercise)

~~~
jsmthrowaway
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...

~~~
toomuchtodo
I really appreciate the kind words, and wish I had more than one upvote for
your comment. I'm not here for profit or ego, just to share what I have
learned and experienced for the benefit of others. "I am old, here are my
mistakes, do not make them" sort of thing. Whether anyone believes it, there's
a serious Bay Area echo chamber (which HN overlaps with); there is a whole
tech world out there that isn't startup culture/tools/methodologies.

If you're ever in Tampa or Chicago, let's grab a beer or dinner my treat.
Would love to share war stories.

~~~
eitally
While I agree with your position in principle, I also come from a "legacy IT"
world, the kind where systems are moved to public cloud because developers are
several steps ahead of the DC admins, or because the CIO wants all net new dev
to be on infrastructure he or she doesn't own. These are not "digital natives"
(who have no excuse, imho). These are the thick, long tail or large businesses
with aging infrastructure and a lack of willingness -- or ability -- to pay
for top talent.

An additional point is that even the second tier PaaS/IaaS providers (like
GE/Predix, for example) are trying to get out of the DC ownership business.
There's no compelling reason for them to keep their own DCs when a) it's
expensive to run & keep fresh, b) it's CapEx, and c) it costs them expensive
heads to organize and manage everything.

~~~
late2part
Snap shouldn't fit the model of legacy IT. To some degree, myspace did and
that's part of why they failed.

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

~~~
georgeott
Will Snap exist in 5 years?

~~~
stevenj
Yes.

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

~~~
partiallypro
They'll exist, doesn't mean they'll be relevant, or profitable. If I were
asked to bet against the stock, I probably would. Everything about their
valuation and IPO smells to high heavens.

~~~
stale2002
Fortunately for you, you can take that bet!

As soon as Snap goes public, you can short the stock. Go for it!

~~~
partiallypro
I prefer to deal in options, and options won't trade on the symbol for a
while.

------
krzyk
For ones (like me) wondering what Snap is, it is the company behind Snapchat,
they apparently changed their name few months ago (source:
[https://en.wikipedia.org/wiki/Snap_Inc.](https://en.wikipedia.org/wiki/Snap_Inc.))

~~~
andybak
Thank you. I was wondering the same.

------
sobinator
Many talking of software here, but at this scale I think we should be looking
at the cost of energy. Suppose Google has a true edge on the rest of the
market in terms of what the cost of a Watt is to them. Take that outlook over
the horizon of 5 years; all software arguments are thereby moot. If Google can
generate a Watt in 5 years at 10% the cost that AWS can, then this drastically
changes the equation.

~~~
smeyer
I don't follow these things closely, but what's the reason to expect that
Google will be able to generate a watt at 10% of the cost that AWS can? 10x
seems like a massively impressive edge to have over another huge player in the
market for a commodity good like power.

~~~
sobinator
Good question. No reason to expect Google beating AWS, but absolutely Google
beats Snap on price per Watt if Snap builds this infra out themselves. I'm no
expert, but I'd say that when the outlook is five years and you're Google and
you have your own internal energy hedge fund, a big margin (perhaps not 10x)
is within the realm of possibility.
[https://en.wikipedia.org/wiki/Google_Energy](https://en.wikipedia.org/wiki/Google_Energy)

------
nikcub
The timing is curious, they signed this dead and added $2B in fixed
liabilities on their balance sheet days or weeks before the S1 filing.

That they didn't wait until after the IPO suggests Snap may see the
partnership as a positive. Could also have been pushed from Google's end as it
is a nice way of bragging about a big get but without having to formally
announce it, and being associated with a hot IPO that will get a lot of
coverage.

~~~
eitally
Or they could have been running on GCP for a long while and just didn't
announce it previously....

(they initially built their product on AppEngine)

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

~~~
freyir
Maybe $400M/year unlocks Google customer support?

~~~
nikcub
Its the support level where APIs you use are no longer randomly deprecated

------
scottmcleod
Nice Snapchat files to IPO so they can pay Google bill. Wonder who wins in
this long game...

~~~
dopamean
Google. I can half imagine a scenario where Snap fails to meet growth
expectations and is bought on the cheap by google.

------
filereaper
I'm confused by this high cost, sure you might need lots of compute, but
storage tends to dominate over the long term.

Isn't Snapchat supposed to delete data after 30s or whatever?

Why this insanely high cost? Can somebody shed some light.

~~~
argonaut
1\. There are also stories (last 24 hours). These are often video clips.

2\. Like Whatsapp, server has to store the message until the receiver is
online again (until they open the app).

3\. Whatever systems they use for advertising, tracking, profiling, and
analytics is probably a significant chunk of their backend.

~~~
kevindong
> 2\. Like Whatsapp, server has to store the message until the receiver is
> online again (until they open the app).

The server actually has to store it for a maximum of 30 days [0]. Snaps get
deleted after 30 days (even if they're unopened). They're deleted immediately
once the Snapchat servers get confirmation they've been viewed.

[0]: [https://www.snap.com/en-US/news/post/how-snaps-are-stored-
an...](https://www.snap.com/en-US/news/post/how-snaps-are-stored-and-deleted/)

~~~
unixhero
Do you really believe that.

~~~
luckystartup
Sure, why not? They might work with the FBI to store data for specific
targets, and the NSA probably intercepts and copies a lot of data onto their
own servers, but I see no reason why the company itself would lie about this.
They probably do delete the data immediately for the vast majority of their
users.

------
ErikAugust
They started on App Engine, I believe?

Interesting that just having one startup like Snapchat start on their platform
made all the other little startups that came and went worth it.

------
jpeg_hero
This could be a major issue with the ipo. Wall Street investors don't take
kindly to long term commitments such as this. It looks especially impertinent
because it is on the order of their current revenue ($400m per year due to
google versus $404m rev 2016). The similarities in the numbers just beg
comparison..

------
anonu
Snap Inc can negotiate this number down if their revenue targets aren't met.
So its really just a pro-forma agreement that can be changed... Source: The
S1... the article fails to mention that part.

------
dhsbdb
Spotify are also heavy users of Google Cloud:
[https://news.spotify.com/us/2016/02/23/announcing-spotify-
in...](https://news.spotify.com/us/2016/02/23/announcing-spotify-
infrastructures-googley-future/)

------
eddd
So 2.5$/year per user, I am not sure if that is a lot. How much does facebook
spent on their infra per user basis?

~~~
stp-ip
For current user volumes. Due to them filing for IPO it seems right to assume
that they want to multiply their user count quite a bit.

------
010a
It is so concerning to me that the company has committed to spending an
average of $400M per year on cloud infra when their revenue is only $200M, and
they've revealed that user growth slowed from 17% to 3% in the quarter Insta
released Stories.

It'd be one thing if they were going to use some of the IPO money to cost-
optimize revenue, but I get the feeling that they need to focus on growing
revenue due to how Insta Stories gutted them in 2016. That means hiring more
people and writing bigger checks to Google.

And they're branding themselves as a "camera company." Their hardware division
does not contribute materially to revenue (not profit: Revenue), and
practically every other consumer camera company, from Kodak to GoPro, is
dying.

This is not a healthy company.

------
beefsack
For anyone else who was confused who Snap are, they do Snapchat (it wasn't
immediately obvious to me.)

~~~
plorntus
Hah yeah, to me too. Wasnt until half way through the comments I found out who
Snap was. Could have at least used the former name in the article somewhere or
their logo.

------
johnsmith21006
Google also owns a piece of Snap through their venture arm. Plus I would think
Snap will want to stay close to Google for access to their advertising
exchange. We are quickly getting down to just two advertising exchanges Google
and Facebook.

------
sebleon
What do you guys think Google Cloud's margins are like? Presumably, Google is
able to run a data center more efficiently than Snap could, meaning that the
savings of running their own data centers will be strictly less than GC's
margins... thoughts?

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

~~~
firloop
I think it may be possible due to sharing of Google infrastructure that Google
App Engine apps (what Snapchat runs on) are automatically blocked in China.
This trick allowed Whatsapp to spoof censorship recently by feigning a
connection to Google.com while truly connecting to an App Engine hosted proxy.

------
tabeth
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 haven't played around with it enough to say
for sure.

~~~
luckystartup
Most server backends can easily scale horizontally, including Ruby on Rails,
Node.js, and Elixir. The only requirement is that you don't keep any "state"
in your server code. A novice programmer can make this mistake in any
language, including Elixir.

Read about the "Twelve-Factor App":
[https://12factor.net/](https://12factor.net/)

The main bottleneck is usually your database, which can be tricky to scale.
You set up things like read slaves and sharding.

------
kriro
Makes me wonder if Google will buy a substantial amount of Snap stock and if
there were takeover discussions before the IPO. I'm not sure if I like this
from Snaps POV but it seems like they expect massive growth and possibly want
to focus more on the core business than on infrastructure (which could come
back to bite them strategically but I'm sure they got a very sweet deal).

------
fabbuki
Snapchat could afford to build its own infrastructure if it wanted to. A
similar sized Unicorn, DocuSign, has about 2000 employees and probably several
hundred million in revenue per year (valuation is around a billion or two,
depending on who you ask). They built their own data centers around the world.

But DocuSign derives a lot of money from B2B and uptime and location of the
servers is important to other Enterprises. DocuSign also started building out
its services more than a decade ago before a lot of the AWS or Google Cloud
infra got built. So, the decision to build your own infra is as much a
decision based on alternatives available. Few alternatives? Build your own
infra.

By staying on GCP, Snapchat also guarantees its service and uptime will not
change appreciably over the next several years. They built on GCP and
migrating the whole service off would probably be a gargantuan task (how do
you flip a switch and move all your compute overnight without hurting customer
experience?). Staying with GCP allows Snap to maintain consistency of service
while also buying time to build a transferable version of Snapchat that they
could move to other infrastructure after the Google contract is over.

Investors on Wallstreet don't like seeing huge changes to company strategy too
close to IPO. If GCP has worked for Snap thus far, it is far less risky to
investors for Snap to keep on going "business as usual." It's better to
overspend to guarantee certainty of service and business health over next few
years than do a massive capital investment. Once Snap gets off the ground
post-IPO, they can make longer term decisions about their infra.

------
angryteabag
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?

~~~
niftich
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.

~~~
krzyk
I also got confused (I was wondering "who is Snap, and why is he investing in
Google"), Snap is not that popular at the news sites that I read (which is
mostly Hacker News :), at least after their name change.

------
kartickv
It seems dangerous to commit to spending so much money for so long into the
future, with a particular vendor. Who knows whether Google Cloud will be best
for your needs four years from now? Price, performance, reliability, support,
whether it will have best-in-class abstractions, and so on...

------
general_ai
I wonder if they're still using Google AppEngine, or have moved to something
lower level. GAE resolved a lot of its scalability and isolation issues thanks
to Snapchat.

In a way, Snapchat was to GAE what Hotmail was to Windows NT back in the day —
trial by fire.

