We built the fastest CI and it failed • Hacker News Board

Re: We built the fastest CI and it failed

#191

Post by px1999 » Tue, Sep 12, 2023, 9:00 PM UTC

> it didn’t make sense for them to jump head-first into an expensive and time-consuming migration effort just because some startup they had never heard of promised to deliver the sun and the moon

> we need to shut down Earthly CI

Is it possible that it all boils down to these two points? The technical benefits don't matter if there's even a hint that your (fundamental to my business') service could fail and be removed.

When I read this it sounds like a technically great idea which solved a problem in a way that missed some fundamental prerequisite for their target user group (and hence success).

Re: We built the fastest CI and it failed

#192

Post by mcnichol » Tue, Sep 12, 2023, 9:04 PM UTC

rewmie wrote: post #129

mcnichol wrote: post #105

Not to rain on the parade here but this is literally a copy-pasta product. Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines...and surprise surprise when you look at where he came from...Ex-Google, Ex-VMW, RabbitMQ... If OP wasn't in and around the source of all these tools above then they were at the very least first cousins to the story. The sales cycle is long, integrations require multiple dimensions of ex…

> Not to rain on the parade here but this is literally a copy-pasta product. More to the point, the product offered no compelling reason to use it, let alone pay for it. Being "fast" is not a selling point. Developers don't want slow pipelines, but that does not mean they want fast pipelines. The speed that the pipeline works is more depending on how the pipeline is setup than the overhead of the pipeline service, an…

Absolutely.

If you told me:

"This pipeline will automatically perform all of your [insert line of business] testing, batteries included.

XYZ has signed off that if you get to the end of this pipeline you do not need to jump through any hoops to get to production." I would be screaming on a soapbox

There is too much process to know about a company to make any claim with any certainty and these companies will not tell you their process because you are a salesman, not their friend. Technology Sales is "Frenemys" at best and "Inherited Cancer" at worst.

Here's a pitch for OOP. If you do this you will have a line around the door: "You can run this on your own internal cloud, public cloud, or mix of both. Hit the eject button and it will give you a [Docker, CircleCI, Jenkins, Travis] playbook to lift and shift your pipeline. Every app that goes through alerts each C?O that cares how it meets their KPI, Security Whatever, etc.

Set the bar as high as you want to get through the pipeline. Mission Critical? Core Business? Skunkwerks? This can be in the DMZ, this can't...you make the rules, we are the engine that enforces them."

I can tell you right now, your success will be predicated on Networking and Security teams that work together effectively and selling high enough to start the ball rolling.

We have this absurd "Throw paint at a wall and see what sticks" approach to doing business and then "People don't really want what I made" response when it fails. Look inward.

Re: We built the fastest CI and it failed

#193

Post by internet101010 » Tue, Sep 12, 2023, 9:05 PM UTC

rewmie wrote: post #129

mcnichol wrote: post #105

Not to rain on the parade here but this is literally a copy-pasta product. Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines...and surprise surprise when you look at where he came from...Ex-Google, Ex-VMW, RabbitMQ... If OP wasn't in and around the source of all these tools above then they were at the very least first cousins to the story. The sales cycle is long, integrations require multiple dimensions of ex…

> Not to rain on the parade here but this is literally a copy-pasta product. More to the point, the product offered no compelling reason to use it, let alone pay for it. Being "fast" is not a selling point. Developers don't want slow pipelines, but that does not mean they want fast pipelines. The speed that the pipeline works is more depending on how the pipeline is setup than the overhead of the pipeline service, an…

Yeah unless I have something that requires really low latency or something I am taking ease of configuration every time.

Re: We built the fastest CI and it failed

#194

Post by mcnichol » Tue, Sep 12, 2023, 9:07 PM UTC

CodeL wrote: post #132

mcnichol wrote: post #113

Earlier quoted context omitted.

This right here. I have found some of the greatest products I have used came from: "I'm working on this project, the tools I currently have are just different forms of a hammer...I need a screwdriver. I built a screwdriver. This screwdriver is the only tool I'll consider when I face this situation." The tools sell because the people doing the work and feeling the pain react strongly while pointing at the incompetent…

Absolutely. It's often those who are in the trenches, dealing with the day-to-day challenges, who recognize the need for better tools. They craft solutions tailored to their specific needs, which often resonate with others facing similar challenges. For instance: - Slack emerged because teams needed a more efficient way to communicate than traditional email chains. It was built as a communication tool for a gaming co…

Couldn't have said it better. I have loved each one of those tools too.

Docker maybe a little more love-hate but I think that has a lot more to do with the politics and salesy side of things and "Who owns what"

Re: We built the fastest CI and it failed

#195

Post by caseyohara » Tue, Sep 12, 2023, 9:14 PM UTC

dpeckett wrote: post #86

reactordev wrote: post #56

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

I'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…

> I'm not sure feature withholding has traditionally worked out well in the developer space.

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.

Re: We built the fastest CI and it failed

#196

Post by fireflash38 » Tue, Sep 12, 2023, 9:20 PM UTC

jnwatson wrote: post #73

alexvitkov wrote: post #4

What does fast CI even mean? CI is an overgrown shell script running your build and telling you when it fails. In general build tooling has gotten so slow that the cost of whatever CI runner relative to it should be nil. If you want fast CI you need fast tsc, clang, rustc, etc... not a faster program that calls exec on them. A bit more on topic, if you're selling CI and your business fails it's because people you're…

The only part of the Earthly pitch that resonated with me was the ability to run the CI locally. When debugging your CI, it is just faster to find problems when you can run on your own box. I have a gnarly GitHub Actions script that took forever to get right because the debug cycle was 10 minutes long.

That's one of my biggest complaints about gitlab-ci. Theres basically no way to debug complex rules without just running it. They've got a way now to simulate for default branch, but that's like bare minimum necessary. No way to simulate based on vars or anything else. And no way to try locally, just gotta fucking send it live.

Re: We built the fastest CI and it failed

#197

Post by justin_oaks » Tue, Sep 12, 2023, 9:20 PM UTC

gabereiser wrote: post #158

justin_oaks wrote: post #145

Earlier quoted context omitted.

I 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/ for details but I'll quote this from it "SSO is a core security requirement for any company with more than five employees"

If you have more than 5 employees, I’m sending you a sales rep to sell SSO to you.

I see, I see. The world isn't fair. We have 5 employees and we want SSO but don't need SSO. So we'll go without it. It's annoying for us but it allows your business to exist because enterprise needs SSO.

Re: We built the fastest CI and it failed

#198

Post by ianwalter » Tue, Sep 12, 2023, 9:24 PM UTC

jnwatson wrote: post #73

alexvitkov wrote: post #4

What does fast CI even mean? CI is an overgrown shell script running your build and telling you when it fails. In general build tooling has gotten so slow that the cost of whatever CI runner relative to it should be nil. If you want fast CI you need fast tsc, clang, rustc, etc... not a faster program that calls exec on them. A bit more on topic, if you're selling CI and your business fails it's because people you're…

The only part of the Earthly pitch that resonated with me was the ability to run the CI locally. When debugging your CI, it is just faster to find problems when you can run on your own box. I have a gnarly GitHub Actions script that took forever to get right because the debug cycle was 10 minutes long.

I feel you on that one. There is also Act (https://github.com/nektos/act) and Dagger.io.

Re: We built the fastest CI and it failed

#199

Post by caloique » Tue, Sep 12, 2023, 9:25 PM UTC

gabereiser wrote: post #114

staunton wrote: post #111

Earlier quoted context omitted.

What's the difference?

plugins, 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.

Co-founder of BoxyHQ here - We've crafted an open-source enterprise SSO because we firmly believe that robust security shouldn't be a privilege limited to large organizations. Ideally, essential enterprise-level features like this should become commonplace for all.

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.

Re: We built the fastest CI and it failed

#200

Post by shepherdjerred » Tue, Sep 12, 2023, 9:26 PM UTC

rewmie wrote: post #179

shepherdjerred wrote: post #84

Earlier quoted context omitted.

> Caching and parallel execution are age old concepts when it comes to CI and every modern build system can do it. It is much harder to set up caching/parallelization with GitHub Actions, Jenkins, Docker, and Make than it is with just Earthly

> It is much harder to set up caching/parallelization with GitHub Actions, Jenkins, Docker, and Make than it is with just Earthly I never used Earthly but I have to call nonsense on this take. Caching and parallelization is a solved problem in GitLab, GitHub, CircleCI, etc. It's so trivial that it's pipelines 101. Caching and parallelization might be easier in Earthly but any improvement over "trivial" is something n…

How do you usually do caching for complex, multi-language projects in this case? How do you guarantee _only_ changed targets are rebuilt when dependencies, like a language version or external library, change?

With Earthly you just... write your Earthfile. You get everything for free. Caching and parallelization _also_ works locally, so I see that speedup in development.