Live data from Hacker News

How we use HashiCorp Nomad

blog.cloudflare.com

91–100 of 166 posts

Re: How we use HashiCorp Nomad

#91
post #12

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.

json is already valid yaml

Re: How we use HashiCorp Nomad

#92
post #13

Off 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)?

They have paid services an despite what cloud providers and CDNs might have you believe, bandwidth is exceedingly cheap.

Re: How we use HashiCorp Nomad

#93

Earlier 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.

Seems like some projects survive their parent company abandoning them like illumos (successor to opensolaris). It's not common, but also not impossible.

Re: How we use HashiCorp Nomad

#95
post #4

Earlier 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

Autoscaling is in Tech Preview as of March: https://www.hashicorp.com/blog/hashicorp-nomad-autoscaling-t...

Disclaimer: I work at HashiCorp in Product Management.

Re: How we use HashiCorp Nomad

#96

Earlier 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.

The CEO addressed a similar comment on Twitter recently. From what he's saying, it seems Hashicorp is standing by Nomad for the foreseeable future. https://twitter.com/mitchellh/status/1247581788706197504

Re: How we use HashiCorp Nomad

#97
post #86

I 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.

I'm curious if you tried the new autoscaler [1] that is in Tech Preview? Is there something it's missing for your scenarios?

[1] https://www.hashicorp.com/blog/hashicorp-nomad-autoscaling-t...

Re: How we use HashiCorp Nomad

#98
post #81

Earlier 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.

What language would be good for operators if not JavaScript?

Re: How we use HashiCorp Nomad

#99
post #81

Earlier 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.

Pulumi does not require JavaScript at all - it is one of a range of options, including JavaScript, TypeScript, Python, Go, C# and F# (currently).

Disclaimer: I worked on Terraform at HashiCorp and am a contributor to Pulumi also.

Re: How we use HashiCorp Nomad

#100
post #70

Earlier 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.

Oh, thanks for letting me know!
Post reply on HN