Hacker News new | ask | show | jobs
by whalesalad 1111 days ago
Huh, I have the opposite. There is a huge hole in the ecosystem between Fly.io/Heroku and managed Kubernetes.

If you want to deploy a handful of services, databases, caches, queues, inside of a single private network, with load balancing, security, deployments, per-environment (versioned) config, rollbacks, blue/green deploys, etc... it is not trivial. It's easy for me because I have been building this stuff for the last 15 years, but I also get sick and tired of reinventing the wheel all the time.

My team and I built an internal PaaS on Kube to power Farmlogs back in 2016. This experience had a tough initial learning curve, but ultimately paid off bigtime and gave me the assurance that yes kubernetes can absolutely work in production at scale reliably. But it's tough to grok and use correctly. So I've been wanting to solve the aforementioned problem for a while now.

This product honestly looks like the perfect answer. My only hesitation would be longevity ie what happens if this company fails. Ultimately I want them to manage the thing, but I also want a reproducible artifact of my entire system so that if they get hit by a bus my business isn't fucked.

It checks all the boxes for me: heroku-style ui to enable devs from different levels of experience to contribute and have visibility into the system but I bring my own AWS account and therefore ultimately have sudo access to my network and how this env might interact with other envs.

1 comments

Appreciate the feedback! That was the experience we had as well - there wasn't anything in between render/heroku/fly.io and EKS and why we started Nucleus. We're not going out of business anytime soon but its a very fair concern and there's ways that we can help mitigate that i.e. offering an on-prem version, exporting terraform files, etc. Working towards this but it will take some time.
> exporting terraform files

This is what I came here to ask about. Managing my infrastructure only through a UI makes me nervous. I much prefer having the source of truth for configuration be in version control. Having said that, I do love what you've launched here, and totally get the value proposition. If I could get that value without sacrificing infra-as-code, this would really speak to me.

A way this could potentially work (albeit with a pretty significant bump in complexity I think) would be for the UI to sync with an IaC repo. That is, changes through the UI would commit to the repo and need to be applied (either automatically or on-demand), and changes to the repo outside the UI would need to be sync'd into the UI.

Just a thought! Nice work on this!