Hi my name is Gianni and I built another open source replacement for Heroku.
As a developer i fell in love with Heroku many years ago (2012). It was always easy to use, flexible, feature complete an had a very low price tag. But in may 2022 they had this major incident, which blocked all dev teams in our company.
Short after, Bob Wise, announced to discontinue the free tier on their platform.
All this led me, to start my own project and build a Heroku clone for Kubernetes. Yes, I know, there are already a lot other very nice tools in this spot. But I wanted a more developer friendly approach with a nice UI, CLI (Work in progress) and most important Kubernetes native.
Kubernetes has already everything builtin related to scalability(HPA) and resilience. The concept of Operators is similar to the Heroku addons. But a new App should be configured and deployed within minutes not days. Writing stable Helm charts requires a deep understanding of Kubernetes.
Another important part was the workflow: We all want to push our work, wait a moment, and see how our work runs in the cloud. So we want to connect our app with a repository and listen to git pushes and pull-requests.
What is Kubero
https://github.com/kubero-dev/kubero
Kubero is basically an operator with a UI and API. There are 2 Custom resources, which are necessary for your app:
- Pipelines, defines namespaces and git repository connection
- Apps, defines your application and addons
The Kubero UI is a single container application, storing all data in the Kubernetes API. Therefore it is possible to modify all resources directly with the your kubectl without having any conflicts.
Kubero is able to deploy prebuilt images, but the bigger benefit comes with the integrated build pipeline. The deployment has 3 stages: fetch -> build -> run. I call them buildpacks, although no images are build, to keep the analogy to Heroku. Every step has a public image maintained by the publisher. These "buildpacks" are easy customizable and extendable for special requirements. Due to this flexibility it is possible to deploy every code, framework and language, which runs in a single container.
We are a Github company, so we had no issue with the fact, that Heroku connects only to Github. But why not connect to other great repositories? So I added Gitea and soon Gitlab, Bitbucket and OneDev.
Authentication
Same with authentication: there is built in method for very small teams. But it is also possible to use oAuth2 and Github.
Addons
When it comes to Addons, things are getting a bit more complicated: Every Addon has its own complexity when running on a Kubernetes cluster. Some require to deploy several CRD's. Others have finalizers to handle when deleted.
What about more complex application or missing addons? Since it is plain Kubernetes, it possible to use traditional Helm or Operator deployments within your Kubero managed namespace.
Whats next in Kubero
I am currently working on the stability of Kubero. I run it on my local Kind cluster and GKE.
There is a documentation, but far from complete.
A CLI, written in Golang and comparable with Heroku-CLI, is on the way. But this will still take some time.
I will add some more simple addons to the Operator, which are not clustered but easier to handle.
So if you want to use it, I am more than happy help. Don't hesitate to open issues or discussions. Ideas, feature requests and contributions are very welcome.
My next posting (Part 2) will guide you through the Kubero Kubernetes installation. Leave in the comments if you prefer GKE oder Digital Ocean
Top comments (0)