Live data from Hacker News

Why we are not leaving the cloud

about.gitlab.com

161–170 of 216 posts

Re: Why we are not leaving the cloud

#161

Earlier quoted context omitted.

Recommending someone to build in the cloud is an easy and safe recommendation to make. Therefore, more people will go that route when asked what you should do. Pretend for a second you plucked someone from a royal family that never prepared their own food, and they asked you how to make food. Are you going to recommend they purchase land, start a farm, grown their own vegetables, and raise their own cattle? Hell no.…

I don't think the cloud is the grocery store. It doesn't give you a pre-packaged solution that you can just rip open and immediately access. Rather, the cloud is like leasing the land from an owner. You still have to till, plant, maintain, and harvest, but you have to pay an annual rent to do so. There are a few things that the landowner is responsible to provide, but most of the day-to-day maintenance responsibility…

I think most cloud providers go beyond that. For example, creating/restoring snapshots with a UI, monitoring/automation tools, large scale DB services, etc.

I rent dedicated servers from a large-scale provider. They're really good at hardware and networking, but that's all they do (well, that and some OpenStack S3 equivalent). I have to do my own Icinga monitoring, Ansible automation, etc. For the type of product I run, it's fairly simple. It's maybe not as cheap as owning the hardware, but I think it's a good compromise.

Not to mention that when everyone is using that same tool from Amazon, and at some point it gets big and clunky and its development stalls because people rely on it never changing.. then other options out there eventually leap frog. (I strongly dislike the google-cloud UI, I waste so much time when I have to use it for one of my clients that has stuff there)

Re: Why we are not leaving the cloud

#162

Earlier quoted context omitted.

> If you wanted to compete with Netflix, you would need to do a lot more than uses Amazon's cloud services. Yes you'd need multi-million dollar contracts with all of the major studios. Netflix isn't as much a technical problem as it is a business problem. HBO has a far worse network, UI, and technology in general but its still competitive simply because it has Game of Thrones and other shows.

Scratch business problem, replace with "legal problem". Copyright law makes it virtually impossible to compete with Netflix. Netflix was only allowed to start because they wedged their way in as a rent-by-mail service. After pioneering streaming and realizing that the studios were asking themselves why they don't just load up their own computers with movies and get paid to stream them out, Netflix was forced to start…

I don't understand what this has to do with copyright laws. This has to do with content licensing and studios not wanting to license content...

Re: Why we are not leaving the cloud

#163

So everyone says the cloud is the future. I get it. But is this the truth, or what all the tech giants want people to believe? Don your foil hats for a moment and listen to me. All the original internet companies run their own hardware. They rent out excess production capacity to us peons in the form of cloud services. These companies that all run their own hardware exclusively are telling everyone that it's stupid t…

So if I understand you correctly, if I need an appendectomy I shouldn't consult a doctor, but rather open up an anatomy book and do the procedure myself?

Re: Why we are not leaving the cloud

#164

Earlier quoted context omitted.

Why should he re-architect his system and introduce some Amazon-specific dependencies like S3 just so he can give Amazon money? How much development time and money will he spend trying to make his setup work on AWS? How many new bugs will he accidentally introduce in the process? How badly will moving to cloud storage via S3 affect his performance v. having the files on a local disk? When S3 outages like the one that…

>Why should he re-architect his system and introduce some Amazon-specific dependencies like S3 just so he can give Amazon money? You could make the same argument going the other way though - why should GitLab spend money recruiting/hiring people, leasing space, setting up monitoring, etc, if their solution today works? Why should anyone re-architect their system to give $COMPANY money? When your bare metal's RAID con…

>You could make the same argument going the other way though - why should GitLab spend money recruiting/hiring people, leasing space, setting up monitoring, etc, if their solution today works? Why should anyone re-architect their system to give $COMPANY money?

Well, that reason would be, at a minimum, a halving of their hosting expenses.

It also doesn't necessarily take much refactoring to move either way. Even if you're heavily dependent on cloud storage, etc., you can access that from an external application server.

The person I replied to was suggesting that the parent refactor in order to make AWS costs less egregious without articulating any particular reason that the original commenter should do so.

> When your bare metal's RAID controller craps out and you have to order another, will his customers be understanding of his decision to move to bare metal?

His customers won't need to know, assuming he has a standby that can take over. Even if he doesn't, he can rush down and install one and move the disks over. With an AWS outage, you can't do anything but say "I hope Amazon fixes it soon". The bare metal equivalent is a power or connectivity loss at the DC, which is much rarer than AWS outages.

Re: Why we are not leaving the cloud

#165

Earlier quoted context omitted.

Scratch business problem, replace with "legal problem". Copyright law makes it virtually impossible to compete with Netflix. Netflix was only allowed to start because they wedged their way in as a rent-by-mail service. After pioneering streaming and realizing that the studios were asking themselves why they don't just load up their own computers with movies and get paid to stream them out, Netflix was forced to start…

I don't understand what this has to do with copyright laws. This has to do with content licensing and studios not wanting to license content...

The copyright laws are what give studios the rights to license that content. Right now, most things published commercially after 1923 are copyrighted and require permission from their rightsholder to distribute. That's practically the entire history of cinema locked up tight.

Copyright should be adjusted so that people can make money off of their creations without allowing the culture to be held hostage to corporations. If the copyright term was shortened to, say, 10 years, a Netflix-with-only-content-from-10-years-ago would be totally viable without having to ask for anyone's permission.

Copyright is a government-granted monopoly. It's gotten totally out of control and severely restricts competition in this type of space.

Re: Why we are not leaving the cloud

#166

Earlier quoted context omitted.

I know Netflix runs their own edge nodes, which is precisely why OP sounds incompetent and uninformed. Netflix has spent lots of time and effort into analyzing and building the architecture which is optimized for them. > Or do you think facebook,google,aol,tripadvisor and pretty much anyone beside HotNewStartup are incompetent? Far from it, and that's precisely my point. At Facebook scale, it certainly makes sense to…

I bet to wager Netflix and Snapchat are at Facebook scale. Certainly $500M/ year in cloud commitments for the next 4 years seem to indicate so.

I'm not sure, but I am sure that someone internally is doing those calculations.

Re: Why we are not leaving the cloud

#167

Earlier quoted context omitted.

I have not once said that cloud is the only option. You're arguing with a straw man. If you're spending millions on infrastructure, you should absolutely do a rigorous analysis of whether the cloud is better or worse.

Yeah, it's not a direct quote. However, that is how I interpret the sentiment that those who fight the cloud will be fired. You suggest that's an unfair interpretation? You can say "cloud may not be the only option" all you want, but "those who oppose cloud will be fired" ensures that somehow, everyone in your organization will believe the cloud to be a supremely good option. :)

Because I do fully believe that the cloud is the superior solution for most businesses, especially those employing sysadmins.

I've seen way too many companies with full-time sysadmins maintaining only a few dozen servers. The significant cost savings come from eliminating those positions.

Re: Why we are not leaving the cloud

#168

Earlier quoted context omitted.

Your opinion isn't really that original. There are plenty of old-school sysadmins who will insist that the cloud is a hoax. They'll fight tooth and nail to avoid it. Eventually, someone fires them and moves to the cloud with significant savings. There are some scenarios where it makes sense to run bare metal, but they're few and far between. If you've evaluated the (capital, operational, and human) costs of cloud vs.…

> There are plenty of old-school sysadmins who will insist that the cloud is a hoax. They'll fight tooth and nail to avoid it. Eventually, someone fires them and moves to the cloud with significant savings. Those "old-school sysadmins..." get hired by large cloud companies. Amazon has plenty. The cloud is just somebody else's computers.

Sure, and that's precisely the operational efficiency which comes from cloud providers.

Re: Why we are not leaving the cloud

#169
Every time I see a post from Gitlab, I worry for them. I haven't used gitlab but have checked it out a few times. On the other hand I use github regularly. But this isn't about github vs gitlab.

Instead this is about gitlab's definition or rather level of transparency and something they seem to be proud of and are even being appreciated very often here at HN. I feel that gitlab have taken the transparency thing to an extreme, to the extent that they even named the engineer that caused a recent downtime. I don't think it matters that the engineer didnt object to it. Then there are posts about why they are choosing some UI framework and why they are moving away from cloud and now this. It's fine to be transparent but in a professional world it's also important to be private about certain things. Trying to please people by being transparent for the sake of it will take a toll on the team eventually. It's much more effective to just get things done instead of constantly being transparent to the external crowd, about every single detail

Post reply on HN