5-minute-production-app VS cluster-api

Author here.

This post doesn't live up to its title, I'm sorry about that.

The title should have been 'We are building a better Heroku FOR PRODUCTION APPS' (we'll add the 'for production apps' to the title)

It should have emphasized the _building_ part, we're just starting. The current 5 minute production app doesn't hold a candle to Heroku at the moment.

It should have made it clear the goals is to improve the speed with which you can configure a production app, not a development app. Development apps on Heroku are already close to perfect. The examples in this post are contrived since it talks about a development app, as rightly called out by Heroku people https://twitter.com/johnbeynon/status/1374306499426652161

It should have gone into why hyper clouds might be preferable https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

It should have talked about state, we made a small improvement in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request... but we should have done the planned work in https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/11137 and made one post out of it.

Disclaimer, I am a CNCF Ambassador (voluntary) - so it's in my interest to promote CNCF projects like Kubernetes.

It seems like a good time to mention my blog post from last year "Then he asked me “Is Kubernetes right for us?" -> https://alexellisuk.medium.com/then-he-asked-me-is-kubernete...

Some of the feedback I've had so far is that it was refreshing to get "permission" to consider alternatives vs. the current hype. I use K8s and K3s quite broadly myself, but increasingly see consulting prospects and customers who are not comfortable to make the leap, but are very happy on managed services with their chosen vendor - Azure / AWS / GCP.

GitLab recently released a bunch of terraform to show you how to run side projects in the free tier of a cloud - https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

The OpenFaaS project again is very coupled to Kubernetes, making it easier to use and more reliable is important to the community and project's future. However, we created a version called faasd that works more like docker-compose. It's received much more traction than we expected and companies and individuals are putting it into production. It does't have clustering, and supports only 1 replica per function, so it's surprising.

I'll keep doing my bit to promote solutions that make K8s easier to understand like K3s (see also k3sup.dev) and to look into alternatives. But as you will see in my blog post - I don't think it's right to assume Kubernetes is the right solution for every team, and every project, without first talking about the problem being solved.

Less than five minutes. I worked closely with GitLab co-founders over the past 7 weeks, and we built the [Five Minute Production](https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template/-/blob/master/README.md) project that generates AWS infra for webapps with minimal fuss.

In this blog post, we will demonstrate how easy and fast it is to deploy Sveltos on an RKE2 cluster with the help of ArgoCD, register two RKE2 Cluster API (CAPI) clusters and create a ClusterProfile to deploy Prometheus and Grafana Helm charts down the managed CAPI clusters.

4. Having moved to a container orchestrator, all of my nodes are immutable. Hardware and VM instances _can_ be born magically into existence. Nearly all infra providers support [cluster-api](https://cluster-api.sigs.k8s.io/). Network infrastructure can now be managed with TF, so I go that route.

## Linux curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.4.4/clusterctl-linux-amd64 -o clusterctl sudo install -o root -g root -m 0755 clusterctl /usr/local/bin/clusterctl ## Mac brew install clusterctl

Did you ever try CAPI? https://github.com/kubernetes-sigs/cluster-api

You might find interesting the capi-rancher-import k8s operator we use in Sylva, it would adopt in Rancher server the Cluster API created k8s clusters (with bootstrap provider kubeadm or even rke2 - you can lookup CAPBR for the latter). I understand your clusters are not created by Cluster API, so if you could move the workloads/resources to new clusters created by Cluster API, this can come handy. (Adoption of non-CAPI clusters into CAPI is not yet a standard practice, more in https://github.com/kubernetes-sigs/cluster-api/issues/7776)

Most of the comments have mentioned older tools like kubespray, Ansible, Rancher etc. I would suggest the cloud native way using ClusterAPI or use a tool that relies on ClusterAPI in the backend called Talos

Cluster API

Sveltos is a powerful open source project that makes managing Kubernetes add-ons a breeze. It automatically discovers ClusterAPI powered clusters and allows you to easily register any other cluster (like GKE). Then, it seamlessly manages Kubernetes add-ons across all your clusters.