4 ms·
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, Cu
by the_duke 4y ago
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.
- darren0 4y agoThis 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 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. Disclosure: acorn creator.
- jiggawatts 4y agoAt $dayjob someone complained that all of the deployments I had done were inconsistent, and that I wasn’t using repeatable patterns. I said: until you give me two consistent applications I can’t give you consistent patterns! Literally everything is unique and special and has distinct requirements for each environment. The orgs that can get the economies of scale are doing some combination of: - developing everything in house for the same platform in the same langue with the same tooling. - deploying thousands of apps, which means even rare configurations will have dozens of identical examples. - never deploying weird proprietary apps with quirky licensing or crazy pricing models for non-production. - don’t care about the cost of non-production and are happy to overpay for hardware to ensure consistency with production. Even at large government departments none of the above is true. This results in many unique deployments and no cost savings from templating or automation.
- code_biologist 4y agoI think that Heroku was really nice, post-acquisition mismanagement aside. My deployments weren't special but I got a lot done.
- jokethrowaway 4y agoWe always wasted tons of money in cloud providers to keep alive dev and staging in all my jobs. In one company they were spending 400k in aws for non production envs (of a 1.2M budget we committed to spend to get better rates). Tons of microservices, all in node (with three exceptions), a mix of managed databases. Things were consistent across envs (only the number of replicas were different, same containers) but we could have used less envs.
- fock 4y agofunny 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...
- the_duke 4y agoTo be fair: if you have hundreds (or even tens) of developers that extra infra expenditure is relatively meaningless.