Live data from Hacker News

GitLab Serverless

about.gitlab.com

81–90 of 126 posts

Re: GitLab Serverless

#81
post #6

Earlier quoted context omitted.

everything works great on gitlab, until the moment you had to migrate. Landmine experience in issue lists

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).

Re: GitLab Serverless

#82

Correct me if I'm wrong, but this is very different from Jenkins-X serverless. Jenkins-X serverless: Jenkins only runs when it has work to do and shuts down while idle. Gitlab serverless: tooling to support FaaS creation Serverless is such a silly word to begin with, now it's even more confusing.

Yes, you've touched on a key difference between Jenkins and GitLab in general:

Jenkins: only does CI/CD, needs to be integrated with a suite of other tools.

GitLab: end-to-end DevOps in one application that has native project planning, source code management, CI/CD, artifact repository, configuration management, and observability built-in.

So Jenkins-X Serverless is about the Jenkins service itself running in a serverless paradigm. Or "using Knative to run Jenkins"

GitLab Serverless is a configuration management feature that allows you to build, deploy, and manage your own serverless functions from the same place where your issues, code, artifacts, etc. are. Or "Using GitLab (which uses Knative) to run your functions."

Re: GitLab Serverless

#83

> to zero and backup I assume this should be "back up." Otherwise I'm missing what this has to do with backups.

Good catch Michael, that's right. We meant the "back up" and we are fixing this typo https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... . Thank you for pointing this out and sorry for the confusion.

It's quite fascinating to follow your link and see the amount of "work" required to fix a simple typo. The fix consists of 1 commit with a change of 1 character. It then takes 1 merge request, 1 pipeline, 13 jobs and a grand total of 23 minutes and 41 seconds to process this change and deploy it.

Since one of the big pros of serverless computing is only paying for the resources that you use, I am wondering if we will hit a point where preparing a trivial release is not worth the effort because it's simply too expensive. Paying 23 minutes of cloud computing for a simple typo adds up easily.

Re: GitLab Serverless

#84

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…

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 be for-filed, increasing this limit is entirely at Amazons discretion, and wont they necessarily do it. I stand corrected, see comment.

https://docs.aws.amazon.com/lambda/latest/dg/limits.html

In your case 3m reqs/min will be fine if each request can be completed in no more than 20 milliseconds, and then you'll be on the knife edge.

If you wanted to reap the benefits of Lambda on the development side, loose the limits and keep server costs low(er) you could deploy OpenFaaS or similar in ECS. However you then loose the operational benefits of a managed solution.

Re: GitLab Serverless

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

Support for RBAC for GitLab Managed Apps was added in 11.4 [1]. You can also connect any Kubernetes cluster hosted anywhere - see the docs on that [2].

What problems are you hitting when installing GitLab on Kubernetes? You can always open an issue about it so it can be prioritized for fixing.

[1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/29398

[2] - https://docs.gitlab.com/ee/user/project/clusters/#adding-an-...

Re: GitLab Serverless

#86

> to zero and backup I assume this should be "back up." Otherwise I'm missing what this has to do with backups.

Good catch Michael, that's right. We meant the "back up" and we are fixing this typo https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... . Thank you for pointing this out and sorry for the confusion.

No problem. Thanks for clarifying :)

Re: GitLab Serverless

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

Support for RBAC for GitLab Managed Apps was added in 11.4 [1]. You can also connect any Kubernetes cluster hosted anywhere - see the docs on that [2]. What problems are you hitting when installing GitLab on Kubernetes? You can always open an issue about it so it can be prioritized for fixing. [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/29398 [2] - https://docs.gitlab.com/ee/user/project/clusters/#adding-an-…

Please also note that you don't have to install GitLab itself on Kubernetes in order to add a Kubernetes cluster to your projects or groups. We updated the docs yesterday to prevent confusion about this https://gitlab.com/charts/gitlab/merge_requests/599/diffs

We had multiple ways of installing on Kubernetes before but we reduced it to one canonical helm chart https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.h...

Re: GitLab Serverless

#88
post #47

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…

Is Heroku considered Serverless? Or is it still more like Digital Ocean (which I consider to be more like #2)?

Re: GitLab Serverless

#89
post #47

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…

it's a 'pay Amazon forever' layer above all else

Re: GitLab Serverless

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

Is Heroku considered Serverless? Or is it still more like Digital Ocean (which I consider to be more like #2)?

Heroku is more like containers in this list. Your app is packaged up, runs on as many machines as needed, but you pay while it is running even if idle.

As soon as the idle state is abstracted away, then it's serverless.

Post reply on HN