I don't really see the big value proposition here.
Sure, deploying a single app config is much more awkward than it should be. (Build config: Helm, Jsonnet, Cue, kustomize,...? How to deploy: Gitops/CI, manually , Octopus, Tekton, Argo, ... ?)
But the real difficulty is in connecting different parts of your architecture.
The Getting Started example is extremely flawed: for local development you want a local Postgres and Redis, but in production those will either be provided by the environment (RDS etc) or self-managed,but as a separate deployment because the authorization/lifetime/scaling/upgrade requirements are very different.
Local, staging and production are so diverse that you will always need extensive customization. And there is no way around that, because the needs are fundamentally different.
There definitely is an opportunity to make this easier. It would have to either be done with tooling that has extensive integrations with cloud providers, or with a distinct end to end platform.
funny if you think that you can hire 2-3 FTE engineers for that hardware easily anywhere non-SV. And then (still) can afford to buy a bit of colocation, fibre and compute (200k for 2000 cores + 8 TB memory we got quoted now) - and that still leaves enough that you just buy NetApp for storage...
This exact use case is built into acorn. In the getting starting guide redis/postgres are included in the acorn, but in production those services can easily be overwritten with any k8s service and the embedded containers will not be ran. This is referred to as linking: https://docs.acorn.io/running/linking-acorns The docs only refer to linking acorns but the exact same thing works with linking a k8s service to an acorn.
Sure, deploying a single app config is much more awkward than it should be. (Build config: Helm, Jsonnet, Cue, kustomize,...? How to deploy: Gitops/CI, manually , Octopus, Tekton, Argo, ... ?)
But the real difficulty is in connecting different parts of your architecture.
The Getting Started example is extremely flawed: for local development you want a local Postgres and Redis, but in production those will either be provided by the environment (RDS etc) or self-managed,but as a separate deployment because the authorization/lifetime/scaling/upgrade requirements are very different.
Local, staging and production are so diverse that you will always need extensive customization. And there is no way around that, because the needs are fundamentally different.
There definitely is an opportunity to make this easier. It would have to either be done with tooling that has extensive integrations with cloud providers, or with a distinct end to end platform.
But I don't see how Acorn helps with that all.