4 ms·
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 s
by linuxdude314 4y ago
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?
- V99 4y ago> 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. These are CLI shorthands. There is a canonical expanded-out object that you would use if you were scripting something or talking to the API. > 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. Of course the same basic concepts of what to run, where to store output and how to take input are needed to describe computing. But there's two ways to run things ("containers" stay running, "jobs" finish) instead of 8 to choose from (bare pod, deployment, replicationcontroller, replicaset, daemonset, statefulset, cronjob, job) with all slightly varying syntaxes. The args/volumes/secrets aren't just things that will be created, but also documentation and first-class objects that can be configured/overridden by the consumer of the Acorn. Without you adding dozens of lines of values.yaml and golang template soup to a helm chart to allow every possible configuration a user might want (and never quite the same way in two different helm charts from 2 different people). You can create an image with reasonable defaults to work for dev/toying around on a laptop; run a local database, generate the secret for it automatically, etc. With the tools needed to ship and run that same artifact in production but pointed at a real DB in RDS. Packaged up as one OCI image so there's one artifact to manage from one source, instead of a helm chart + n images from n containers from n registries. (Acorn cofounder)
- deleted 4y ago[deleted]