GitLab Serverless (opens in new tab)

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.

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.

The way I see it, it's basically just a cost-saving measure. If you have some very varying workloads, instead of paying for having a bunch of servers running all the time (and idling most of that time), when you actually need the extra compute power you can let AWS Lambda spin up a server, run the code, then spin it down again. That's clever and all, and might save you a pretty penny if you have huge workloads only part of the time - but for most users, it's hardly worthy of the hype.

It does feel like just FTPing a .php file into your LAMP webhost, but with autoscaling, slicker UX and much more vendor lock-in.

It’s kind of similar, but imagine php without the ability to break anybody else on the web host and infinite resources as much as you wish to pay. So no server migrations. No debugging performance problems.

So it is just the natural progression of a shared LAMP host that’s worked well for 20 years.

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.

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

People abuse the term serverless, yes to mean "cloud" or "somebody else server" and "just write the function you want we will find a server to run it on and report to you the result".

The term I like to associate with serverless is all peer-to-peer, not client-server architecture, for example any datwebsite, on datproject, and any zsite on zeronet.

There you dont have a server, really, a zite is a peer in a torrent swarm like any other, and can be found like any other torrent by its infohash (sha1) in the DHT, and can at any time go offline, while the swarm continues as nothing happened, new people can still access the zite from peers - and the zite despite rendering in a web-browser, can/should not really talk to any server, only to a peer-to-peer network. There is no "form submit" allowed on a zite, then it defeats the purpose of zeronet and similar techniques.

Another example is gun.js

It's the new PaaS, but scoped down to a smaller payload of just a single function, although most platforms now let you upload an entire app or container anyway.

The other big change was removing the concept of servers/instances altogether so there is no step-wise scaling at all that you can see or control.

It just simplifies an entire field of software engineering (devops) into a simple "one-click" setup.

Before, you had to open an account, provision a server, figure out your machine image, install dependencies, figure out error/process handling, deploy...

...figure out optimization, payment, RAM usage, longevity, how many instances do I need? What are peak hours, and should it autoscale?

No you just run a single command line and it's up in the cloud, figuring all that out for you automatically.

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

I think they are managing the continuous deployment part of the devops cycle which is traditionally done using webhook.

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!

To clarify, we are not getting into the cloud play at all. We support multi-cloud deployments of any kind now including serverless. So you can use the GitLab UI to plan, build, deploy, manage serverless apps/functions with the rest of your code. Knative helps us deploy to any cloud.

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.

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.

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

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?

It’s based on Knative I think, so this is an open source, kubernetes-based alternative tied into GitLab.

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

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.

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.

Yes, sorry about that! Thanks for fixing, dsumenkovic :-)

> 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

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

So I hope to upgrade to that soon.

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

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.

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.

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.

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

- on-demand pricing

- no capacity planning

- simple programming model

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

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