51–60 of 126 posts
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 there really a big demand for this?
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…
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…
I'd like to think 4) is actually Containerless or PaaS - "I want to run App". Serverless or FaaS takes this a step further to "I want to run App on demand". What do you think?
Earlier quoted context omitted.
> 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.
regarding your k8s comment, did you mean kubeless?
Earlier quoted context omitted.
I feel the whole "not paying for underused server" argument is pointless when a serverless solution is way more expensive than paying for an idle server.
But it's so much cheaper bud (it's not). It maybe is only when you're doing <= $10/month.
Earlier quoted context omitted.
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 :)
[0] https://gist.github.com/shaunpud/35f77b542eaec7c7024bbb15c2e... [1] https://lowendbox.com
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?
Earlier quoted context omitted.
I feel the whole "not paying for underused server" argument is pointless when a serverless solution is way more expensive than paying for an idle server.
It isnt more expensive! Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. Not only would it cost more but you'd probably hit the concurrency limit in AWS Lambda. But we also have an admin UI that gets about 2500 visits a day. We're running that for about $4 a month - with virtually no operational burden whatsoever, and with a reassurance of resilience. We worked ou…
A managed app runtime can be great though: for those who tried Google AppEngine back in the day, it was amazing to work with.
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…
> 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_req…
Would love to hear some feedback if anyone has some.