Live data from Hacker News

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

techcrunch.com

261–270 of 311 posts

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

#261

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…

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) Like most discussions in this thread, this statement is way too general. Dropbox moved their storage from S3. What about EC2 or other AWS services they were using? Did they abandon all of those too?

You're overestimating the amount of work it takes to run compute on anyone other than Google or AWS.

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

#262
post #10

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.

Maybe $400M/year unlocks Google customer support?

Hi!

Terrance from Google Cloud Platform Support here. If you are having any issues interacting with our support team please drop me a line with some case numbers (tsg@google.com) and I will take a look and try and resolve them.

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

#263
post #70
post #28

Earlier quoted context omitted.

Because of google container engine (hosted kubernetes). https://cloud.google.com/container-engine/ Also them starting the project along with the knowledge they have internally scaling containers helps.

Can anyone here provide some info or make a comparison with the Azure Container Service here, or any AWS option? I'm going to go through all of the service offerings this weekend - from Docker Inc's Docker for Azure and Docker for AWS to the native container services on each.

Azure Container Service is simply a PaaS-ish offering of Swam, DC/OS, or Kubernetes. It still spins up VMs that you can log into, but handles deployment/provisioning of the product, and makes some assumptions about your use case. It's a great way to push a button and have a "real" deployment of those services to evaluate, especially if your goal is a platform-agnostic target. I work for an Azure-focused cloud consultancy and for any serious production environment we still build out a more custom deployment using a combination of Terraform, Chef, Cloud-Init, CoreOS, etc.

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

#264

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.

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…

Gitlab reversed their decision to go with bare-metal. They still plan to ditch Azure and the most likely candidate (already testing to move their CI infra) for the move is GCP/GCE and GKE from Google.

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

#265
post #29

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…

But that is one of the outs that Kube gives you. Start on Kube/GCE and then if needing, you can migrate to colo boxes, and dynamically even. The beauty of a Kube based cloud platform is you can literally start anywhere, go anywhere.

There are some companies using k8s not just for the ability to move, but as a hybrid starting ground. One bandwith intense workload is running with GKE for all state/databases, but uses a bare-metal k8s cluster for compute and bandwidth intensive stuff. They actually use federation and the bare-metal cluster basically looks for a local database doesn't find one and gets routed to the next available global cluster, which is GKE.

Due to the cache and read dependend nature of the database queries the latency impact is worth it.

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

#266
post #99

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

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?

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

#267
post #175

Earlier quoted context omitted.

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.

> 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 the…

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.

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

#268
post #165

Earlier quoted context omitted.

> 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 a…

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

> First, if you don't notice some random/unexpected EC2 instance failures, you don't have a big EC2 deployment.

The parent didn't claim they don't happen, just that (1) they were rare (a point you agree with, given the minimum usage needed to notice them) and (2) multi-AZ, multi-region failures nearly non-existent.

> The point is that even when you're using EC2, you still have to set all of that up.

It takes literally minutes to set up an ELB and Autoscaling group across five availability zones. How long does the non-cloud version of that take?

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

#269
post #164

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?

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.

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

#270
post #266
post #99

Earlier quoted context omitted.

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

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?

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

Post reply on HN