Live data from Hacker News

Why we are not leaving the cloud

about.gitlab.com

211–216 of 216 posts

Re: Why we are not leaving the cloud

#211

Earlier quoted context omitted.

Did you have to sign a NDA? Because if people send you random advice via email after reading a blog post then this sounds to me very much like "publicly sharing" their experience...

I disagree. It's a private email. Gitlab can ask permission to post, but it would be impolite and perhaps unethical to assume a private email is now "public". If they wanted it public, they could have chosen to provide a comment on HN, Twitter, etc.

Apparently according to syste some of the best arguments came from emails, so he could have put those arguments anonymised and trimmed down to the main points into the blog post, which would have respected the company's privacy while still sharing good arguments, unless there was a NDA which would prohibit that.

So I disagree with you, because you look at this very black and white while the reality is grey.

Re: Why we are not leaving the cloud

#212

Earlier quoted context omitted.

I get the sentiment, but it really depends: For some services, it's very true. For other services, careful problem analysis will show that you only need one or two features from the full package, which then can be replaced by a very small shell script.

Can you give an example where a shell script would solve the problem? Curious to know

Last month, I needed to add a periodic job to a simple Rails app to snapshot some data and send it to another system. I discussed the design with a colleague, a Rails expert, who went into the pros and cons of various worker-queue configurations. In the end, I added a hidden API call, and deployed a shell script along the lines of

  while true; do
    curl https://rails.app/do/the/thing
    sleep 3600
  done
The actual version is slightly larger because of error checking etc., but that's the gist. So that's one example of replacing (or rather: avoiding) a distributed system (an asynchronous job queue) with a small shell script.

I don't mean to say that shell scripts always can replace more complex systems, but sometimes they're enough.

Re: Why we are not leaving the cloud

#213
As a potential Gitlab customer (I would be running an instance in the cloud if I moved off of their hosted offering), this removes the main concern I had with migrating to their platform.

Fundamentally the performance problems they had could be solved by either software or hardware, and I have more faith in the team's ability to learn the distributed computing / caching techniques required than to learn how to run their own metal.

Re: Why we are not leaving the cloud

#214

Earlier quoted context omitted.

> equally astonished in 2017 > Prime Video, Hulu, HBO GO, YouTube Red, So Netflix has a six year lead and attendant network effects in it's favor. If you don't believe me, I created a facebook clone in PHP last weekend which works just as well (or better) than the original Facebook. Do you want to join it?

> So Netflix has a six year lead and attendant network effects in it's favor. I completely agree with you. I personally have a Netflix account, and do not subscribe to other services. My point is that right now, today, this very instant in time, Netflix is not primarily differentiated on technology, but on having content that their subscribers want; that online video distribution is now a commodity.

> but on having content that their subscribers want

This is where we disagree. I don't even know what content Amazon or HBO or Hulu has at this point. Netflix has already made me a lifelong customer with their product and user-experience in the past 10 years or so that it'll take an earth-shaking difference in content for me to switch (or add) a second monthly bill for content. Netflix is part of social fabric (at least in the US). All of this was won by relentless focus on an excellent product and user experience... and perhaps only a middling content catalog.

Re: Why we are not leaving the cloud

#215

Earlier quoted context omitted.

More than likely so that the video feed is as close to you as possible, rather than only because of cost efficiency. The video is the most important part of their product, so keeping it at your ISP or a local exchange not only lowers latency, but most likely also gives better throughput since it only has to travel through your ISP's network or local exchange links without having to go through the rest of the internet…

Its not "more thank likely", it is the real reason. CDN's could not keep with their volume AS WELL as pricing structure. Latency ( 30ms vs 300ms) doesn't matter much in video playback, only throughput. Once you hit play, it isn't bi-directional. But you're just nitpicking. This IS their core business, and they realized its "too core" to give to someone else. So yes, you do "outgrow the cloud", and well, part of "outg…

Right, but that alone shows that the reason they didn't go for the cloud for those has nothing to do with the capabilities of it, just that the locations are not close enough to their userbase to make sense.

Put another way, if there was a cloud DC in each major city and Netflix hadn't already started using their own edge nodes, then there's nothing stopping them from spinning them up in each cloud DC as opposed to their own hardware. There's nothing inherently special about their setup except location.

Nothing about this situation says that Netflix "realized its "too core" to give to someone else." I don't quite understand how you're making that leap. Instead, they had a very specific requirement (that most companies don't have, mind you) that current cloud hosts can't provide. Nothing else.

Re: Why we are not leaving the cloud

#216
post #16

Why was hybrid not considered? With providers like megaport providing really inexpensive direct connect, this is almost a no brainer. This may seem harsh, but relying on random commenters shows a huge flaw in how you guys went about this. Physical environments DO work well, but they do require experience to run them. I have used AWS for as long as its been around, but nothing beats physical environments for "known wo…

> Snapchat spends MORE in cloud infrastructure in 2016/2017 per year, than ALL OF GOOGLE did in 2012

Not 2012 but in 2013, Google spent 7.3 Billion dollars on data centers [1]. Snap's has agreed to spend a minimum of 400 Million dollars per year on Google cloud according to their S1 [2]. Where did you get your figures?

[1]: http://www.datacenterknowledge.com/archives/2014/02/03/googl...

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

Post reply on HN