
GitLab Serverless - sriram_iyengar
https://about.gitlab.com/2018/12/11/introducing-gitlab-serverless/
======
PurpleRamen
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?

~~~
rkangel
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 requires more work
and buying more stuff.

2) VMs) 'I want to run Stack + App'. Machine and OS is provided for you and
maintained. You still have to build runtime environment and your app. Scaling
doesn't require capex like (1), but still slow - you have to decide how much
capacity you want.

3) Containers) Still 'I want to run Stack + App' but faster scaling so can be
responsive rather than in advance. A halfway step to:

4) Serverless) 'I want to run App'. Runtime environment, hosting etc is all
taken care of. You just write the app and everything else works at the
capacity you need.

We've been aiming at this last level of abstraction for a while. As you
pointed out, the classic VPS with LAMP got you some of the way there, but
without the scaling advantages. Google App Engine got closer but was its own
special world. Containers are an important technical enabler to doing it more
portably.

~~~
y4mi
let me guess, you don't have any experience in ops?

1) Scaling doesn't really require more work. It needs a bigger investment
because a hardware hypervisor costs significantly more than a vm... after all,
that hard metal can host tens of VMs

2) you still need to manage your linux system and OS if you're buying a VM...
the only thing you don't need to worry about is hardware. So, a faulty hard
drive, hypervisor failover and similar stuff is taken care of. That doesn't
mean that it works, however. It just means that somebody else will take care
of it... though it might not work and you're entirely on their mercy to fix it

3) containers don't inherently give you better scaling either. creating images
from VMs has been done for ages before docker was a thing, and provisioning a
new Node from a VM Image is pretty easy if you're already using Terraform or
similar.

you're just able to utilize a higher percentage of your hardware with
containers, as you don't need to virtualize the kernel... so its a cost-
cutting issue, not scaling

~~~
tracker1
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.

~~~
y4mi
An optimized vm boots in < 2 seconds...

Heck, a hardware server can boot in seconds if you skip POST entirely

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

------
hardwaresofton
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_...](https://www.reddit.com/r/gitlab/comments/a54mc3/support_for_mergerequest_only_ci_builds_has_landed/)

~~~
Already__Taken
> 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/7...](https://gitlab.com/gitlab-org/gitlab-
runner/merge_requests/725)

~~~
hardwaresofton
I'm actually working on a system to do exactly this I wanted to sell dedicated
1C 2GB RAM runners for $8/month (which is less than a t2.micro), maybe I
should architect it so people can contribute runners and make it a
marketplace...

Would love to hear some feedback if anyone has some.

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

------
wink
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
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
Thank you, that makes it a bit clearer.

------
Aeolun
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
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-...](https://docs.gitlab.com/ee/user/project/clusters/#adding-an-existing-
kubernetes-cluster)

~~~
sytse
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.h...](https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html#introduction)

------
gtirloni
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
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
everything works great on gitlab, until the moment you had to migrate.

Landmine experience in issue lists

~~~
dsumenkovic
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
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
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
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.

~~~
twk3
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)

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

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

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

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

~~~
k__
\- on-demand pricing

\- no capacity planning

\- simple programming model

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

------
jonplackett
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?

~~~
nicoburns
> 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
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!

------
michaelmior
> to zero and backup

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

~~~
dsumenkovic
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/...](https://gitlab.com/gitlab-com/www-gitlab-
com/merge_requests/17295).

Thank you for pointing this out and sorry for the confusion.

~~~
dopeh
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.

------
manigandham
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?

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

~~~
teekert
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
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 ...

------
mr_toad
Article does a very good job of burying the lede.

tl;dr; GitLab have have a FaaS offering in alpha.

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

~~~
rolandboon
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
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.

