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.
GitLab Serverless
21–30 of 126 posts
Re: GitLab Serverless
#22Can 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?
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 s…
You are coming up with your ow definition of serverless. For most people serverless means
1. Per invocation billing 2. No need to provision resources ahead of time
Taking AWS's example
1. EC2 is not serverless but Lambda is 2. RDS is not serverless but Aurora Serverless is.
Re: GitLab Serverless
#23Can 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?
It does feel like just FTPing a .php file into your LAMP webhost, but with autoscaling, slicker UX and much more vendor lock-in.
> and much more vendor lock-in.
This is a myth that really needs to be busted. There is almost no lock in with serverless. The serverless products from all the major providers are nearly identical.
The lock in comes from the services you are using within a particular cloud, which you can avoid if you want to by running everything else in k8s.
Re: GitLab Serverless
#24Can 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?
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.
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.
Re: GitLab Serverless
#25Can 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?
It does feel like just FTPing a .php file into your LAMP webhost, but with autoscaling, slicker UX and much more vendor lock-in.
With the difference that you pay per request instead of per month / year. Mind you, given how cheap LAMP webhosts can be, I'm fairly sure they would be cheaper if you don't need the autoscaling.
Re: GitLab Serverless
#26Can 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?
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.
Just like old shared webhosting :)
Re: GitLab Serverless
#27I'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 does…
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!
Re: GitLab Serverless
#28Can 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?
It does feel like just FTPing a .php file into your LAMP webhost, but with autoscaling, slicker UX and much more vendor lock-in.
Does it really? As far as I understand it, in a traditional webhost you have a certain set of resources allocated to your account for which you pay even when 0 traffic hits it. Serverless consists of an isolated chuck of logic that runs only when a request hits your server. When the traffic is 0, server resources are blocked on an idle service.
Re: GitLab Serverless
#29Earlier quoted context omitted.
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 s…
You are coming up with your ow definition of serverless. For most people serverless means 1. Per invocation billing 2. No need to provision resources ahead of time Taking AWS's example 1. EC2 is not serverless but Lambda is 2. RDS is not serverless but Aurora Serverless is.
It's not their own definition, this was the default definition just a few years ago.
Re: GitLab Serverless
#30Is 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?