Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab Serverless

about.gitlab.com

Post reply on HN
Print view View original

101–110 of 126 posts

Re: GitLab Serverless

#101

Post by bryanlarsen »

williamchia wrote: post #82
bryanlarsen wrote: post #51

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.

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

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.

Re: GitLab Serverless

#102

Post by cortesoft »

rkangel wrote: post #47
PurpleRamen wrote: post #14

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?

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

There is a step between 1 and 2, where you pay a per-month fee for an actual server that the provider owns. That was pretty standard operating procedure in the mid 2000s.

Re: GitLab Serverless

#103

Post by mo1ok »

PurpleRamen wrote: post #14

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?

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.

Re: GitLab Serverless

#104

Post by SahAssar »

amyjess wrote: post #80
antocv wrote: post #18

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

Serverless means "I don't have to maintain or even know anything about a server", not "there is no server".

If so any memory-managed language should be called memoryless, any non-low-level language should be called osless and so on. It's an absurd naming scheme.

Re: GitLab Serverless

#105

Post by tracker1 »

y4mi wrote: post #63
rkangel wrote: post #47

Earlier quoted context omitted.

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

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

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.

Re: GitLab Serverless

#106

Post by tracker1 »

ddorian43 wrote: post #62
mickael-kerjean wrote: post #56

Earlier quoted context omitted.

I don't know if it's the HN effect but I never had a scaling problem. Prior acquisition the story says whatsapp used to run on a single server

It depends on the type of application. But when at 5pm your traffic grows by 200x (hint: it doesn't) and you petascale your aws vps megafleet (hint: you don't, especially your database you don't) then you are on route to unicorn-scale hypergrouth cash-money-team-happiness.

My personal take is this...

1. start with docker (or dokku), on a single server, it's easy enough to get going, automate CI/CD. Make sure your backups are working and relatively frequent.

2. Break your lower environments on to a separate server.

3. Break out your database, and set up redundancy at that layer. Leverage DBaaS if you can.

4. Grow to multiple app/api instances for redundancy, and setup rolling deployments.

5. Scale Vertically (bigger servers/instances)

6. Migrate to Kubernetes and expand your automation and tooling.

7. Break apart your application into smaller pieces to scale individually. Possibly leveraging platform tools like Lambda/Functions.

8. Work towards redundant datacenter and application data sharding to deliver a closer experience.

By the time you get to 5-6, you should be making money or have a good investor strategy in place for capital. There's very little need to go all out when at concept or earlier release stages.

6-8 may take place in a different order, depending on your needs.. but again, you should have money or have raised capital by this point, or you have a relatively good problem to have otherwise.

IIRC Stack Overflow grew vertically pretty big on a single server, then two (db/application split).

Re: GitLab Serverless

#107

Post by blacksmith_tb »

icebraining wrote: post #33
nightfly wrote: post #26

Earlier quoted context omitted.

Just like old shared webhosting :)

Most webhosting plans are fixed monthly fees, AFAIK. The only one I knew that billed for used resources was NearlyFreeSpeech.

Was? [1]

1: https://www.nearlyfreespeech.net/services/pricing

Re: GitLab Serverless

#108

Post by Aeolun »

sytse wrote: post #91
Aeolun wrote: post #81

Earlier quoted context omitted.

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

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 as long as it is the same version. I think the output is a single file.

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.

Re: GitLab Serverless

#109

Post by berlinstartup »

hardwaresofton wrote: post #10

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

> It feels like if they can manage orchestrating serverless functions they can manage orchestrating containers or VMs...

Ah, but they cannot. We have the misfortune to be stuck with them at my workplace, and it's painfully obvious that they don't test nor use the kubernetes features, as most of them are straight up broken. I have no trust in them whatsoever.

Re: GitLab Serverless

#110

Post by robot »

PurpleRamen wrote: post #14

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?

https://medium.com/@bahadirbalban/what-is-serverless-and-wha...
Post reply on HN