8 ms·
This is a good write up of why you shouldn’t give away the house when you open source things. The issue was really this: Earthly being open-source, Earthy Satel
by reactordev 3y ago
This is a good write up of why you shouldn’t give away the house when you open source things. The issue was really this: Earthly being open-source, Earthy Satellite users were already seeing the benefit from 95% of Earthly CI.
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 or a service you provide 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.
*EDIT* I'm not suggesting withholding features that are critical for the software to operate, but withholding business features that provide support or enterprise-level integration. Even making it tiered so the power users pay less because they support it more themselves?
- hhh 3y agoI feel almost certain someone could wrap ArgoCD into a product if they handled the 'patternization' of applicationsets. D2iQ already do it with Flux, but we bailed on D2iQ before we even got to try it.
- gabereiser 3y agoArgoCD is almost worthless if your DevOps teams are IaC wielders. Honestly, just a bash script to push a container to the pods is all that’s required for DevOps deployment. A build pipeline should be get artifacts -> put artifacts in container -> push container to registry -> trigger a pull on your pods. If you didn’t have a standard cloud architecture, I can understand the frustration and reasoning behind looking at ArgoCD. If you have a standardized cloud practice, it’s moot.
- hhh 3y agoMy needs are more 1 application, 150 configurations, 150 clusters.
- jangxx 3y agoYou can self-host Gitlab CI runners and use them even in the free community version.
- gabereiser 3y agoI know, this is what I’ve been doing for years. (edit on GitHub, not GitLab, didn’t know GitLab allowed community CI now)
- jangxx 3y agoThen I guess I misunderstood "GitLab restricts CI/CD to paying customers"?
- gabereiser 3y agoSorry, I misread your comment as GitHub, not GitLab. I was unaware you can run CI runners on GitLab community version.
- prometheon1 3y agoI thought using your own runners for free in Gitlab was already an option before Github Actions even existed
- reactordev 3y agoWhen it was an open source project, yes. You are correct. Ever since GitLab went commercial, it's been behind a paywall. Apparently you can run runners on self-managed CE so I'm going to look into that.
- smashed 3y agoOn Gitlab.com you need to input a valid credit card once in order to validate your account, but you can still get 400 minutes on shared runners for free. 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.
- dpeckett 3y agoI'm not sure feature withholding has traditionally worked out well in the developer space. The churn rate for tooling is so high that if Earthly were to intentionally cripple their product I'm sure the majority of developers would just move on to other inferior, but free, options (eg. taskfile). Maybe those that remain could be converted successfully but it's quite a gamble. 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.
- gabereiser 3y agoYeah, not suggesting feature withholding per se, but a differentiator on why one would buy vs run the OSS build.
- staunton 3y agoWhat's the difference?
- gabereiser 3y agoplugins, hardware, hosting, support, there's a number of ways to offer a service for an open source project. Open Core models come to mind. Another is not having enterprise SSO as part of the core. Or not having clustering. Something that would make a VP think twice about adopting your open source solution vs using you as a vendor.
- justin_oaks 3y agoI know these are examples, so I don't want to pick on you too much, but I have one nitpick: Reserving SSO for enterprise customers is awful. Please don't do it. See https://sso.tax/ 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"
- rhaps0dy 3y ago
- isoprophlex 3y ago> Azure DevOps is the devil. Amen to that!
- shandor 3y agoIs there an actual technical point beyond ”MS bad” for this sentiment? Honestly asking, as I’ve been mostly hearing positive things about AzDO, and from developers of all people.
- datadrivenangel 3y agoADO makes me yearn for Jira. 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.
- shandor 3y agoHah, thanks for that mental image. 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.
- WorldMaker 3y agoAzDO Pipelines was directly the first draft of what became GitHub Actions, so technically it does have a lot to recommend it, especially if you learn the Multi-Stage YAML approach which does sort of directly feed into GitHub Actions for the eventual day you decide to migrate.
- datadrivenangel 3y agoYeah, the Pipelines are okay all things considered.
- AaronM 3y agoDid you mean argowf instead of argocd? Argocd is pretty simple and only syncs k8 resources.
- gabereiser 3y agoI mean that node (not js) dashboard to build pipelines and make things look logical instead of writing 4 lines of bash. I'm not a fan of anything that adds complexity. ArgoCD/WF/ALL ARGO... is just a pretty dashboard over cli tooling. ./deploy.sh <repo>@<version> <pod-name> This is the contract you should focus on. Whatever you need to make ./deploy.sh do this, do it.
- psYchotic 3y agoIsn't ArgoCD more of a GitOps tool? The pretty UI is mostly secondary to its main purpose for me, which is to keep the declarative "truth" in source control, and have ArgoCD be the control loop that keeps the cluster in sync with that truth. Accidentally nuked namespace? No worries, ArgoCD's (or whatever alternative, like flux) got your back!
- rrrix1 3y agoExactly this. The critical difference being who deploys and when/how your resources are deployed - a human, or a machine. 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.
- gabereiser 3y agoI don’t accidentally do anything in production. Sorry. Nor do my teams or any developers who have access to my clouds. These kinds of failures don’t happen in my world. You will not have a mutable environment outside of data storage. Period. Nuke all you want, it will repair and redeploy itself.
- 3y ago
- ilyt 3y agoFrom my experience hosting our own instance of Gitlab + few CI/CD workers was few weeks of initial work (integrating with company's LDAP etc.) then around one ops-week per year worth of maintenance over last few years (50+ developers, dozens and dozens of projects). 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).
- gabereiser 3y agoYou just described a great starting point for a small shop, I would recommend this route 100%. 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.
- ilyt 3y agoThere are actually authentication providers that will pretend to be LDAP server for your apps, regardless of what auth backend you use. 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.
- maccard 3y agoWe use buildkite but if I was starting fresh now I would just use github with github actions.
- maratc 3y ago> Swarm’s of Jenkins is what most are used to in the enterprise. Thanks, I thought we were one of the last places with that setup, nice to know this unholy contraption is actually somewhat standard.
- gabereiser 3y agoIt’s the one true daemon of the enterprise. Unholy. Can’t die. You’ll find it in the darkest places. But it does it’s masters bidding.
- sanderjd 3y agoI know this is controversial, but I wish commercial "source available" were the more mainstream / not-shat-upon approach to services, rather than "open core". 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.
- dpeckett 3y agoStallman was right. I think it's inevitable we'll see the next generation of developer focused tooling go in the direction of AGPL or source available (eg. BSL). Ironically enough Earthly started off as BSL.
- sanderjd 3y agoWhat did Stallman say about this?
- MaxBarraclough 3y ago> 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 https://en.wikipedia.org/wiki/OpenSSH#History [1] https://en.wikipedia.org/wiki/MariaDB https://en.wikipedia.org/wiki/MariaDB [2] https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html [3] https://opensource.org/osd/ https://opensource.org/osd/
- sanderjd 3y agoI mean, I'm very glad that open source (and also free) software exists. I don't think there should only be software with source available licenses, and I certainly admire and appreciate the giant amount of foundational work that has been done under those licenses. 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!
- paxcoder 3y agoThat is not at all the conclusion the author draws from this experience of his. Here's more of the paragraph, you quoted: >Earthly being open-source, you could already run your own Earthly remote runner (since we use Buildkit underneath, it was essentially a remote Buildkit), connect Earthly to it, and get similar benefits to Satellites even before this was a commercial offering. And so people did this on their own, hosting it in their own environment, without us managing it for them. Once we had this packaged up in a managed offering, people were flocking to it, mainly because they did not want to manage remote runners on their own. The author blames the failure on not validating what the were building was what clients wanted.
- AlphaSite 3y agoI think the main competitor is gitlab and GitHub, it’s very hard to compete with them. It’s not competing with earthly OSS. Personally the reason we haven’t used earthly satellites or CI is because we can’t use them inside the corporate firewalls, nor does it integrate with our existing CI tools super well, e.g. gitlab. We use it and love it but it’s missing important enterprise features like that and SSO.
- XCSme 3y agoThis is why I don't believe in businesses that offer both open-source and a paid cloud version. Their business goal is literarily: make sure the open-source version is not so good and easy to use/install/maintain, so that people do need to use our cloud offering.