Show HN: Open Fire Serverless CI

[jjdelannoy]

Hello, HN community, I'm really excited to show you Open Fire a serverless CI, how does it work? relying on serverless technologies (firecracker) we can spin up a new VM in less than 200 ms running in a more powerful and newest CPU on the market, just change 1 line of code on your GitHub Actions Workflow and you're up and running! You can see our use case, where we implemented Open Fire in the NextJS repo taking down build time from 1 hour 17 minutes to 26 minutes which is a 66 % of improvement without any engineering effort! [1]

The value of a CI/CD Pipeline is inversely proportional to how long the pipeline takes to run and is a limiting factor for companies to release quickly and often.

For a little bit of background, I have been working in the CI/CD space for the last 9 years in small startups, my own CI/CD startup for mobile games, and big enterprises like PayPal and Binance, and you see the same pattern emerges

In today's life developers are pretty good when they're building new features on their local machines, they have top-edge hardware like MacBooks with tons of core and RAM, but when they push and need to run all CI/CD steps building (multi-arch x86, x86_64, ARM), unit testing, e2e they start to feel very frustrated with the state of the art of their CI/CD pipeline because those will be running on some cloud provider crappy VM that has between 2vCPU 4 GiB to 4 vCPU 8 GiB of RAM, is in that place when they see that their local workflow from 2 minutes build time will become something in the range of 30 minutes to 1 hour! And if you want to migrate to self-hosted CI you will get:

High cost of idle infrastructure waiting to pick up jobs to run. Big queues for accessing the resource to run your pipelines, because everyone is working at the same time frame the high demand overlaps and you can't scale your self-hosted solution that fast without building a team of ~ 20 people. Spent all day installing and updating all the dependencies of the VM and now have to maintain the software packages installed on that machine Companies tend to have 3 different kinds of CI/CD platforms inside them, legacy systems using Jenkins and for new systems GitHub or GitLab, and Buildkite, so you need to create and maintain new runners for all these CI/CD systems, pre-install software for all the build pipelines that may run in your runner Now you have a new platform to develop, update and support every day for the whole company. And the list goes on

[1] - https://open-fire.notion.site/Open-Fire-Serverless-CI-788479...

Thanks for reading, if you want to try us, want to say high, or give us some feedback just ping me jean _at_ open-fire.dev

- Jean

[gregman1]

Oh yes, Openfire is a very popular and reliable XMPP server that has been around for many years. It has a lot of features and is highly customizable, making it a great choice for both small and large chat applications. Openfire is a great choice for anyone looking for a powerful and flexible XMPP server.

And what is this? This is an expensive security breach. How can it be cheaper to have a runner elsewhere? And how hard is to self host a runner?

[jjdelannoy]

hey gregman11,

sorry I didn't your first part about the chat server

> And what is this? This is an expensive security breach.

Great question, From the data perspective, we don't store any kind of information, the logs are retained by GitHub, for each run we issue a registration token and use it for spinning up the runner and it is gone. When the job is finished the VM and the filesystem get deleted, and if your security needs prohibit you from using a SaaS you can use Open Fire in your own infrastructure. We're working on our process of getting the SOC-2

> How can it be cheaper to have a runner elsewhere? And how hard is to self host a runner?

like any engineering problem, self-hosted solutions come with tradeoffs and at the end of the day all depends if the benefits will overcome the effort that you need to put to build, operate and run your solution, in the post, I made a not exhaustive list of thing that you need to do in the self-hosted case if you can pay that price and still get benefits then that is the way to go in your use case, as always the question is the same, why use Dropbox if I can build it myself? Yes, you can build it but is it worth it? or just pay 5 bucks and use it.

Thanks for your questions, I hope you have some more

[breakingcups]

He is saying that the name Openfire is already used and semi-widely known as a realtime chatserver.

[jjdelannoy]

> He is saying that the name Openfire is already used and semi-widely known as a realtime chatserver.

Oh I see thanks for the clarification, the name comes after Firecracker, the framework that we use for microVMs

[mindcrash]

Interesting service, but I can not think a single reason how you could defend better operational performance versus a major security risk when talking to a well versed, battle hardened CSO.

Have you considered a model in which people can license this service and drop it inside their own infrastructure (AWS/Azure/GC or on premise bare metal (Kubernetes, Openshift and friends))?

[jjdelannoy]

Hey mindcrash,

> Have you considered a model in which people can license this service and drop it inside their own infrastructure (AWS/Azure/GC or on premise bare metal (Kubernetes, Openshift and friends))?

Yes, you can run the services inside your own infra (AWS/AZURE/GC and on-prem bare metal), I think I should make that more clear on the page and maybe the post so this is clarified, thanks for the question and feedback!

[theamk]

TL/DR: this is "github runners as a service", and claimed build time improvement appears because they OpenFire gives more CPU/RAM resources that default Github runners. I guess a good idea if you rely on github's default runners... but if you are already using your own runners the benefit may or may not appear. For example hosting runners on EC2 is 2x cheaper, and gives you stuff like shared cache.

Also, "just change 1 line of code" is a bit of exaggeration.. It is more like "sign up with Open Fire, enter your credit card, grant them access to all your git repos, change 1 line of code, don't forget to pay the bills".

[jjdelannoy]

hey theamk

> TL/DR: this is "github runners as a service", and claimed build time improvement appears because they OpenFire gives more CPU/RAM resources that default Github runners. I guess a good idea if you rely on github's default runners... but if you are already using your own runners the benefit may or may not appear. For example hosting runners on EC2 is 2x cheaper, and gives you stuff like shared cache.

I'm happy that you got the idea behind Open Fire "github runners as a service", yes you can run your runners in an EC2 instance, but on top of that, we're taking the burden of running those instances, having all the dependencies updated and working on building new features around the platform like analytics for your pipelines, local caches so the networking stop being a bottleneck for you runners, incremental building, instant checkout and more to come

> Also, "just change 1 line of code" is a bit of exaggeration.. It is more like "sign up with Open Fire, enter your credit card, grant them access to all your git repos, change 1 line of code, don't forget to pay the bills".

yeap, that is pretty much the idea, pretty neat for onboarding a new solution, right?