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

91–100 of 126 posts

Re: GitLab Serverless

#91

Post by sytse »

Aeolun wrote: post #81
dsumenkovic wrote: post #77

Earlier quoted context omitted.

Hi, Community Advocate from GitLab here. Could you please reference what issues you are experiencing? We'd love to follow up on it. Also, if you want to write the details, it would be great to open an issue https://gitlab.com/gitlab-org/gitlab-ce/issues . Thanks in advance.

One, having to come from the same version. Two, having to connect to the same block storage in exactly the same way to make everything work. I just want to upload a backup that gitlab makes, and upload that somewhere (anywhere) to restore from that one tarball, regardless of where I’ve decided to host my current instance or data (or indeed, if I’ve decided to use block storage again or not).

Thanks for the feedback.

1. Yes, you have to restore a backup on exactly the same version of GitLab and then upgrade that version. If you restore it to a different version the database scheme isn't correct.

2. You can restore a GitLab backup anywhere https://docs.gitlab.com/ee/raketasks/backup_restore.html as long as it is the same version. I think the output is a single file.

Re: GitLab Serverless

#92

Post by buf »

Is the only difference between Heroku and Serverless is that I pay for Heroku while the app is idle and that I have great debugging tools on heroku?

Please help me understand why I would choose Serverless over heroku

Re: GitLab Serverless

#93

Post by k__ »

buf wrote: post #92

Is the only difference between Heroku and Serverless is that I pay for Heroku while the app is idle and that I have great debugging tools on heroku? Please help me understand why I would choose Serverless over heroku

- on-demand pricing

- no capacity planning

- simple programming model

There are monitoring/observability tools for serverless (CloudWatch/Epsagon/Thundra/IOPipe)

Re: GitLab Serverless

#94

Post by tirumaraiselvan »

buf wrote: post #92

Is the only difference between Heroku and Serverless is that I pay for Heroku while the app is idle and that I have great debugging tools on heroku? Please help me understand why I would choose Serverless over heroku

Yes. The only difference is the unit economics. You pay per request in serverless whereas you pay "constant" amount in Heroku. Don't think it should be too hard for heroku to introduce price per request plans since they already have the infra for it (ala sleeping/waking dynos in free tier).

Re: GitLab Serverless

#95

Post by mjb »

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

Earlier quoted context omitted.

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

mcrittenden is right in that it probably will cost more to run than just having the old processes run on ECS/EC2. Lambda charges a premium for maintaining its control plane and development of the product that only makes sense to pay if your app has 'idle time'. But also there is a per account per region concurrency limit of 1000 parallel executions. That's shared across all lambdas. If you hit it, requests will not b…

The 1000 concurrency is a default limit, and we're very happy to raise it if you need more. The instructions for a limit increase request are here: https://docs.aws.amazon.com/lambda/latest/dg/concurrent-exec...

(Source: I work on Lambda at AWS)

Re: GitLab Serverless

#96

Post by jackpeterfletch »

mjb wrote: post #95
jackpeterfletch wrote: post #84

Earlier quoted context omitted.

mcrittenden is right in that it probably will cost more to run than just having the old processes run on ECS/EC2. Lambda charges a premium for maintaining its control plane and development of the product that only makes sense to pay if your app has 'idle time'. But also there is a per account per region concurrency limit of 1000 parallel executions. That's shared across all lambdas. If you hit it, requests will not b…

The 1000 concurrency is a default limit, and we're very happy to raise it if you need more. The instructions for a limit increase request are here: https://docs.aws.amazon.com/lambda/latest/dg/concurrent-exec... (Source: I work on Lambda at AWS)

Fair play - added a correction, that statement came from discussions with our DevOps facility rather than first hand contact with Amazon, so there could be something else going on.

Re: GitLab Serverless

#97

Post by franga2000 »

bufferoverflow wrote: post #38
Cthulhu_ wrote: post #25

Earlier quoted context omitted.

With the difference that you pay per request instead of per month / year. Mind you, given how cheap LAMP webhosts can be, I'm fairly sure they would be cheaper if you don't need the autoscaling.

Seriously, VPS hosts are so far ahead of the cloud when it comes to cost/resource ratio. I can get a 4-core 4GB 120GB SHDD instance for ~$2/month. https://lowendbox.com/blog/hostedsimply-4gb-ram-ssd-cached-v... EDIT: cheaper even, $1.58/month: https://lowendbox.com/blog/n3servers-vps-hosting-and-hybrid-...

Low-cost VPSs are great, but their uptime is usually garbage. I myself run almost everything on a 9€/mo Contabo box (6c, 16GB) and while it's nice and powerful, it gets randomly rebooted way more often than acceptable (and I've heard similar about other hosts). For the "I'll get an angry phone call if the app is down for half an hour at 4 am" category of projects, the cost of a reliable enough VPS comes very close to the equivalent in the cloud, where you also get the benefit of pointing a finger at your provider if something goes wrong.

Re: GitLab Serverless

#98

Post by gobengo »

Aeolun wrote: post #79

I would appreciate it if they first focused on getting their Kubernetes integration working with anything other than Google cloud. Or maybe add support for RBAC, or a variety of other things that make some of these amazing features like auto devops workable for the common man without having to spend weeks setting it up. If I try to install gitlab on Kubernetes I have no less than 4 ways to do it, and none of them wor…

> If I try to install gitlab on Kubernetes I have no less than 4 ways to do it, and none of them work perfectly.

Yes. Until a couple months ago the 'official' way was a deprecated (but not yet replaced with anything not marked alpha) chart: https://gitlab.com/charts/gitlab-omnibus

FWIW, I use that to run GitLab on Kubernetes on AWS (not EKS).

Though the new 'container-native' (more separate containers for each service instead of one big omnibus container for the web app + git server + else) one is now out and 'official': https://gitlab.com/charts/gitlab-omnibus

So I hope to upgrade to that soon.

Re: GitLab Serverless

#99

Post by jonplackett »

matteuan wrote: post #58
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?

I can confirm AWS Lambda still has this problem. A dirty solution could be to time-trigger your function every x seconds to keep the container alive. For example, doing that every 10 seconds would produce 259200 request per 30-days month, so 0,05 USD per month for this in AWS.

Smart!

Kinda silly that it's required, but a good and super-cheap solution. Thanks.

Re: GitLab Serverless

#100

Post by jonplackett »

nicoburns wrote: post #65
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.

Yeah that's basically what I do now. Amazon's Lightsail is really good for this.

What I'd really like though is one place I can just put the code, test it and know I can leave it there when it gets bigger. That's the dream anyway, but I guess nothing's perfect!

Post reply on HN