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

[andrewstuart2]

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 shot, even if you only consider the services they actually need to use.

[vidarh]

You don't need to have $400 million revenue and do custom data centres to pay less than the published rates for any of the public cloud providers. Heck, you don't need a million in revenue to be able to save on going managed hosting or bare metal colocated.

The key here is: Compared to published rates. They'll not be paying published rates, the same as there's no way Netflix is paying published rates at AWS.

They'll be paying extremely highly discounted rates, assuming they're negotiating team isn't staffed with a bunch of people who failed their business degrees.

[erichocean]

> You don't need to have $400 million revenue and do custom data centres to pay less than the published rates for any of the public cloud providers.

Out of curiosity, at what point should someone look into negotiating lower rates with AWS (in particular)? And how would they go about that?

[vidarh]

Anything more than a few tens of thousands per year, I'd say. I'm not sure where the lower threshold would be of when they'd offer it, but I know once you get into a couple hundred k a year, getting massive discounts is at least possible (know of specific cases). I'd say do your homework on what renting managed hosting would cost, and what using reserved instances would cost, and talk to your account manager and use the managed hosting prices as the argument (they will be far lower).

A lot of my consulting is on cutting hosting costs, and I've yet to have a client where we couldn't come up with substantially cheaper alternatives than AWS, but sometimes being able to show your account manager that you know how insanely high their margins actually are and that you have a credible alternative makes enough of a difference for them to end up sticking with AWS.

It also depends on ease of cutting the cost, I'd say. E.g. if 90% of your cost is bandwidth, and it's mostly serving up static assets, it's trivial to cut the cost dramatically by rolling your own mini-CDN outside of AWS (bandwidth prices at AWS are between 10x and 50x higher than the cheapest competitors depending on region if looking only at managed hosting or other cloud providers - more if you're large enough to look at peering options).

[erichocean]

Thank you.

[fulafel]

Is the comparison to Google's investments a good benchmark? Sometimes it's better to make something custom than to buy from a big corporation doing a more general thing at 100x your scale.

[andrewstuart2]

Sometimes. But look at Netflix. $8.8 billion revenue in 2016 and a good third of Internet traffic and nearly every single server they have is in AWS. They had their own custom data centers and made the choice to migrate to somebody else's infrastructure. I'm pretty sure they're doing just fine with that decision.

[Arnt]

That's a really good example. They talk a lot about AWS, and nearly every service they run is in AWS. If you don't pay close attention, you might think they're all-AWS. I expect that Netflix' AWS pricing reflects that perception.

The exception is serving films. If you watch a film, you receive bytes served by hardware built to Netflix' specification, running in leased space at a mixture of colos and ISPs. That's a really big exception. The third of internet traffic is that exception.

[ddorian43]

They don't use aws for cdn (i think level3 and many others) + they design custom server-cache which they put inside isps.

[erichocean]

> nearly every single server they have is in AWS

That's…not true. Netflix has a huge CDN[0] running their own custom-built servers that sits near customer endpoints.

I shudder to think of how much bandwidth they'd be paying to AWS if they didn't…

[0] https://openconnect.netflix.com/

[bogomipz]

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

They have 1800+ employees as disclosed in their filing. So clearly people resources are not a problem for SNAP.

Do you believe its not possible to build 4 datacenter - 2 US, 1 EU and 1 APAC datacenter for 2 billion dollars? These are tangible assets that you can depreciate as well. The lifetime TCO of a center rack is $120K

Source: http://www.linuxlabs.com/PDF/Data%20Center%20Cost%20of%20Own...

Here is a DC build vs buy calculator. So can see independently those costs are about right:

https://www.expedient.com/data-center-build-vs-buy-calculato...

[zhengyi13]

Disclosure: I work for Google, but nowhere near Cloud, and I have no knowledge of this deal.

Quite apart from the dollar costs and human capital required to build and maintain a DC, there's the lead time required to build the thing, and I'd speculate that that's potentially a significant factor in Snap's decision. Perhaps Snap are looking at e.g. how quickly Pokemon GO scaled their operation, and they're thinking for whatever reason that they might need to do something similar?

[vgt]

It's not just about hardware and data centers. Google cloud offers a global secure high performance sdn, scalability, manageability, things like versioning and deployment tools, code debugging, world class security, and high speed of innovation, all out of the box, or even as intrinsic qualities transparent to customer.

By the time you build your infra (5 years was mentioned), Google would have iterated on their offering and their own network and data centers for 5 years.

(Work on Google cloud)

[patrickg_zill]

There are datacenters for sale, every day of the year, in the USA, that are already operational, lit with fiber, already staffed with the needed people, etc.

Thinking about it more, there must be some other strategic reason behind their decision to go with Google.

[bogomipz]

I totally agree, you can't discount the lead times of things like zoning, permitting, and local bureaucracy. But on the other hand the time frame mentioned is a 5 year period.

[treblig]

Yep, agreed. Snap only has 1900 employees.

[iamgopal]

so one person for every line of code. nice. (..I hope this comment does not wipe out all my karma on hn...)

[mrweasel]

That seems like a lot of people, especially when they buy infrastructure from Google.

[thanksgiving]

I'd imagine not if that figure includes sales team for ads, content team for discover, and so on. Especially sales (I don't have any inside information, so this is purely speculation) can be pretty personnel intensive if you're trying to court ad buyers.

[the_duke]

Where did you come up with that?

Crunchbase says they have 100-250 employees. Their LinkedIn profile says 50-200.

[acchow]

It's in their S-1 filing

"1,859 as of December 31, 2016"

https://www.sec.gov/Archives/edgar/data/1564408/000119312517...

I hope you don't rely on Crunchbase or LinkedIn for anything serious.

[Alex3917]

> Needing this amount of resources implies that Snap is expecting huge growth.

It's a hedge. If they don't grow as rapidly as expected then they're betting that someone else will buy the excess reserved capacity from them for close to market rates. So in the case that they only use 1.5 billion dollars worth of hosting, they're betting that they'll be out, say, $25M rather than $500M. On the other hand they want to make sure that if they do grow rapidly then Google has the capacity to meet their needs.

[matt_wulfeck]

I've never heard of anyone buying excess cloud capacity from a private party. Is this a thing? Is there a market for this? Sounds like a security nightmare.

[Alex3917]

AWS reserved marketplace?

Security wise it's no different than any other instance; specific machines aren't associated with the party who originally reserved the capacity in any way.

[matt_wulfeck]

They're still just buying it from Amazon.

[late2part]

You're right. The deals businesses do at this level preclude you from selling the resources you've purchased at a discount to another party.

[ohashi]

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market...

[yclept]

Yes there are marketplaces for this with some providers like AWS. You are buying capacity (like a voucher) for a server not a particular server.

[dekhn]

Cycle Computing does this. ATLAS, an LHC experiment, recently demonstrated this. I even built a product at Google that made this possible. We used Native Client (users compiled their binaries using the NaCl toolchain) as one part of the security container.

[abalone]

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

It doesn't mean they won't. Apple is reportedly spending a similar amount on Google cloud.[1] They're also investing billions in building their own data centers.[2] Those things go together.

Do you really think a company facing literally hundreds of millions of dollars in cloud service bills is not going to run the numbers on plugging in their own servers.

[1] http://www.businessinsider.com/google-nabs-apple-as-a-cloud-...

[2] http://fortune.com/2016/02/02/apple-data-center-move/

[nikcub]

There is nothing about using cloud services that makes this a unique risk factor. With self-hosting replace "Google" with the companies own name and list all the things that can go wrong - it's pretty standard for a tech co. S1.

For ex. this is Twitter's risk item for running hosted services:

> Our business and operating results may be harmed by a disruption in our service, or by our failure to timely and effectively scale and adapt our existing technology and infrastructure

Continues bottom of page 26[0]

[0] https://www.sec.gov/Archives/edgar/data/1418091/000119312513...

[late2part]

So outsource the risk so you can blame someone else? Maybe....

[Klathmon]

Outsource the risk to someone who has an entire product devoted to that one area, and has many years of experience and is probably the largest provider on the planet for that service...

[late2part]

On the one hand - you're right. Google is good, I use GCP, they are competent and good to work with.

On the other hand "someone who has an entire product devoted to that one area, and has many years of experience and is probably the largest provider on the planet for that service" also describes Enron at the time.

Google's no Enron, but Size isn't the metric one should use.

[Klathmon]

But even taking Enron into account, A Taxi company would be stupid to try to drill and refine their own gas, even right before Enron went down.

Sometimes it's just better to pay someone else to do a job.

I agree that too often "put it in the cloud" is abused, but there are areas where it really shines, and looking at their filings it looks to me like Snap has done their homework and that it's going to be a good fit for them.

They are signing on with one of the biggest, they are building out their own infrastructure over time, they are signing up with a secondary provider just in case, and they lay out their reasoning pretty well for why they want this to be handled by someone who has magnitudes more experience at it than they do (the big one being that they point out their demographic is VERY fickle, and any kind of performance issues, outages, or major problems could easily be the thing that switches someone to an alternate service forever. And they themselves don't quite have a grasp on expected growth so going somewhere that you can scale at a moments notice is a great benefit!)

[lallysingh]

Parent listed 3 metrics. I don't think it's fair to pull one out and attack that instead of the combination of all 3.

[late2part]

you are right but i meant to imply enron was all three, but i didnt write that.

[yueq]

Facebook is not a good example here. Back to early 2000s there was no Cloud infra so they started from inhouse. Snap is a different story since they not only use GCloud but also have Google engineers support and oncall for them. Snap focuses on the Product and Growth that creates much more value.

[SoreGums]

The other thing you get with GCloud is multiple datacenters around the planet. Assuming Snap are going after the 2billion+ people not in America, this seems like an advantage to use someone else's gear. 2billion seems high, maybe it's the maximum negotiated on paper for the deal as opposed to the guaranteed?

When you have Adwords dollars pouring in it makes sense to go send out a few people to buy up fibre and land/power/water for datacenters on the down low....

[beisner]

This seems like the key to me. Yes, if I'm a SaaS company with low bandwidth requirements but have a ton of users domestically, maybe I'll build my own data center (think IBM, or maybe Salesforce). But if I am raising money in the hopes of scaling my user base into the billions, and I need hundreds of millions of people to be able to upload to and download hundreds of megabytes of data to my servers daily, and have those images be instantly available to every user's contacts worldwide, I'll build on top of Google's infrastructure, which was literally designed for these kinds of tasks. Buying the metal is just the tip of the iceberg when. Snap would have to design a high-throughput, globally consistent network of data centers, likely lay their own undersea fiber (as all the cloud providers have done), and assume all the technical risk that comes with building and operating that kind of infrastructure. I think they made the right call on this one.

[Forrest7778]

To be fair, they did address this concern under the 'Operating Leverage in Our Business' section where they said that they may look for another third party to rely on for cloud computing or they build their own infrastructure.

"We have committed to spend $2 billion with Google Cloud over the next five years and have built our software and computer systems to use computing, storage capabilities, bandwidth, and other services provided by Google Cloud, some of which do not have an alternative in the market. We are currently negotiating an agreement with another cloud provider for redundant infrastructure support of our business operations. In the future, we may invest in building our own infrastructure to better serve our customers."

[chetanahuja]

We run our infrastructure on public cloud but almost our entire stack is cloud agnostic (except for a particular big database service we use). So our serving nodes are distributed across many public cloud providers and we can make decisions based on location/cost etc. in different regions of the world.

The rule of thumb I've heard is that you should start looking beyond public cloud once your cloud spend hits ~200K/month. Since at this level, engineering and ops investments you need to make to maintain your own infrastructure start making more sense. I think it's safe to say Snap is beyond that threshold right now.

[paulddraper]

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.

[averageweather]

How much did that sales rep get in commission? ;-)

[cookiecaper]

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 your core infrastructure on your own colocated bare metal.

I've seen companies increase their server expenses by ~$1M/yr by moving everything to EC2, and they sit around congratulating themselves for it because now "they're in the cloud". There's no reason to do that!

Little humorous tangent: an AWS rep told someone I've worked with that Amazon really wanted to help them secure better pricing, because as new CFOs come from self-hosted companies and into AWS-dependent companies, the CFO's eyes bug out when they see the Amazon bills and EC2 becomes the first thing on the chopping block.

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.

[mjolk]

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

[Sanddancer]

And when EC2 falls over, like it tends to do a few times a year? Hosts fall over, stuff dies. Something the scale of Snap, you're going to be doing setups that look a lot like cloud anyways. Bringing new systems up either by cloning a disk or through using PXE, setting up clustering, possibly by using the stuff they're already using, etc. You're going to be writing a lot of the same fallover code if you're running on someone else's hardware, so why rent?

[mjolk]

> And when EC2 falls over, like it tends to do a few times a year?

Multi-AZ, multi-region complete failures are very, very rare. How often do you get a failure in your data center per year (that you notice)?

> You're going to be writing a lot of the same fallover code if you're running on someone else's hardware, so why rent?

The answer is in the question -- when rented things fall down and go boom™, your code runs and someone gets a text message with the receipt.

When a handful of the "wrong" disks decide to revert to air-blocking bricks or your upstream network provider has an outage, you're lucky if it's something you can fix by heading to the data center. I promise that AWS or Google is better at running a DC, and unless you're trying to enter the hosting business, I wouldn't advise spending the time and money to meet their uptime and features.

I've only managed data storage in the scale of many petabytes (and this was a handful of years ago) and honestly, I think it required at least 20 hours a week of babysitting by various staff. At Snap's scale and traffic patterns (viral content, lots of writes, so on), I imagine this is a very non-trivial spend on scaling, staffing, tech implementation.

At 2bb over 5 years, maybe Snap would benefit from rolling their own -- hiring 50 great hackers at a mildly conservative 250k/head (say 200k average + benefits + taxes + employee support costs (HR, payroll, recruiting, legal, etc)), eating a year or two of transition costs off their cloud hosting providers, then probably saving a bit of money even after hardware, bandwidth, facility, insurance costs. Hell, maybe they'd even open source some software and recruiting would get easier after conference talks of how they did it. Or maybe they get bought by Google or Facebook in a year. Snap's in the business of selling ads and getting more eyes on those ads. Whatever enables growth and doesn't serve as a distraction or speedbump is a "fine" decision.

[cookiecaper]

>Multi-AZ, multi-region complete failures are very, very rare. How often do you get a failure in your data center per year (that you notice)?

First, if you don't notice some random/unexpected EC2 instance failures, you don't have a big EC2 deployment. Even though there is a lot of pomp and circumstance around the cloud, when it comes down to it, your instances are still on a physical server in a datacenter somewhere and they can, and sometimes do, fail. In that case, as in every other robust production deployment, your application (hopefully) performs an automatic and graceful failover to its standbys. The location of the standbys is usually an configuration value. Not seeing any unique value proposition here for "the cloud".

The point is that even when you're using EC2, you still have to set all of that up. Contrary to popular belief, EC2 is not a panacea that can magically make your software reliable and redundant. It's just a nice interface that makes it easy to rent servers from Amazon.

The only benefit you get from EC2 is that someone paid by Amazon has to go pull the box, but your company could hire such a guy in-house for _much_ less than it's paying Amazon.

The onus is still on the developers to figure out all of the application stuff that's necessary to accommodate failover and make sure that everything plays nice with each other, and getting that working right is by far the most time-consuming part of deploying a high-availability application.

So EC2 doesn't add any extra resilience; it's just outsourcing the job of pulling a server to an Amazon employee/contractor instead of YourEmployer employee/contractor. If your company is big enough (and at Amazon's prices, you don't have to be very big at all to be "big enough"), that doesn't make sense.

I know EC2 et al are popular because people like buzzwords, but that doesn't make it good business (or does it? Investors love cloud because it keep capex low, and because investors are buzzword-driven like everyone else; saying "cloud" will make them like you more and want to give you more money).

For companies that are still in the garage (literally in the garage), shelling out $20/mo for a couple of cheap VPSes from something like DigitalOcean is going to be just fine. But once you get bigger than that, there's no way to avoid paying attention to this stuff, even if paying Amazon tons of money creates a false psychological connection that makes you think they're doing the work for you.

>The answer is in the question -- when rented things fall down and go boom™, your code runs and someone gets a text message with the receipt.

Let me fix that for you: when things fall down and go boom, if your code is written and your deployment is configured to support it, your product continues to work, and someone, somewhere, has to get a broom and sweep up some ashes.

Whether or not cloud is a reasonable proposition is primarily a question of whether it makes more sense for that someone who sweeps up the ashes to be on the corporate payroll of YourEmployer or YourCloudProvider.

>I've only managed data storage in the scale of many petabytes (and this was a handful of years ago) and honestly, I think it required at least 20 hours a week of babysitting by various staff. At Snap's scale and traffic patterns (viral content, lots of writes, so on), I imagine this is a very non-trivial spend on scaling, staffing, tech implementation.

EC2 is not a silver bullet. It's just an interface to allow you to rent servers from Amazon. EC2 users still have to babysit stuff, just not the hardware (though they still have to monitor resource usage, clean up disk space, and be prepared for things to blink offline with 0 notice -- again, all the normal things; only difference is that your hardware jockey is accessed through EC2's web support interface instead of Slack/cell).

>At 2bb over 5 years, maybe Snap would benefit from rolling their own -- hiring 50 great hackers at a mildly conservative 250k/head (say 200k average + benefits + taxes + employee support costs (HR, payroll, recruiting, legal, etc))

Vastly overallocating here.

>Hell, maybe they'd even open source some software and recruiting would get easier after conference talks of how they did it.

Unnecessary, there's already tons of great open-source software to handle HA deployments (usually, this is the software underneath the commercial UI that makes everything work; it's surprising how much "revolutionary" commercial software is just glue code and a point-and-click wrapping around an OSS workhorse).

Of course, once you get unicorn-scale, everything has to go custom and/or highly modified because no out of the box solutions can handle the load, and that will be the case whether their hardware is hosted by Google or not. Again, "cloud" does very little to relieve workload for all non-hardware employees.

And the added benefit of being a trendy tech company is that after your company creates some extremely specialized solution, you can open-source it and watch with an uncomfortable mix of amusement and horror as 90%+ of other companies's tech departments contort themselves into pathetic, desperate architecture pretzels so that they can become cool by abandoning a stable, proven, mature stack for your company's experimental, sputtering, duct-taped abomination that requires a PhD to even get to compile.

This pattern has become so commonplace that reciting any specific example feels trite. You can probably name 12 off the top of your head. Hadoop in particular is a victim of many gross offenses of this type.

>Snap's in the business of selling ads and getting more eyes on those ads. Whatever enables growth and doesn't serve as a distraction or speedbump is a "fine" decision.

Sure, but they don't have to set massive gobs of money on fire for no reason along the way. But then, I guess they wouldn't be part of the Silicon Valley family if they didn't.

[chetanahuja]

> Of course, maybe they got some killer promotional deal with Google

For sure. How much is this free marketing that Google cloud service is getting worth? I'm pretty sure whatever discounted deal Google gave Snap is more than made up by this free marketing blitz they're getting.

[theDoug]

Snap’s been a happy and public customer for some time, so any “free marketing blitz” would a) have essentially been used up before, and b) would truly have to be remarkable to work against some form of discount where the non-discounted remainder /still/ represents $2,000,000,000 over four years.

[chetanahuja]

First of all, extent of Snap's dependence on Google Cloud and this extreme volume of spend was never public.

Also, there's a difference between something being public (like press releases) and actively generating buzz where lots of (relevant) people are actively talking about this.

I think if you were in a GCE sales meeting yesterday you'd have noticed a lot of people jumping up and down in joy. They've been playing second fiddle to AWS and in desperate catchup mode. Their next cold call got so much easier. Their next close got so much easier. Screw all that, their inbounds suddenly went through the roof. Lots of smaller startups etc. who would have never thought of Google cloud as an option are now seriously considering it. A lot of people who are already on AWS just signed up for GCE out of curiosity "just to see what the big deal is about". I don't think there's any way to overstate the impact of this news on Google Cloud's future.

[robzyb]

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

If they ran on bare metal then they'd list that as one of their big risk factors too.

[omarforgotpwd]

True, but what's the opportunity cost of transitioning to bare metal? Is it worth slowing down development / feature releases / possible service outages? In the time it takes to transition, is it possible that cloud actually becomes cheaper than running your own infrastructure?

[conanbatt]

It might be a sort of signaling that google is a potential buyer.

[dharma1]

They're filing for IPO, I think that ship has sailed

[oskarth]

> 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 to be clear, how many billion dollar infrastructures have you built up? What about played a significant role in, witnessing the various trade-offs that have been made? Taken part of, in any shape or form?

Of course, if you have experience that's all well and good. But I would expect someone with experience to lead with it, not omit it, precisely because they know how important it is with all the trade-offs involved.

[lallysingh]

I think they're paying for technical runway. They're not a big company yet, but expect substantial user growth. Right now, they probably believe that growth is more important than profit. So they're going to spend their engineering resources on getting more users to use and keep using their stuff.

GCP isn't sticky. They can leave, or renegotiate, or even try to get Google to do some of their engineering work for them ("We'd really love if this API did this as well..."). Or some combination thereof to minimize risk vs max profits.

[antoniuschan99]

If you watch Jeff Bezos Ted talk years ago, he made the comparison that back in the day, Beer Brewers used to have to generate their own electricity.

Similarly, services like AWS provide companies with that type of infrastructure (data or internet in this case) so they can focus on building out features.

But to your point, it gets expensive at some point and I am surprised that Snap is still outsourcing this instead of having their own data centers. I guess it's because the CEO is not strong Technology-wise so the company is focused on Product?

[ciaranm]

But ensuring 5 years of guaranteed service at a fixed price is reducing their risk. It prevents Google from pulling the rug out from under them, or from the price going up and they have no option but to accept it.

I imagine part of their plans are to move away from the dependency, but while it exists - this is exactly how you reduce your exposure to that risk.

[runeks]

All in all, I would say that if needing a new cloud provider in case Google defaults is a big risk factor for your company, your company is in pretty good shape.

[londons_explore]

You can bet that guaranteeing such a large future investment, they will have bought themselves a pretty hefty discount too.

Perhaps a discount large enough that prices match or are even better than bare metal servers.

Remember, Google builds its own custom hardware and probably gets much better performance per dollar than you would get from HP/dell/IBM/etc.

[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

[Beltiras]

Difference is that a comment that simply states "bad move" is voted down in short order. This comment makes a cogent point about scales and infrastructure. This might be valuable. I love Hacker News too, just without the snark.

[bogomipz]

A "random person"?

How about a HN reader who is taking part in a discussion? They offered their view and why they believe that. Nowhere did they they claim "authority." Unlike your snide commentary they are actually contributing to the conversation.

[the_duke]

Yes, the OP does claim authority, by stating his opinion as a plain fact, without knowing anything about it other than the publicly available information, and at the same time labeling a company that has raised 2.6 billion and has 100+ employees as complete idiots.

Good discussion would have ensued after a statement like "I wonder why they don't build out their own infrastructure because at this scale it is usually cheaper to...".

I could imagine that with this big a deal, they could get rate reductions that get the cost down to a comparable level to building out your own datacenters (at least 2) and hiring qualified ops people.

It might very well be a bad move, but you really can't say unless you know more.

[pythonaut_16]

Would it be better for everyone to preface their comments with "This is only my opinion but..."? Making a statement in a comment implies speaking your opinion, unless you start making strong claims to fact or citing sources. We don't need the extra linguistic clutter of framing every statement as a matter of opinion.

[bogomipz]

The OP states in their second sentence:

>"This sounds like a really bad move on their part and they ..."

That's hardly a "factual" statement.

>"Good discussion would have ensued after a statement like "I wonder why they don't build"

Do we really need to preface our comments with personal opinion disclaimers? When someone says "it sounds like", it seems pretty clear that they are admitting they don't know all the details, so how can what follows that phrase imply authority? That's absurd.

[noelwelsh]

This. If opinions aren't welcome on HN the whole site is pointless.

[joeyspn]

On HN nobody knows if you're a dog, or if you run infrastructure at Facebook...

[vincnetas]

Or a dog running infrastructure on FB ;)

[andybak]

That's unfair. From what I can tell all the canines are on the mobile app development team.

[orbitur]

I... like the iOS Facebook app.

Especially as a fellow iOS dev, there's a few UI things I'd like to reverse engineer. Seems like every year they introduce something useful or cool-looking and I think, "Wait, how did they pull that off?"

[bostand]

The android app team consist probably mostly of whales.

(observation based on the fluidity of their app)

[lallysingh]

m.facebook.com man, it's been my happy place for fb for a few years now.

[richardboegli]

mbasic.facebook.com if you really feel that need for speed :)

[prrrnd]

woof

[sheraz]

LOL. So. Very. True.

[ben174]

To be fair, that company is run by these same 'random persons' that are commenting here.

[visakanv]

That doesn't mean anything, though. "Some people who do X also do Y" does not imply that "people who do Y are qualified to comment on X."

For example: Elon Musk is a Twitter user. I too am a Twitter user. So's Kylie Jenner, Donald Trump, and random spambots. Using the same service does not mean they're equally qualified to speak with authority about the same things.

[ben174]

Correct. That's why I said "to be fair". I'm saying the playing field is quite level, so we shouldn't judge a comment on whether we recognize their username, but rather on quality of content.

[visakanv]

> we shouldn't judge a comment on whether we recognize their username, but rather on quality of content

Ah right, I think I see the nature of our disagreement / misunderstanding. I totally agree with you on the general principle that quality of content should be allowed to stand on its own.

However, I believe that there are things that are context-specific things that the men and women in the arena will face. And these are things that those of us in the stands, however thoughtful and discerning, will never be able to appreciate them, because we simply do not know. (For a great read about this, check out Daniel Ellsberg's message to Henry Kissinger, on the reality of having access to top secret information: http://www.motherjones.com/kevin-drum/2010/02/daniel-ellsber...)

So for example. It seems obvious to me that the top comment is sensible and correct. Snap's CTO or whoever else made that decision is surely very familiar with the costs of being dependent on something like Google. So if they decide to do it anyway, I'm of the opinion that they're quite likely to have done it because of concerns that I am not able to appreciate, because I am not in their context.

Of course, there's a non-zero chance that Snap is making stupid decisions. But I think it's far likelier that they're making decisions that SEEM stupid to a 3rd party, but make perfect sense once you appreciate their context.

I could be wrong about this, of course.

[hluska]

I don't think you're wrong, but I'd like to point out something. Armchairing decisions like this is a wonderful learning tool. Not only does it give people the opportunity to mentally work through issues that most of us will never face in our careers, but it's a wonderful opportunity to practice diplomatic, yet persuasive writing.

You're right, we don't know everything that has gone into a decision, but that's part of the value of an exercise like this. Being able to debate about something, remain civil and deal with specific arguments is an incredibly valuable skill that only gets more valuable as you age.

[hackly]

Being a 'random person' or a Twitter user should have no bearing on the merit of one's arguments.

[brianwawok]

That was the point

[return0]

If both x and y are true for a person then he is definitely qualified.

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

[late2part]

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

[hamandcheese]

That's assuming that:

- GCP will always have a margin that high

- Snapchat is paying the advertised rate

- They can find the requisite talent in a reasonable timeframe

[origami777]

Bingo. They aren't paying advertised rates. Google will have margin but not as much as usual. Snap also has google by the balls here. What if snap comes out with a statement saying Gcp sucks and they're moving to aws?

[forgetsusername]

>Snap also has google by the balls here.

Surely they don't.

>What if snap comes out with a statement saying Gcp sucks and they're moving to aws?

Then we question why Snap committed billions of dollars to infrastructure that "sucks", and wonder why they couldn't figure it out, but Google could.

You think people will take Snap more seriously than Google itself?

[origami777]

Yes, I do think Google's biggest customer leaving their platform vocally would be more impactful than Google promoting/defending itself.

If Snap threatened to leave I'd wager that even the CEO of Google would get involved to keep their biggest cloud customer. Snap's revenue and brand name have enormous value to Google. There simply aren't that many $2 billion dollar cloud customers right now.

[late2part]

Snap signed a contract - how are they going to leave that contract? Yes, maybe if there is significant breach by Google, but that's lawsuit level.

[origami777]

without knowing what's in the contract there is at least one way I can think. Make a statement saying all new workloads are being deployed elsewhere. Lots of ways to play the game.

[brown9-2]

This only accounts for hardware cost.

What about the cost of writing the software services that you could pay Google Cloud to use?

How much would it cost to write your own Compute Engine, or Datastore, or Pubsub, or Bigquery?

[lallysingh]

Is 50 racks the right point of comparison here? Different scale levels will cost different amounts per server.

[puranjay]

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

[polishTar]

Large companies aren't always right, but they're not always wrong either.

Snap has competent engineering execs that have built a very strong company. I would have a hard time believing that they haven't put way more thought into this than OP.

[rifung]

I don't think anyone is assuming they can't be wrong. I think it's more that the post said this was a bad move "with authority" when you don't have all the information unless you actually were involved with that decision.

It might be a bad move still but we don't have all the information necessary so it's strange to just assume we know better.

[argonaut]

Completely wrong way to think about it. In fact, those companies are cases of fraud and lying, and we generally do not assume companies lie. When Google releases their quarterly earnings, we assume the numbers are correct, unless there is evidence to believe it's fraudulent.

[knorby]

Bear Stearns didn't fail due to fraud, it failed due to not adequately tracking and assessing the risk of its assets. It is worth noting that there have been serious allegations made a few weeks ago against Snap that they are lying on the S-1.

[0003]

Link?

[knorby]

https://news.ycombinator.com/item?id=13324514

[hluska]

You comment would be stronger if you removed the snark and actually refuted the parent's points. If you want to refute the points refute them, but this kind of comment adds nothing to the discussion.

The parent made some good points about scale and infrastructure. I've worked with infrastructure on many projects and I can't come up with a coherent argument why any of the parent's points are wrong. Can you?

[shaldengeki]

I think asking him to refute points gets to the heart of the issue -- in an environment where nobody has enough information to speak authoritatively on a subject, the people who are willing to do so anyways are advantaged. (Think about the qualifications or knowledge that one would have to have to make an informed assessment of this.) This is bad for productive discussion.

I agree that empty snark is usually unproductive, but in this case, I think there's a useful point being made. Still, always best to rephrase into non-snark. :)

[rampage101]

I read his point as praise of comment actually.

[partiallypro]

We'll learn when they have to report quarterly earnings what their cash burn is, then we random people can tell them how dumb they were in hindsight.

[StreamBright]

Here we value good arguments more than authority, I guess.

[deepnotderp]

Pretty sure HN readers work at these companies...

[partiallypro]

and HN includes investors and people in financial services...

[samuelbrin]

This made me smile. During a very trying time. Can you please make similarly awesome comments/observations on political forums?

[free2rhyme214]

I love this comment :)

[vonklaus]

Counterpoint: Maybe the agreement is breakable or they know they can resell the resources. This metric could be a good way to trick "tech savvy" analysts who don't care about total users.

I assume spending this much would give them a below market discount and they could recoup some of their losses if nec.

All this assumes it is a positioning tactic w/ a hedge. Maybe, they will just build a developer ecosystem a don't want to bifurcate their engineering output. If twitter fails, it would validate this choice as they can pay a slight premium and if their metrics increase build infrastructure in 2.5 years w/ more info to spec it

[burntrelish1273]

Snap needs to have consistent booked revenue in order justify this sort of outlay.

This is akin to dot-com era companies signing long leases on buildings or small business owners buying lots of inventory. Plus, 2 gigadollars could easily buy 4-10 soup-to-nuts datacenters that have tangible (although less) resale value.

Overexpansion is easy to do and super risky... these sort of moves increase expectations and scare off wise investors.

[late2part]

Maybe. I agree with your sentiment, but a lot of investors say "cloud" - ooh good, I like Google, so Google Cloud must be good, buy Snap Stock!!!

[burntrelish1273]

Ideally, a company should use a hybrid of cloud and on-prem as a p&l dial to adjust risk and agility.

EDIT: for super scrappy startups playing with on-prem with lab-like reliability, https://unixsurplus.com/ is awesome.

[yAnonymous]

When Google eventually buy Snap, it's better for them to already manage the infrastructure.

Then everyone can honestly announce that Snap user data won't be handed over to Google - because it's already there. ;)

[ulfw]

It begs the question what their product really is if so much is outsourced to others and where the valuation is at if all it is is just branding.

[azinman2]

Network effects are massive, and they keep iterating on product successfully. You're focusing on the least interesting bit that's outsourced.