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

121–126 of 126 posts

Re: GitLab Serverless

#121

Post by sytse »

Aeolun wrote: post #108
sytse wrote: post #91

Earlier quoted context omitted.

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.

Thanks for the response. 1. Gitlab is able to migrate up to a new version, so is there anything preventing it from getting up to a certain (older) version before running the last few migrations after restore? If I set up a new instance it’s generally one or two minor versions higher than the old instance. 2. I swear I restored from my omnibus installation to Helm based gitlab and lose all my uploads and registry imag…

1. I'm not sure and will ask.

2. It might be that this wasn't supported yet in the Helm chart at that time, I'm not sure.

Re: GitLab Serverless

#122

Post by jeremylikness »

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?

Serverless is identical in every respect to traditional hosting/managed services with one exception: micro-billing. In web hosting you are often either constrained by the "level" you pay for, or have to configure scale and pay for the size of your domain. True serverless should auto-scale on demand without your intervention, and it should only bill you for what you use. Have a slow month and are idle? Pennies. Have a phenomenal month and huge usage? Dollars. There is less server, not no server, but instead of worrying about the OS or even platform level dependencies, you can focus just on the bit of code you want to run. If your server is a house and a virtual machine is like renting a house, platform-as-a-service is an apartment and serverless is a hotel (thanks to Scott Hanselman for that analogy).

Re: GitLab Serverless

#123

Post by twk3 »

Aeolun wrote: post #108
sytse wrote: post #91

Earlier quoted context omitted.

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.

Thanks for the response. 1. Gitlab is able to migrate up to a new version, so is there anything preventing it from getting up to a certain (older) version before running the last few migrations after restore? If I set up a new instance it’s generally one or two minor versions higher than the old instance. 2. I swear I restored from my omnibus installation to Helm based gitlab and lose all my uploads and registry imag…

We've opened https://gitlab.com/charts/gitlab/issues/1015 to discuss this comment. I don't believe the db migrations are what are holding us back, as much as the other parts of the backup/restore.

For number 2, that sounds unexpected, and we would love for you to give us more details. https://gitlab.com/charts/gitlab/issues

Re: GitLab Serverless

#124

Post by tracker1 »

y4mi wrote: post #120
tracker1 wrote: post #105

Earlier quoted context omitted.

I would dissent from #3 in that containers also have the inherent advantage of being able to scale and start quickly. A full VM takes time to boot and run through whatever setup/initialization needs to happen at the OS level, where a container just needs to copy/deploy and start. In many cases it's an additional abstraction, but there are advantages beyond just better hardware utilization.

An optimized vm boots in Heck, a hardware server can boot in seconds if you skip POST entirely

My experience with Azure and AWS is that it takes quite a bit longer than 2 seconds before a new server is up.

Re: GitLab Serverless

#125

Post by headcanon »

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 add to the other comments, using serverless with AWS Lambda has been very useful for us in our data pipeline, in a large part because you can hook them up to respond to a number of events like S3 uploads, updates to dynamo tables, or to an SNS or message queue topic. It scales up effortlessly and is very cheap to run. Could we have done this by avoiding serverless? sure but we would have to maintain quite a bit more infrastructure - why do that when someone else can handle that infrastructure cheaply? I realize my example is provider-specific but I think having them act as asynchronous data transforms and workflows are where the serverless really shines, especially given the invocation overhead of 20-30ms or so when hot, and several seconds when cold.

We have run into instances where the serverless model doesn't work so well, like when we updated our graphql API to query a postgres store - each lambda invocation created its own connection pool and would overload the database. Currently theres no way to reliably persist those somewhere else and have the lambdas pick up the persistent connection (like how a redis session store would work) - perhaps that will change. the lambdas work best when they're more-or-less "pure functions", so if you have to keep things like sql connection pools, or a session around, you still need your own persistent server.

Re: GitLab Serverless

#126

Post by ric2b »

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…

So the main advantage is that it scales easily, but then it's only cheaper if you actually don't need it to scale?
Post reply on HN