The New Stack had a writeup that actually covered it's usage nicely. It looks like it's a pretty fast/convenient way to package apps & declare some dependencies (DBs) qyickly, & get a nice managed namespace of everything one would expect.
https://thenewstack.io/acorn-a-lightweight-portable-paas-for...
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.
But I don't see how Acorn helps with that all.
I have good evidence to believe one of the PaaS we use at work uses K8s for deployments under the hood but it’s not like that provides any portability to us; and they certainly don’t advertise that. How is this any different? I guess my point is that at this level of abstraction k8s seems almost irrelevant.
A proprietary wrapper around a few k8s objects? Where's the big win?
It's not clear what problem Acorn is solving.
I don't understand why everyone is using their own OCI compatible image formats for PaaS, it seems anti user, and likely decreases portability. Adding your own image format over complicates this when you can rely on docker images or nixpacks or whatever. Having 10 competing image formats is anything but useful.
What does the following refer to in their GitHub readme?
> Caution: Consuming this project can expose you to chemicals, which are known to the State of California to cause cancer and birth defects or other reproductive harm.
https://github.com/acorn-io/acorn/blob/8a474b9e593956c2ad56b...
Yes Kubernetes YAMLs are a PITA. But you can just wrap them in a scripting language like Ruby that makes it easy to create a DSL.
[0]: https://www.brightbox.com/blog/2020/02/12/rubynetes-kubernet...
Use a language rather than a tool if you need the flexibility.
Is it a copy of https://github.com/theketchio/ketch ?
How does this compare against https://porter.run/ ?
Looks nice and it's open source. What is your business model?
Oh dear, also the name of a JS parser https://github.com/acornjs/acorn
Rio undead?
How does Rancher have any money left?
Acornfiles? I feel like when you introduce a new config format, a common expectation will be having a prominent "Why Acornfiles?" page where you explain why this new format is necessary. Without it, I personally groan and look away. With it, you are still wasting time explaining your config format, time that should be spent explaining the benefits of the larger system you're offering.
Overall it looks pretty hacked together. For instance, instead of using an object model or tuples to represent ports, acorn uses a list of strings where each string holds multiple delimited values.
Ex. ports: [ "80/http", "8080/http", ]
While a stylistic choice, it also makes it a PITA for others to write parsers for their DSL, and generally isn’t as readable as say the vanilla Kubernetes port model.
Next let’s take a look at the level of abstraction provided. Typically with a PaaS you are at a higher level of abstraction than an IaaS platform.
args: { // defines arguments the consumer can provide } profiles: { // defines a set of default arguments for different deployment types } containers: { // defines the containers to run the application } volumes: { // defines persistent storage volumes for the containers to consume } jobs: { // defines tasks to run on changes or via cron } acorns: { // other Acorn applications that need to be deployed with your app (databases, etc.) } secrets: { // defines secret bits of data that are automatically generated or passed by the user } localData: { // default data and configuration variables }
Looking at the list above of what we need (or can) provide for a deployment, it doesn’t seem we are at any higher a level of abstraction than we are when just using Kubernetes.
It’s incredibly easy to have the same artifact deployed in multiple environments using Kubernetes with no additional tooling.
So all this leaves me with the question, why?
Good luck to them and all that but given the significant legacy of the Acorn name in computing history, they could maybe have dug deeper for a title.
That has been posted three times in the last 30 days. One time with comments: https://news.ycombinator.com/item?id=32331892
Two thoughts when reading the Acornfile:
1. Ugh, yet another DSL. Why not just use Lua?
2. The config file still looks complicated. What makes this better than writing your own Helm chart or Docker Compose?
This is nice.
But the real problem is Kubernetes. What do I mean by that? I mean the setup, care and feeding of K8s.
It's nice to have a tool that you can quickly push stuff to K8s. There are other tools out there that do that too.
The thing is this, the majority of people who use K8s, don't need to use K8s. Those people could easily get by with something like Dokku or even just start containers by hand to deploy.
Acorn is just perpetuation the cycle of recommending the over-engineering of K8s for small workloads and small companies that really and truly don't need it.
I'll say it again people. Spin up a few giant servers and call it a day. Save thousands of dollars in hosting costs and tens of thousands if not hundreds of thousands of dollars in engineer hiring costs. Bonus side effect? 10x performance than a passel of wimpy VPS's.
P.S. I'm coming from using K8s in both Google Cloud and on Bare Metal.