26 ms·

GitLab Serverless

233 points by sriram_iyengar 8y ago

mr_toad 8y ago
Article does a very good job of burying the lede. tl;dr; GitLab have have a FaaS offering in alpha.
gtirloni 8y ago
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.
- ndnxhs 8y ago
  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.
  - est 8y ago
    everything works great on gitlab, until the moment you had to migrate. Landmine experience in issue lists
    - dsumenkovic 8y ago
      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 https://gitlab.com/gitlab-org/gitlab-ce/issues. Thanks in advance.
      - Aeolun 8y ago
        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).
        sytse 8y ago
        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 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.
        Aeolun 8y ago
        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 images. Cannot see from the docs why that would happen any more though. Maybe it was the opposite, with me restoring the backup to the same block storage devices, and gitlab hiccuping on the fact that all the files it wanted to restore were already there.
        sytse 8y ago
        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.
        twk3 8y ago
        We've opened https://gitlab.com/charts/gitlab/issues/1015 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 https://gitlab.com/charts/gitlab/issues
      - est 8y ago
        Hi, https://gitlab.com/gitlab-org/gitlab-ce/issues/27217 https://gitlab.com/gitlab-org/gitlab-ce/issues/27217 Something like this. When I fixed the VERSION manually, there are other errors, as expected. However the peculiar thing is the errors are not idempotent. Somethings there's some postgres wrong column error, other times it says you can't import the project because you can't have hyphens in project names. (which I don't) Migration is hard, considering everything can be linked in Gitlab.
  - bogomipz 8y ago
    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.
  - dsumenkovic 8y ago
    Thanks for the feedback.
- scrollaway 8y ago
  Their CI system runs actual workloads as well. To be honest I don't understand why they prioritized this but it seems to me like Gitlab has a path to becoming a lot more than what Atlassian is right now; by owning not just the devops but also the cloud itself. It sort of makes sense if that's something they aim for, but it'd be an uphill battle and to be honest I don't see it ever working out. But there's huge rewards there if it does work out. It's kind of the reverse of Amazon tried to do (AWS is trying to compete with Github etc by having their own code hosting and code deploy services, which doesn't ever lead anywhere except for die-hard AWS fans). I'm giving Gitlab the benefit of the doubt on this for one simple reason: I was very doubtful of their current strategy of building in a monsterhouse of features to their product. Then I actually used it and was impressed with how smooth and useful it all is. It also took me actually using it to understand what exactly they were doing. Most people are confused about Gitlab today because they compare it to Github, but Github really only does code hosting and barely even touches development lifecycle; whereas Gitlab is more like Atlassian (and goes beyond that, even). It owns code hosting, product management, development, and deployment. So the "natural next step" in that direction is devops, which they have already been playing with.
  - Already__Taken 8y ago
    > Their CI system runs actual workloads as well Only if you attach k8s right? Or can you leave services deployed with normal CI Jobs that don't end?
jondubois 8y ago
Serverless functions are a terrible idea. Way too restrictive and proprietary. Kubernetes is the future. Amazon throwing money behind the Serverless trend is only delaying the inevitable universal success of a standardized, open source container orchestration platform.
- jively 8y ago
  It’s based on Knative I think, so this is an open source, kubernetes-based alternative tied into GitLab.
- jerluc 8y ago
  I don't understand, half of this announcement refers to the fact that this new feature is built upon Knative: > It leverages Knative, which enables autoscaling down to zero and backup to run serverless workloads on Kubernetes. So what are you referring to?
  - dsumenkovic 8y ago
    Hey, Community Advocate from GitLab here. Sorry for the confusion with the words. We actually meant "back up" which has a bit different context. Fixing that in https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/17295 https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
- rolandboon 8y ago
  Your argument against serverless functions holds for AWS Lambda, but this Gitlab feature is based on Knative. That's an open source serverless platform based on Kubernetes. I think all money Amazon is throwing at serverless is to build a foundation to ultimately transform all their "managed" services into a serverless form. They already released serverless RDS (https://aws.amazon.com/rds/aurora/serverless/ https://aws.amazon.com/rds/aurora/serverless/).
  - jondubois 8y ago
    Good to know that it's open source. I should have looked it up first. My understanding of Serverless was that it was synonymous with 'Functions as a Service'. What Knative seems to be doing is more like 'Backend as a Service'. I guess it's good to know that these two very different approaches are now both labeling themselves as 'Serverless'. I guess Knative is just hitchhiking on top of Amazon's marketing success around the 'Serverless' term.
hardwaresofton 8y ago
I'm a huge Gitlab fan but this seems a little parallel to their core service if not orthogonal... I've been pretty pleased with the feature progress of Gitlab overall though, for example support for merge request-only CI steps just landed[0] I see this as a play to start leveraging all the machines they have hanging around for running jobs and gitlab instances, and I'm not against it as long as the Gitlab itself doesn't suffer. Are they planning to pivot to becoming a cloud provider like digital ocean? It feels like if they can manage orchestrating serverless functions they can manage orchestrating containers or VMs... [0]: https://www.reddit.com/r/gitlab/comments/a54mc3/support_for_mergerequest_only_ci_builds_has_landed/ https://www.reddit.com/r/gitlab/comments/a54mc3/support_for_...
- talkingquickly 8y ago
  Any chance you've got a documentation link for this? My Google foo is failing me and this is a feature I've also wanted for ages!
  - Vinnl 8y ago
    Here: https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html https://docs.gitlab.com/ce/ci/merge_request_pipelines/index....
    - hardwaresofton 8y ago
      Also there's the general `only` section of the `gitlab-ci.yml` documentation: https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplifi... (I have this page favorited)
- tirumaraiselvan 8y ago
  I think they are managing the continuous deployment part of the devops cycle which is traditionally done using webhook.
- Already__Taken 8y ago
  > start leveraging all the machines they have hanging around for running jobs and gitlab instances If anyone ever figures out the isolation problem I'd host an instance and/or ci servers in exchange for licence credit. Unfortunately the current gitlab-runner doesn't run on arm [1] but I wanted ci/cd to make containers for the project, 98% of the time it's idle. 1: https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725 https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/7...
jjm 8y ago
For sometime now GitLab could be made aware of Kubernetes deployments. That is you added the integration of through your build. This allowed you to see your build through to the “deploy” phase. All this new Serverless functionality does is now provide a window to see the Serverless workload rather than just your traditional pods. All brought to you by knative.
PurpleRamen 8y ago
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?
- napo 8y ago
  With serverless you only pay for a request and you (almost) don't care about scaling. While non-serverless implies that you have to manage how many server instances you want, and have them running and pay for them even if you have no traffic.
  - seanwilson 8y ago
    Also, you don't need to worry about server security or server setup outside of the code you're running. With a typical VPS, you'd have to install software updates yourself and have a plan for how to set up a server from scratch again if needed (nontrivial if you do a lot of setup manually over SSH). Essentially, a good way to set something up that requires minimal maintenance.
    - icebraining 8y ago
      They were talking about Webhosting, not VPSs. With webhosting, the hosting company usually manages the software, you just dump your code (or cgi-bin binary) into a directory. For example https://www.hostgator.com/web-hosting https://www.hostgator.com/web-hosting
  - nightfly 8y ago
    Just like old shared webhosting :)
    - icebraining 8y ago
      Most webhosting plans are fixed monthly fees, AFAIK. The only one I knew that billed for used resources was NearlyFreeSpeech.
amelius 8y ago
I didn't read the article but something tells me that "serverless" involves a server of some kind ...
- teekert 8y ago
  From tfa: "...serverless computing is an execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources." The name "serverless" is so unfortunate... On-demand would have been better.
  - pritianka 8y ago
    Hehe, I agree. Sadly, IMO the term has taken over and so we’re stuck with it because of the quick recognition people have to serverless ...
- syntheticcdo 8y ago
  Also "wireless" networking also involves wires of some kind. In terms of wireless networking, I don't care that there are actually wires that connect my router to the internet. It's the same with serverless architectures: I don't care that there are actually servers executing the code, I just don't want to have to think about them.
willhallonline 8y ago
Serverless has been on the roadmap for a little while: https://gitlab.com/groups/gitlab-org/-/epics/155 https://gitlab.com/groups/gitlab-org/-/epics/155 - I saw a demo of using OpenFaaS (https://www.openfaas.com https://www.openfaas.com) as a serverless endpoint for GitLab around 3 months ago. I think that the effort here is to control software, the deployment to Kubernetes is just an additional thing that is tied to the overall software development life cycle. I don't think that GitLab is looking at running against AWS as a cloud provider, but more at being a control plane for managing software. And for that, for me, it is far ahead of the competition.
jonplackett 8y ago
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?
- matteuan 8y ago
  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.
  - jonplackett 8y ago
    Smart! Kinda silly that it's required, but a good and super-cheap solution. Thanks.
- nicoburns 8y ago
  > 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.
  - jonplackett 8y ago
    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!
latchkey 8y ago
Where does Google AppEngine sit in the 'serverless' realm? That one started in 2008 and to me defines the concept of serverless. Auto scaling, support for executing multiple languages, hosted database backend (datastore), infinitely scalable transactional task queue, logging, etc...
bryanlarsen 8y ago
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.
- williamchia 8y ago
  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."
  - bryanlarsen 8y ago
    Jenkins-X adds a bunch of stuff to Jenkins including an artifact repository, a helm chart repository, release management, et cetera. It's pretty cool.
manigandham 8y ago
If you're already deploying stuff on Kubernetes then why this over just packaging up the code into a container and running that? It's also probably using more resources to run the Knative stuff which would offset any scale-to-zero savings. Is there really a big demand for this?
michaelmior 8y ago
> to zero and backup I assume this should be "back up." Otherwise I'm missing what this has to do with backups.
- dsumenkovic 8y ago
  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/17295 https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/.... Thank you for pointing this out and sorry for the confusion.
  - dopeh 8y ago
    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.
  - michaelmior 8y ago
    No problem. Thanks for clarifying :)
- pritianka 8y ago
  Yes, sorry about that! Thanks for fixing, dsumenkovic :-)
Aeolun 8y ago
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 work perfectly.
- matteeyah 8y ago
  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 https://gitlab.com/gitlab-org/gitlab-ce/issues/29398 [2] - https://docs.gitlab.com/ee/user/project/clusters/#adding-an-existing-kubernetes-cluster https://docs.gitlab.com/ee/user/project/clusters/#adding-an-...
  - sytse 8y ago
    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 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.html#introduction https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.h...
- gobengo 8y ago
  > 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 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 https://gitlab.com/charts/gitlab-omnibus So I hope to upgrade to that soon.
buf 8y ago
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
- k__ 8y ago
  - on-demand pricing - no capacity planning - simple programming model There are monitoring/observability tools for serverless (CloudWatch/Epsagon/Thundra/IOPipe)
- tirumaraiselvan 8y ago
  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).
wink 8y ago
I've read the announcement now twice but I can't make out what this is actually good for. I know what they mean with serverless, so that's not it. - is this tied to CI in any way so stuff can get tested via knative? - is this CI for functions to be deployed (via OpenFaaS or Lambda)? - is this just a frontend for serverless backends? I'm totally lost, I use GitLab as a hosted amount of git repos, with inclusion of CI runners, so maybe that's the wrong angle of approach? Which _problem_ does it solve? Is it to make using serverless easier? If I wanted to use 'functions' would I first have to install GitLab? Why would I use a code hosting platform for that?
- willhallonline 8y ago
  Overall, this is trying to give more support for pushing functions to Kubernetes using Knative as the method. I believe that there will be some support built in to GitLab for supporting Knative functions. I also know that this already works with OpenFaaS and OpenFaaS cloud, whereas Lambda normally is not deployed directly to Kubernetes, although you can use GitLab CI to do this.
  - wink 8y ago
    Thank you, that makes it a bit clearer.

Article does a very good job of burying the lede. tl;dr; GitLab have have a FaaS offering in alpha.

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.

ndnxhs 8y ago
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.
- est 8y ago
  everything works great on gitlab, until the moment you had to migrate. Landmine experience in issue lists
  - dsumenkovic 8y ago
    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 https://gitlab.com/gitlab-org/gitlab-ce/issues. Thanks in advance.
    - Aeolun 8y ago
      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).
      - sytse 8y ago
        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 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.
        Aeolun 8y ago
        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 images. Cannot see from the docs why that would happen any more though. Maybe it was the opposite, with me restoring the backup to the same block storage devices, and gitlab hiccuping on the fact that all the files it wanted to restore were already there.
        sytse 8y ago
        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.
        twk3 8y ago
        We've opened https://gitlab.com/charts/gitlab/issues/1015 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 https://gitlab.com/charts/gitlab/issues
    - est 8y ago
      Hi, https://gitlab.com/gitlab-org/gitlab-ce/issues/27217 https://gitlab.com/gitlab-org/gitlab-ce/issues/27217 Something like this. When I fixed the VERSION manually, there are other errors, as expected. However the peculiar thing is the errors are not idempotent. Somethings there's some postgres wrong column error, other times it says you can't import the project because you can't have hyphens in project names. (which I don't) Migration is hard, considering everything can be linked in Gitlab.
- bogomipz 8y ago
  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.
- dsumenkovic 8y ago
  Thanks for the feedback.
scrollaway 8y ago
Their CI system runs actual workloads as well. To be honest I don't understand why they prioritized this but it seems to me like Gitlab has a path to becoming a lot more than what Atlassian is right now; by owning not just the devops but also the cloud itself. It sort of makes sense if that's something they aim for, but it'd be an uphill battle and to be honest I don't see it ever working out. But there's huge rewards there if it does work out. It's kind of the reverse of Amazon tried to do (AWS is trying to compete with Github etc by having their own code hosting and code deploy services, which doesn't ever lead anywhere except for die-hard AWS fans). I'm giving Gitlab the benefit of the doubt on this for one simple reason: I was very doubtful of their current strategy of building in a monsterhouse of features to their product. Then I actually used it and was impressed with how smooth and useful it all is. It also took me actually using it to understand what exactly they were doing. Most people are confused about Gitlab today because they compare it to Github, but Github really only does code hosting and barely even touches development lifecycle; whereas Gitlab is more like Atlassian (and goes beyond that, even). It owns code hosting, product management, development, and deployment. So the "natural next step" in that direction is devops, which they have already been playing with.
- Already__Taken 8y ago
  > Their CI system runs actual workloads as well Only if you attach k8s right? Or can you leave services deployed with normal CI Jobs that don't end?

jondubois 8y ago

Serverless functions are a terrible idea. Way too restrictive and proprietary. Kubernetes is the future. Amazon throwing money behind the Serverless trend is only delaying the inevitable universal success of a standardized, open source container orchestration platform.

jively 8y ago
It’s based on Knative I think, so this is an open source, kubernetes-based alternative tied into GitLab.
jerluc 8y ago
I don't understand, half of this announcement refers to the fact that this new feature is built upon Knative: > It leverages Knative, which enables autoscaling down to zero and backup to run serverless workloads on Kubernetes. So what are you referring to?
- dsumenkovic 8y ago
  Hey, Community Advocate from GitLab here. Sorry for the confusion with the words. We actually meant "back up" which has a bit different context. Fixing that in https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/17295 https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
rolandboon 8y ago
Your argument against serverless functions holds for AWS Lambda, but this Gitlab feature is based on Knative. That's an open source serverless platform based on Kubernetes. I think all money Amazon is throwing at serverless is to build a foundation to ultimately transform all their "managed" services into a serverless form. They already released serverless RDS (https://aws.amazon.com/rds/aurora/serverless/ https://aws.amazon.com/rds/aurora/serverless/).
- jondubois 8y ago
  Good to know that it's open source. I should have looked it up first. My understanding of Serverless was that it was synonymous with 'Functions as a Service'. What Knative seems to be doing is more like 'Backend as a Service'. I guess it's good to know that these two very different approaches are now both labeling themselves as 'Serverless'. I guess Knative is just hitchhiking on top of Amazon's marketing success around the 'Serverless' term.

hardwaresofton 8y ago

I'm a huge Gitlab fan but this seems a little parallel to their core service if not orthogonal... I've been pretty pleased with the feature progress of Gitlab overall though, for example support for merge request-only CI steps just landed[0] I see this as a play to start leveraging all the machines they have hanging around for running jobs and gitlab instances, and I'm not against it as long as the Gitlab itself doesn't suffer. Are they planning to pivot to becoming a cloud provider like digital ocean? It feels like if they can manage orchestrating serverless functions they can manage orchestrating containers or VMs... [0]: https://www.reddit.com/r/gitlab/comments/a54mc3/support_for_mergerequest_only_ci_builds_has_landed/ https://www.reddit.com/r/gitlab/comments/a54mc3/support_for_...

talkingquickly 8y ago
Any chance you've got a documentation link for this? My Google foo is failing me and this is a feature I've also wanted for ages!
- Vinnl 8y ago
  Here: https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html https://docs.gitlab.com/ce/ci/merge_request_pipelines/index....
  - hardwaresofton 8y ago
    Also there's the general `only` section of the `gitlab-ci.yml` documentation: https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplifi... (I have this page favorited)
tirumaraiselvan 8y ago
I think they are managing the continuous deployment part of the devops cycle which is traditionally done using webhook.
Already__Taken 8y ago
> start leveraging all the machines they have hanging around for running jobs and gitlab instances If anyone ever figures out the isolation problem I'd host an instance and/or ci servers in exchange for licence credit. Unfortunately the current gitlab-runner doesn't run on arm [1] but I wanted ci/cd to make containers for the project, 98% of the time it's idle. 1: https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725 https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/7...

jjm 8y ago

For sometime now GitLab could be made aware of Kubernetes deployments. That is you added the integration of through your build. This allowed you to see your build through to the “deploy” phase. All this new Serverless functionality does is now provide a window to see the Serverless workload rather than just your traditional pods. All brought to you by knative.

PurpleRamen 8y ago

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?

napo 8y ago
With serverless you only pay for a request and you (almost) don't care about scaling. While non-serverless implies that you have to manage how many server instances you want, and have them running and pay for them even if you have no traffic.
- seanwilson 8y ago
  Also, you don't need to worry about server security or server setup outside of the code you're running. With a typical VPS, you'd have to install software updates yourself and have a plan for how to set up a server from scratch again if needed (nontrivial if you do a lot of setup manually over SSH). Essentially, a good way to set something up that requires minimal maintenance.
  - icebraining 8y ago
    They were talking about Webhosting, not VPSs. With webhosting, the hosting company usually manages the software, you just dump your code (or cgi-bin binary) into a directory. For example https://www.hostgator.com/web-hosting https://www.hostgator.com/web-hosting
- nightfly 8y ago
  Just like old shared webhosting :)
  - icebraining 8y ago
    Most webhosting plans are fixed monthly fees, AFAIK. The only one I knew that billed for used resources was NearlyFreeSpeech.

amelius 8y ago

I didn't read the article but something tells me that "serverless" involves a server of some kind ...

teekert 8y ago
From tfa: "...serverless computing is an execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources." The name "serverless" is so unfortunate... On-demand would have been better.
- pritianka 8y ago
  Hehe, I agree. Sadly, IMO the term has taken over and so we’re stuck with it because of the quick recognition people have to serverless ...
syntheticcdo 8y ago
Also "wireless" networking also involves wires of some kind. In terms of wireless networking, I don't care that there are actually wires that connect my router to the internet. It's the same with serverless architectures: I don't care that there are actually servers executing the code, I just don't want to have to think about them.

willhallonline 8y ago

Serverless has been on the roadmap for a little while: https://gitlab.com/groups/gitlab-org/-/epics/155 https://gitlab.com/groups/gitlab-org/-/epics/155 - I saw a demo of using OpenFaaS (https://www.openfaas.com https://www.openfaas.com) as a serverless endpoint for GitLab around 3 months ago. I think that the effort here is to control software, the deployment to Kubernetes is just an additional thing that is tied to the overall software development life cycle. I don't think that GitLab is looking at running against AWS as a cloud provider, but more at being a control plane for managing software. And for that, for me, it is far ahead of the competition.

jonplackett 8y ago

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?

matteuan 8y ago
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.
- jonplackett 8y ago
  Smart! Kinda silly that it's required, but a good and super-cheap solution. Thanks.
nicoburns 8y ago
> 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.
- jonplackett 8y ago
  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!

latchkey 8y ago

Where does Google AppEngine sit in the 'serverless' realm? That one started in 2008 and to me defines the concept of serverless. Auto scaling, support for executing multiple languages, hosted database backend (datastore), infinitely scalable transactional task queue, logging, etc...

bryanlarsen 8y ago

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.

williamchia 8y ago
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."
- bryanlarsen 8y ago
  Jenkins-X adds a bunch of stuff to Jenkins including an artifact repository, a helm chart repository, release management, et cetera. It's pretty cool.

manigandham 8y ago

If you're already deploying stuff on Kubernetes then why this over just packaging up the code into a container and running that? It's also probably using more resources to run the Knative stuff which would offset any scale-to-zero savings. Is there really a big demand for this?

michaelmior 8y ago

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

dsumenkovic 8y ago
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/17295 https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/.... Thank you for pointing this out and sorry for the confusion.
- dopeh 8y ago
  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.
- michaelmior 8y ago
  No problem. Thanks for clarifying :)
pritianka 8y ago
Yes, sorry about that! Thanks for fixing, dsumenkovic :-)

Aeolun 8y ago

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 work perfectly.

matteeyah 8y ago
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 https://gitlab.com/gitlab-org/gitlab-ce/issues/29398 [2] - https://docs.gitlab.com/ee/user/project/clusters/#adding-an-existing-kubernetes-cluster https://docs.gitlab.com/ee/user/project/clusters/#adding-an-...
- sytse 8y ago
  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 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.html#introduction https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.h...
gobengo 8y ago
> 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 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 https://gitlab.com/charts/gitlab-omnibus So I hope to upgrade to that soon.

buf 8y ago

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

k__ 8y ago
- on-demand pricing - no capacity planning - simple programming model There are monitoring/observability tools for serverless (CloudWatch/Epsagon/Thundra/IOPipe)
tirumaraiselvan 8y ago
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).

wink 8y ago

I've read the announcement now twice but I can't make out what this is actually good for. I know what they mean with serverless, so that's not it. - is this tied to CI in any way so stuff can get tested via knative? - is this CI for functions to be deployed (via OpenFaaS or Lambda)? - is this just a frontend for serverless backends? I'm totally lost, I use GitLab as a hosted amount of git repos, with inclusion of CI runners, so maybe that's the wrong angle of approach? Which _problem_ does it solve? Is it to make using serverless easier? If I wanted to use 'functions' would I first have to install GitLab? Why would I use a code hosting platform for that?

willhallonline 8y ago
Overall, this is trying to give more support for pushing functions to Kubernetes using Knative as the method. I believe that there will be some support built in to GitLab for supporting Knative functions. I also know that this already works with OpenFaaS and OpenFaaS cloud, whereas Lambda normally is not deployed directly to Kubernetes, although you can use GitLab CI to do this.
- wink 8y ago
  Thank you, that makes it a bit clearer.