Earlier quoted context omitted.
Helm, however, is objectively terrible with its yaml-based templating language and zero practical modularity.
Sometimes I even wish they could embed a JavaScript interpreter... After all, YAML is almost equivalent to JSON, which the perfect templating language for JSON is -- JavaScript tbh. Or people have to keep inventing half baked things.
How we use HashiCorp Nomad
91–100 of 166 posts
Re: How we use HashiCorp Nomad
#92Off topic but... I've always wondered how Cloudflare can not charge for the bandwidth. Even the free plan is super generous (CDN, SSL, etc). How are they making a profit when AFAIK all other CDNs charge you for the bandwidth (and I assume they have to pay for to their providers)?
Re: How we use HashiCorp Nomad
#93Earlier quoted context omitted.
Nomad is open source (or, at least, a significant subset of it is). Anyone is able to continue to improve it, even if Hashicorp is no longer paying people to work on it.
I used to do sales for an enterprise "open source" software product, so I get it, but the truth is as soon as someone stops paying people to keep the project going it will die.
Re: How we use HashiCorp Nomad
#94Re: How we use HashiCorp Nomad
#95Earlier quoted context omitted.
Which features is Nomad missing? Feature count comparisons are meaningless unless the features are tied to actual important use cases. Lots of software is encrusted with rarely used features that just add complexity.
A few long-standing feature requests I've noticed a lot: * No autoscaling * Can't reserve entire CPU core: https://github.com/hashicorp/nomad/issues/289 * No way to run jobs sequentially: https://github.com/hashicorp/nomad/issues/419
Disclaimer: I work at HashiCorp in Product Management.
Re: How we use HashiCorp Nomad
#96Earlier quoted context omitted.
"Kubernetes but with less stuff" is a valuable niche that I'm glad someone is targeting.
That's a fair point, I guess it depends on your use case. The risk, however, is that the powers that be at HashiCorp one day decide to abandon Nomad once they realize it will never be a profit centre for them.
Re: How we use HashiCorp Nomad
#97I love nomad and architected a large system that used it for several years. We are finally moving away from it, however, because of its lack of native support for autoscaling. I know there are third party solutions for it, but that doesn't work for us. I suspect a large number of k8s users could use nomad instead with way less overhead.
[1] https://www.hashicorp.com/blog/hashicorp-nomad-autoscaling-t...
Re: How we use HashiCorp Nomad
#98Earlier quoted context omitted.
TF can be often suffocating still. Pulumi runs circles around it, when it comes to user experience in writing complex, modular, composable and reusable configurations.
Except now you have to deal with javascript. It's hard enough to turn some operators towards an IaC approach, but throwing Javascript at them isn't going to help.
Re: How we use HashiCorp Nomad
#99Earlier quoted context omitted.
TF can be often suffocating still. Pulumi runs circles around it, when it comes to user experience in writing complex, modular, composable and reusable configurations.
Except now you have to deal with javascript. It's hard enough to turn some operators towards an IaC approach, but throwing Javascript at them isn't going to help.
Disclaimer: I worked on Terraform at HashiCorp and am a contributor to Pulumi also.
Re: How we use HashiCorp Nomad
#100Earlier quoted context omitted.
I think that'd be a bit challenging because Config Connector is highly opinionated, for example, Kubernetes Namespace corresponds to GCP project. Though it might be enabled to be used as part of a Composition when we support namespaced CRs to be used as composition member.
Every config connector resource can be annotated with the project for GCP resource to be created in. Namespece to GCP project mapping is encouraged, but not enforced, you are still free to create resources in multiple projects from a single namespace as well as in a single project from multiple namespaces.