This is used to combat abuse and crypto miners, they don't actually charge the card.
You can also connect your own private runner to either the saas or self-hosted gitlab-ce for free, you just have to provide your own runner.
You can always connect your own runners to GitLab, whether SaaS or self-hosted, and whether free/CE or premium/ultimate/EE. GitLab SaaS also comes with free use of the central runners up to a quota. I'm not sure about the history here but as far as I know this has always been the case.
Hi Spivak, You're not Lee Spivak (formerly of Upromise in the early 2000's), are you?
A great turn around story in recent times though is probably Docker. But that required them to abandon strict open source and make controversial license/product changes.
See https://sso.tax/ for details but I'll quote this from it "SSO is a core security requirement for any company with more than five employees"
BTW, I did just this this morning. The AE came back to offer the enterprise package for the price of the mid-tier package.
SSO Tax is a fun meme, but it misses the point: Whether it's 5 people or even 3, you've scaled your business enough to hire people who aren't in the inner circle.
That's a fair place to consider you an enterprise.
It's to allow centralized access management. Stuff like firing someone and revoking their access from one platform instantly, instead running around and changing permissions in every tool manually. Or ensuring people in department A can't be invited to some platform for people in department B in order to limit information access.
SSO tax is predicated on the idea that the moment you outgrow the informal arrangements and liberal access, you're really a business. Seems pretty fair?
Technically it's an anti feature...
The "feature" you are talking about is really identity management not sign on (which, btw, users have different identites, outside of the scope of a single company).
At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridiculous price tag).
Separate services otherwise are enough, no need for SSO.
Can you explain more about how this works for SSO?
Let's say I'm trying to launch a product (which I am), and want to have SSO as part of the package (which I do), how do I implement what you just said?
I looked into SSO services and they're bloody expensive, so if I can cheaply do it myself, I will.
SSO is hairy enough that you can't write it from scratch in any reasonable amount of time for what a typical SaaS needs.
There's OSS SSO you can host yourself that supports enterprise : https://www.keycloak.org/
If you're B2C Firebase Auth is cheap, and doesn't actually require hosting on Firebase
I expected so, looking at how much it costs to provide just SSO as a service.
Thanks for keycloak, didn't know about that.
The comment about customers is possibly valid, the difference entirely your use case. If you consume services as a corp, and your goal is to be able to decouple any employee quickly, then you do not need SSO, assuming each service you use allows you the option to delete by username (with proper auth, ofc).
SSO is only needed when you want to give a customer federated access (ability to assign roles without activation on their part). For an internal corp it is largely unnecessary and a convenience thing not a security one (it is much more secure to require different passwords for every service versus a global SSO credential that gets you everywhere).
If your "customers" are your own employees, then this is your decision not a use case or a business requirement.
If you think you need SSO and but you do not have the budget for upgrading to their enterprise tier, may be you are not the right customer that they are targeting to sell. It is not you, it is them.
I wasn't thinking as the service provider that needs a way to force the folks with the big bucks to pay up.
It sucks for the little companies, but it may be necessary for the service to do so.
SSO is expensive, adding maybe $10/user/month if the team adds in a purchased solution (passing the cost directly onto the client).
If the customer doesn't want to pay for it because they aren't an enterprise, you can't blame the supplier for not supplying it at a lower price than $10/user/month.
While we acknowledge the reasons behind SSO being in the enterprise tier, we're all on a collective journey to enhance our security measures. Open Core models are indeed a good option (my preference), yet the dynamics vary across solutions and industries. It's up to each of us to explore, experiment, and discover what resonates with our market. In doing so, we can foster growth while maintaining our commitment to supporting the community in the long run.
It's very tricky to balance the open core model correctly, which is why not many companies get it right. You need to invest equally, if not more, in the OSS product, and make sure users are happy with it before you even mention a commercial addon. Grafana is another example of companies that understand and do this well.
It's fine to criticise Nix for its various flaws, but any suggestion of an "alternative" that has learned nothing from it is just a collective waste of time.
For any other project, I can spend half an hour max to get a decent deployable build. The trade offs is Nix doesn’t seem to work for me.
You say that while your ecosystem still can't get away from cutesy childish terms like "flakes" and "pills". Newsflash: nobody cares. I want "a package" and "a system".
I am not impressed. Before you look down on others make your own thing look uber-professional and then uproot any and all nerd-friendly marketing from it, now and forever. "It was in fact just a phase, mom" -- that's the aura that Nix should radiate before I give it a second chance.
Nix is supposed to solve a very serious problem and if it actually succeeds in that technical goal, the next step is for them to act like it. Very often you're marketing to CTOs or other tech executives -- working programmers are only one chunk of your audience. So that ecosystem has to do better -- starting with you. Your two comments here are basically a text-book argument against using Nix.
I've been a CTO and VP of Eng and I have skipped projects that can't sound professional. I know I have missed out on good stuff; I am very well aware. But we all have only 24h in a day, and only so much energy. We have to filter. One of my filters is: perceived / marketed professionalism.
(To be fair to all sides, I like the nixos.org website. I don't like practically anything else about the ecosystem though.)
> It's fine to criticise Nix for its various flaws, but any suggestion of an "alternative" that has learned nothing from it is just a collective waste of time.
Let's start with that one: nobody needed one more programming language. Nobody will "see the light" if every new technology requires one more knowledge investment. Somebody must tell you that programmers, DevOps, full-blown Ops, CTOs etc. are already overworked and already have to know and regularly catch up with way too much.
If Nix is aiming to help people work less on very annoying problems then it should, you, actually make them work less.
Nix's marketing is a complete mess. "We want you to think less about A and B so here, now learn, X, Y, Z and you should still know A and B -- but it gets better after, one day!".
Nah.
It's fine that you found technology that you love but your bias is very clearly visible and you lack the introspection skills to see that Nix is not that impressive.
Give me a `curl ... | bash` installer plus instant onboarding plus zero upkeep (an oft complaint about Nix btw) and I am sold. Anything less than that, to me you are just one more voice in a huge crowd where everyone screams "use my thing, it's amazing!".
Differentiate yourself and people will flock to you without you having to lift a finger. The fact that this hasn't happened yet is a strong hint that Nix fans are refusing to notice and take a lesson from.
You should get off your high horse. Nobody cares about you having been a "CTO" of some random venture-backed company, it doesn't give you any credentials which you can fling at people to "win" debates online. 80% of the people on this forum have some useless title like that in their CV. You being able to write lots of words about irrelevant superficial topics doesn't mean that you have anything useful to say, even if you've previously been led to believe that these are equivalent.
I don't care where you flock. I publish all my Nix related work for free, I don't have a personal stake. Your decisions are your problem.
Well, OK, now I know who is on the high horse so let's drop it here.
Shame that tech zealotry never dies.
It’s worked well for GitHub, Slack, and pretty much every service that only offer SSO behind enterprise subscriptions.
The trick is to offer enough to make people productive but not so much that there isn’t a worthwhile upgrade path.
Earthly is a single binary CLI on top of Docker buildkit so it's a bit trickier for them.
Also you’re getting too caught up in specifics and missing the broader point. You want open source examples? How about Nexus, Redhat, nginx, prettier much all of Hashicorps offerings, basically half of why AWS resell.
The real issue with commercial open source isn’t restricting access to customers, it’s restricting access to resellers. As demonstrated with the examples above.
I think it's worked out well for Sidekiq (https://sidekiq.org). I really like their model of layering valuable features between the OSS / Pro / Enterprise licenses.
The trick is you have to do that very early on. Nerfing your open source offering by making some existing features paid-only is always going to get some backlash.
Amen to that!
Honestly asking, as I’ve been mostly hearing positive things about AzDO, and from developers of all people.
(One of the most recent signs of this crazy zombie state that a recent feature for AzDO was given the absurd only Microsoft could do brand name "GitHub Advanced Secure for Azure DevOps", and it is indeed a bundle of GitHub features several years old at this point finally provided to AzDO users. Other signs include all sorts of AzDO libraries and roadmaps and related repos openly hosted on GitHub with last updated dates in 2019 and 2020.)
From an outsider perspective, Microsoft probably has a lot of sentimental and internal engineering reasons it doesn't want to truly wrap up so much of its operations in North Carolina (AzDO's ancestral home going back to early days of TFS), but the writing seems to be on the wall that what's left is a skeleton crew mostly working for GitHub full time and then sort of applying things part time back to AzDO. It doesn't seem to me to be sustainable long term, and every day it feels more like an Old Yeller situation where Microsoft is just prolonging the inevitable and making the pain worse for everyone involved.
The old issues + tags + milestones was perfect. Now it’s the same needlessly-heavy thing as all the rest, with their reimagined “projects” thingy.
But then again I’ve not once seen a PM embrace any version of GitHub’s project management, with the only explanation forthcoming being “it’s confusing for non-technical users” (fucking how? More confusing than Jira or Asana? No friggin’ way) so maybe they have to shit it up and make it hard to use and easy to get lost in or miss info in, to get any traction with PMs.
It definitely seems one of those sorts of "every system PMs touch is doomed to become unmanageable complexity" laws and GitHub "Projects" does seem to be exponentially closer to being "Jira 2: Electric Boogaloo" every day.
It was intended to be a SAAS version of the on Prem offerings MS has provided since before GitHub even existed.
The boards are terrible, the UI is hard, the permissions are incomprehensible, it doesn't even integrate that nicely with Azure.
On paper it does everything, it practice it can be made to do everything, but it's like getting citrus drenched sandpaper papercuts every day.
As I said the positivive sentiments I heard came from developers, and TFA is about CI (rather than boards etc. that JIRA handles, so is there maybe anything remotely positive in how AzDO implements CI, git integration, testing, etc? Or is it just rotten to the core?
Hard to imagine someone would hate it more than Bitbucket Pipelines or, god forbid, Bamboo. Buuut I’m more than open-minded if need be.
./deploy.sh <repo>@<version> <pod-name>
Having git be the source of truth of your production environment is a blessing and a curse which is directly related to the maturity of the deployment system.
If you have low confidence in your deployments (as in, you don't deploy very often and don't have full e2e tests & monitoring), GitOps is nightmarishly scary compared to classic, battle tested Ops team CLI scripts.
No one EVER should run deploy.sh like how you propose it.
ArgoCD abstracts away access to a k8s cluster (login through dex).
It has strategies of how to deploy k8s resources like through retry, replace (which you would need to write manually in your deploy.sh).
It gives you debug output for your deploy process (yes thats a thing, you do not assume every deploy just works).
ArgoCD also can and should be used to reference secerts from secret store like vault.
And it gives you a history/audit.
In a small business (read: startup), `deploy.sh` is all you should have. When you go on vacation and it breaks, I just need to read a bit of bash/python/php/whatever-script-you-use.lang and fix the broken stuff.
What they had befor was a terraform based pipeline (i would argue similiar to a deploy.sh) and they struggled with those scripts hard.
ArgoCD with dex is easily integrated in your auth system and you don't need to write some scripts to handle issues like login errors, timeouts etc.
I have seen plenty of bash scripts which do exactly what they should do with 0 error handling and it was always a pain in the ass to analyse and fix those scripts.
ArgoCD is super easy to setup, has a declarative setup and is a great platform tool.
I introduced it to big systems and i really can't imagine how we would struggle if we would deploy those infra components with some bash scripts.
Could you be more specific?
Like assume you have some monitoring stack (kube-stack or grafana etc.) and either as a helm chart or as something else: What do you do when a CRD needs to be replaced? You write it in your deploy.sh script through some bash magic? Handling error cases in there?
What do you do when you want to see what you have deployed? Like checking if your test setup is rolled back? You always use kubectl to check some helm values? Or do you always annotate all pods with git commits which you then c&p?
A basic ArgoCD declarative setup takes perhaps a few hours if you do it for the first time, than you can give teams access to namespaces, they have log access, exec access if you provide a platform that is, in my opinion, quite a big advantage over just letting them use kubectl. Most developers i know do struggle with kubectl.
And for my own infra ( i also even setup argocd at home ) the dev cycle is much faster for me.
What "crappy cloud architecture" problem are you talking about specificly argocd apparently solves?
How do you test components? Like we have a test cluster and everyone uses argocd to just switch to a dev branch for a few days while testing. This works really well and you can switch back to main in argocd. And due to Argocd App Def you can even see all apps out of sync due to testing.
Before that we had just "a git server + jenkins + some slaves" that took even less maintenance (althought I'd imagine more fumbling on dev side with job config)
Earthly isn't cheaper than any of those options and none of our clients use it (and we occasionally have to work on client's gitlab instances).
Initially your CI/CD needs to be close to the code. It needs to be close to developers. Not a DevOps department. It needs to be almost forgettable. Include a config in your repo, bam, welcome to the pipeline.
Where this breaks down is when you don’t have LDAP, you have Azure IDP + Amazon’s Cognito + Keycloak 3rd Parties + SAML (barf) + Form Login for contractors + JWT/OAuth for services.
This is the inflection point where you need DevSecOps + Architecture + Cloud Engineers to ensure everyone’s playing nicely. Enjoy your pods. Let us know when you need that VPN tunnel to your customers backend because they don’t trust SSL.
But yeah, once your clients are big corporations you'd at least need to know how to implement some kind of cloud mess of authentication provider(s), still, doesn't need you need to infect your own stack with it.
Thanks, I thought we were one of the last places with that setup, nice to know this unholy contraption is actually somewhat standard.
I find it very frustrating to not be able to read the code or contribute bug fixes or self-host anything outside the "open core", and I have no need for any of the things that distinguish "open source" licenses from "source available" ones.
This strikes me as short-term thinking.
If you've ever used OpenSSH or MariaDB, say, then you've benefited from the right to fork, granted by Free and Open Source licences. [0][1] There are of course thousands of other examples.
This is what the FSF calls Freedom 3, [2] and what the OSI's Open Source Definition calls Criterion 3: Derived Works. [3]
Needless to say this kind of thing typically isn't permitted by source-available licences.
[0] https://en.wikipedia.org/wiki/OpenSSH#History
[1] https://en.wikipedia.org/wiki/MariaDB
But I think it comes with its own trade-offs. For instance, I might say that preferring open source is short-term thinking, because projects can become both critical infrastructure and essentially un-funded, and use one of the same examples you did, of openssh.
And I lament that people seem to be less critical of entirely opaque proprietary software than of source available software. I think if the only viable choices are nonprofit+open and commercial+closed, then we are going to end up with more closed software that is of higher quality than its open alternatives.
In general my interest in this topic flows from dissatisfaction with funding models for open source software. I really hate that so much important software relies on under- or even entirely un-paid labor to create and maintain it. I'm not under illusions that alternative models are a panacea, but I'm also not satisfied with the status quo. I get paid well for my work, and I hate that so many people whose labor I rely on aren't getting paid well for theirs!
I don't follow. All told, OpenSSH is still going strong, and it owes its existence to the right to fork.
The FOSS model has a good history of software project longevity, especially compared to, say, proprietary software developed by start-ups.
More generally, the rights granted by FOSS licences are a good (albeit imperfect) protection against software turning user-hostile. To that end, a FOSS licence might not be sufficient, but it seems to be necessary.
> people seem to be less critical of entirely opaque proprietary software than of source available software
The Free Software Foundation used to consider semifree software to be its own subcategory of non-Free software, but they no longer make the distinction. [0] This makes sense given the organisation's goals - they don't want to be seen to be giving partial credit to licences that, while not as bad as some others, still deliberately deny the user the '4 freedoms'.
I agree that non-Free-but-source-available is better than non-Free-and-source-unavailable, but there are good reasons the Free Software and Open Source software movements have the principles they have.
> my interest in this topic flows from dissatisfaction with funding models for open source software.
Agreed. It's frustrating that so few people or organisations think to contribute to FOSS projects, even ones they deeply rely on.
There are ways to monetise aside from patronage/donation, such as paid support and paid managed services, but unfortunately it seems these are rarely successful in generating appreciable income.
[0] https://www.gnu.org/philosophy/categories.en.html#Proprietar...
Sorry, this was too implicit. What I was alluding to was the period of time when openssh had some showstopper security issues, and everyone realized it was being maintained by essentially one person with essentially no funding.
I don't want to downplay that the copyright owner of source-available software taking it in a bad direction or stopping maintenance or going out of business altogether is a big risk of that model (and of fully proprietary software as well). It totally is, and it is definitely something that the ability to fork solves.
But my point is that it's a trade-off. Both models have failure modes. And they both have (different) imperfect solutions for them.
> Agreed. It's frustrating that so few people or organisations think to contribute to FOSS projects, even ones they deeply rely on.
This is probably where our fundamental difference in philosophy comes from. I don't think it is at all the case that people don't "think to contribute to FOSS projects", it's that the incentives don't work out in favor of it, for most organizations. And I don't think the answer to that is to wish for altruism from organizations and free labor from individuals.
> There are ways to monetise aside from patronage/donation, such as paid support and paid managed services, but unfortunately it seems these are rarely successful in generating appreciable income.
Yeah, as I said, I find all of these solutions deeply unsatisfying. Patronage/donation has the "relying on altruism" issue. Paid support misaligns incentives, because if you manage to make perfect software, you've also managed to put yourself out of business, whereas if your software is difficult to use, that makes it lucrative. Paid managed services would be great, if Amazon couldn't just slap your code behind an official AWS service that 99% of people are going to use instead of your also-ran; but keeping them from doing that requires the restraint on commercial re-distribution that everyone seems to hate.
We use it and love it but it’s missing important enterprise features like that and SSO.
I’m a huge fan of open source, however, if your business model includes an open source model - you need a differentiator. Beyond blazingly fast(tm). You need a reason for people to offer up their credit cards, or better, their accounting PO process. You need a feature you withhold from the open source offering to make it appealing.
GitLab restricts CI/CD to paying customers. Travis/CircleCI limit on build time/credits unless also open source. Azure DevOps is the devil. ArgoCD is complicated. GitHub actions are nice if you have hardware to run the runners. Swarm’s of Jenkins is what most are used to in the enterprise.
As a former Director of DevOps, my immediate question will be what features make me want to buy vs host myself. I’m technically capable. Why should I buy with you when I can run my cloud and my DevOps pipelines for my workforce the way that makes the most sense for my business? Help me make the most sense.