3 ms·
Seemingly unpopular opinion, but coming from more ops related background, I always appreciate configurable deployments. If I want to test-deploy the thing on my
by friendzis 2y ago
Seemingly unpopular opinion, but coming from more ops related background, I always appreciate configurable deployments. If I want to test-deploy the thing on my own workstation I hope the defaults will work, but in a corporate environment I may not only want, but actually require flexibility.
Infra, ops and dev intersect at different points in different orgs. Some may provide custom kubernetes operator and abstract the service away, some orgs may provide certain "managed" building blocks, e.g. postgres instance. Some will give you a VM and and iscsi volume. Some will allocate credits in cloud platform.
Having the ability to plug preexisting service into the deployment is an advantage in my book.
- danpalmer 2y agoIt's not an unpopular opinion, but as far as I can tell Huly is not a configurable deployment. It's a strict set of dependencies. If you can't run Mongo, Elastic, and a bunch of other bits, then you can't run it. The more pieces they add the more likely any one potential user can't run it. The options are either to minimise the dependencies (the approach I advocated for in my parent comment), or to maximise the flexibility of those dependencies, like requiring a generic-SQL database rather than Mongo, requiring an S3 compatible object store rather than whatever they picked. This is however far more work.
- d0gsg0w00f 2y agoThis is clearly a case where Huly's primary focus is their complex SaaS option. The self-host option has to follow core or it bitrots. I'm fine with this trade-off personally.