6 ms·

Show HN: Open Fire Serverless CI

24 points by jjdelannoy 3y ago

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-7884796e00e84dd082b523f66df04155 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

theamk 3y ago
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 3y ago
  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?
gregman1 3y ago
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?

24 points by jjdelannoy 3y ago

theamk 3y ago

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 3y ago
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?

gregman1 3y ago

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?