41–50 of 126 posts
Earlier quoted context omitted.
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!
Here: https://docs.gitlab.com/ce/ci/merge_request_pipelines/index....
(I have this page favorited)
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.
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.
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.
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.
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 out that the inflection point of value is at about 3 million requests a month. (that's an fag packet estimate, arbitrarily expensive 'request', your mileage may vary).
Its no silver bullet, but for some applications, particularly personal projects, low traffic and startup scenarios it can be ideal.
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…
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...
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.
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 reward…
Only if you attach k8s right? Or can you leave services deployed with normal CI Jobs that don't end?
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?
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.
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…
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?
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?
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.