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_...
Serverless has been on the roadmap for a little while: https://gitlab.com/groups/gitlab-org/-/epics/155 - I saw a demo of using OpenFaaS (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.
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?
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.
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.
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...
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.
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.
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
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?
> to zero and backup
I assume this should be "back up." Otherwise I'm missing what this has to do with backups.
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?
I didn't read the article but something tells me that "serverless" involves a server of some kind ...
Article does a very good job of burying the lede.
tl;dr; GitLab have have a FaaS offering in alpha.
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.
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?