Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab Serverless

about.gitlab.com

Post reply on HN
Print view View original

61–70 of 126 posts

Re: GitLab Serverless

#61

Post by bogomipz »

ndnxhs wrote: post #5
gtirloni wrote: post #3

This seems to be the first product to run actual workloads on instead of out-of-band management? I'm a bit lost when it comes to GitLab because they are trying to do so much, so I'm confused if this is a change in strategy or natural next step for them. Edit: Clarifying question.

I don't think they are trying to do more than they can handle. Every feature I have used on gitlab has worked amazing so it doesn't seem like they are spread thin.

I don't agree. A lot of features seem half-baked. The public Gitlab issues are filled with features that don't seem to work or are poorly understood because of their spare or incomplete documentation. These issues often just languish until the gitlab bot closes them for inactivity. However the only inactivity for many of these is just Gitlab's failure to respond.

Re: GitLab Serverless

#62

Post by ddorian43 »

mickael-kerjean wrote: post #56
ddorian43 wrote: post #42

Earlier quoted context omitted.

But it's so much cheaper bud (it's not). It maybe is only when you're doing <= $10/month.

I don't know if it's the HN effect but I never had a scaling problem. Prior acquisition the story says whatsapp used to run on a single server

It depends on the type of application. But when at 5pm your traffic grows by 200x (hint: it doesn't) and you petascale your aws vps megafleet (hint: you don't, especially your database you don't) then you are on route to unicorn-scale hypergrouth cash-money-team-happiness.

Re: GitLab Serverless

#63

Post by y4mi »

rkangel wrote: post #47
PurpleRamen wrote: post #14

Can someone explain me what that hype about serverless is? As I understand it, serverless is just good old webhosting, but in the cloud. With webhosting I mean providers offering a LAMP-environment and customer just upload their code and don't manage anything else. Is this correct? Then how is serverless different to this?

To me, it's about the abstraction layer that you interact with when bringing up your stack. That abstraction layer has gradually moved higher over time as providers try and deliver more for their customers: 1) Hardware) 'I want to run Linux + Stack + App'. You get an empty rack, a network port and a power socket. You have to buy iron, install and maintain OS/platform, runtime environment and your service. Scaling req…

let me guess, you don't have any experience in ops?

1) Scaling doesn't really require more work. It needs a bigger investment because a hardware hypervisor costs significantly more than a vm... after all, that hard metal can host tens of VMs

2) you still need to manage your linux system and OS if you're buying a VM... the only thing you don't need to worry about is hardware. So, a faulty hard drive, hypervisor failover and similar stuff is taken care of. That doesn't mean that it works, however. It just means that somebody else will take care of it... though it might not work and you're entirely on their mercy to fix it

3) containers don't inherently give you better scaling either. creating images from VMs has been done for ages before docker was a thing, and provisioning a new Node from a VM Image is pretty easy if you're already using Terraform or similar.

you're just able to utilize a higher percentage of your hardware with containers, as you don't need to virtualize the kernel... so its a cost-cutting issue, not scaling

Re: GitLab Serverless

#64

Post by 0x445442 »

jackpeterfletch wrote: post #44
titanix2 wrote: post #31

Earlier quoted context omitted.

I feel the whole "not paying for underused server" argument is pointless when a serverless solution is way more expensive than paying for an idle server.

It isnt more expensive! Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. Not only would it cost more but you'd probably hit the concurrency limit in AWS Lambda. But we also have an admin UI that gets about 2500 visits a day. We're running that for about $4 a month - with virtually no operational burden whatsoever, and with a reassurance of resilience. We worked ou…

>> Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete.

I'm curious about this statement because I'm currently working on a project where the intent is to port a legacy app to AWS Lambda. The legacy app is currently distributed across 96 VMs and handles ~ 50K reqs/min during normal times but can run into ~ 3M reqs/min during high demand.

Are you saying AWS Lambda can not scale to handle this type of demand and if so can you point me to some resources/references that explain this?

For the record, I'm not the one that came up with the architecture.

Re: GitLab Serverless

#65

Post by nicoburns »

jonplackett wrote: post #30

Is this addressing any of the cold start problems? One of the things that attracts me to Serverless is not paying anything (or vey little) until a project is properly off the ground. But with things like Heroku there’s a ridiculous delay to start up if here hasn’t been a request for a while. Does Serverless / this implementation of Serverless address that at all?

> One of the things that attracts me to Serverless is not paying anything (or vey little) until a project is properly off the ground.

I guess it's not quite nothing, but can't you just buy a cheap $5 (or even $2.50) VM, and run all of your small projects off of the same one.

The cost is pretty small, and you don't have to worry about how your going to migrate your code off the serverless platform later.

Re: GitLab Serverless

#66

Post by prepend »

PurpleRamen wrote: post #14

Can someone explain me what that hype about serverless is? As I understand it, serverless is just good old webhosting, but in the cloud. With webhosting I mean providers offering a LAMP-environment and customer just upload their code and don't manage anything else. Is this correct? Then how is serverless different to this?

It’s kind of similar, but imagine php without the ability to break anybody else on the web host and infinite resources as much as you wish to pay. So no server migrations. No debugging performance problems.

So it is just the natural progression of a shared LAMP host that’s worked well for 20 years.

Re: GitLab Serverless

#67

Post by prepend »

y4mi wrote: post #63
rkangel wrote: post #47

Earlier quoted context omitted.

To me, it's about the abstraction layer that you interact with when bringing up your stack. That abstraction layer has gradually moved higher over time as providers try and deliver more for their customers: 1) Hardware) 'I want to run Linux + Stack + App'. You get an empty rack, a network port and a power socket. You have to buy iron, install and maintain OS/platform, runtime environment and your service. Scaling req…

let me guess, you don't have any experience in ops? 1) Scaling doesn't really require more work. It needs a bigger investment because a hardware hypervisor costs significantly more than a vm... after all, that hard metal can host tens of VMs 2) you still need to manage your linux system and OS if you're buying a VM... the only thing you don't need to worry about is hardware. So, a faulty hard drive, hypervisor failov…

“let me guess, you don't have any experience in ops?”

This is precisely the benefit. It lets you not require as much ops experience to get the same output as what once required a lot.

This is pretty neat because now more teams can do more stuff since lots of orgs don’t have good ops or can’t pay.

Re: GitLab Serverless

#68

Post by imhoguy »

antocv wrote: post #18
PurpleRamen wrote: post #14

Can someone explain me what that hype about serverless is? As I understand it, serverless is just good old webhosting, but in the cloud. With webhosting I mean providers offering a LAMP-environment and customer just upload their code and don't manage anything else. Is this correct? Then how is serverless different to this?

People abuse the term serverless, yes to mean "cloud" or "somebody else server" and "just write the function you want we will find a server to run it on and report to you the result". The term I like to associate with serverless is all peer-to-peer, not client-server architecture, for example any datwebsite, on datproject, and any zsite on zeronet. There you dont have a server, really, a zite is a peer in a torrent s…

That is very interesting topic. If you were able to add secure computation with some kind of homomorphic encryption [0] it could be possible to get rid of centralized compute vendors. The only issue is the performance of such computations which are still cheaper to run unencrypted in a trusted env.

[0] https://en.wikipedia.org/wiki/Homomorphic_encryption

Re: GitLab Serverless

#70

Post by mcrittenden »

0x445442 wrote: post #64
jackpeterfletch wrote: post #44

Earlier quoted context omitted.

It isnt more expensive! Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. Not only would it cost more but you'd probably hit the concurrency limit in AWS Lambda. But we also have an admin UI that gets about 2500 visits a day. We're running that for about $4 a month - with virtually no operational burden whatsoever, and with a reassurance of resilience. We worked ou…

>> Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. I'm curious about this statement because I'm currently working on a project where the intent is to port a legacy app to AWS Lambda. The legacy app is currently distributed across 96 VMs and handles ~ 50K reqs/min during normal times but can run into ~ 3M reqs/min during high demand. Are you saying AWS Lambda can…

I think he/she meant that Lambda wouldn't compete on pricing (as opposed to on performance).
Post reply on HN