piku VS 5-minute-production-app

I like it. I wrote Piku (https://github.com/piku/piku) with much the same interest in fixing some of my pains, so I get where you're coming from with this. Will drop it into one of my current projects to build ESP32 binaries :)

I never had any serious issue with SD cards since the Pi 2B (and I've kept Pis running for years).

Anyway, for those wanting to deploy more generic apps, that is why I initially wrote https://github.com/piku/piku - you still have to flash the OS (and rpi-imager does that with sane defaults these days), but once you're done you have Heroku-like deployments for any language runtime you install on the Pi.

I also have https://github.com/rcarmo/ground-init, a cloud-init like shim that simplifies setting up machines (I'm a big fan of cloud-init, but since Raspbian doesn't support it and Ubuntu on ARM requires some fiddling to make it work I decided it wasn't too hard to roll my own).

(I probably should look into glueing that into rpi-imager, but there is are only so many hours in the day...)

I automated that away a long time ago: https://github.com/piku/piku/blob/master/piku.py#L814

Piku https://github.com/piku/piku

So, stupid question: why couldn't I just use the 'baremetal' OS provided by Hetzner, install Postgres, Redis & node, create a separate db for each app, and run each app with https://github.com/piku/piku on a different port? For backups, I'll setup crontab to dump dbs locally and to S3.

piku?

Piku https://github.com/piku/piku

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.