Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we use HashiCorp Nomad

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 166 posts

Re: How we use HashiCorp Nomad

#71

Post by p_l »

kraig wrote: post #31
q3k wrote: post #26

Earlier quoted context omitted.

Highly recommend trying Jsonnet (via https://github.com/bitnami/kubecfg and https://github.com/bitnami-labs/kube-libsonnet ) as an alternative. It makes writing Kubernetes manifests much more expressive and integrates better with Git/VCS based workflows. Another language like Dhall or CUE might also work, but I'm not aware of a kubecfg equivalent for them. Jsonnet in general is a pretty damn good configuration langua…

Funny, I thought jsonnet was an even worse experience than templating yaml

The problem with templating YAML is that you're templating text, in a very sensitive to whitespace syntax. By definition, Jsonnet avoids that because it operates on the data structure, not on their stringified representation.

Re: How we use HashiCorp Nomad

#72

Post by AlphaSite »

q3k wrote: post #63
AlphaSite wrote: post #61

Earlier quoted context omitted.

Ive found the whole k14s eco system is pretty great to (ytt + kbld + kapp).

ytt is even more templating-yaml-with-yaml, so it all ends up being a bargain bin Helm. There's no reason to do this over just serializing plain structures into YAML/JSON/...

It avoids the whole set of issues you get with templating yaml with helm since its structure aware.

Also you can actually write pure code libraries in starlark (basically a subset of Python)

Re: How we use HashiCorp Nomad

#73

Post by [deleted] »

pier25 wrote: post #51
jsnell wrote: post #47

Earlier quoted context omitted.

> How are they making a profit They aren't. In Q1 they made a loss of $33M on $91M in revenue.

Oh wow. In fact it seems they have been loosing more and more money over the years. https://finance.yahoo.com/quote/NET/financials/ What are they counting on happening here? Obviously free customers won't switch to paid plans.

[deleted]

Re: How we use HashiCorp Nomad

#74

Post by AaronFriel »

namelosw wrote: post #59
q3k wrote: 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.

There is a tool called Pulumi that does exactly that, and it's excellent.

Re: How we use HashiCorp Nomad

#75

Post by almost_usual »

pier25 wrote: post #51
jsnell wrote: post #47

Earlier quoted context omitted.

> How are they making a profit They aren't. In Q1 they made a loss of $33M on $91M in revenue.

Oh wow. In fact it seems they have been loosing more and more money over the years. https://finance.yahoo.com/quote/NET/financials/ What are they counting on happening here? Obviously free customers won't switch to paid plans.

According to cloudflare.net, their GAAP gross margin was 77% in Q1 which is pretty good. Seems like they spend most on sales, marketing, and r&d.

Re: How we use HashiCorp Nomad

#76

Post by 4636760295 »

otterley wrote: post #65
4636760295 wrote: post #48

Earlier quoted context omitted.

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.

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

#77

Post by rossmohax »

monus wrote: post #70
mleonard wrote: post #42

Earlier quoted context omitted.

Any chance you plan to integrate with Google's Config Connector? It's very similar to crossplane (but gcp specific). https://cloud.google.com/config-connector/docs/overview

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.

Re: How we use HashiCorp Nomad

#78

Post by rossmohax »

schoolornot wrote: post #41

I'm surprised Hashicorp hasn't repositioned this product. Terraform was a huge breath of fresh air after Cloudformation. If you ask me, deploying apps via k8s is even better. Everyone wants a free lunch and for me, momentum + cloud vendor support + ultimately the Nomad Enterprise features that come free with K8s made the choice easy.

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.

Re: How we use HashiCorp Nomad

#79

Post by jeffbee »

dpw wrote: post #66
jeffbee wrote: post #27

"... here is the CPU usage over a day in one of our data centers where each time series represents one machine and the different colors represent different generations of hardware. Unimog keeps all machines processing traffic and at roughly the same CPU utilization." Still a mystery to me why "balancing" has SO MUCH mindshare. This is almost certainly not the optimal strategy for user experience. It is going to be mu…

I'm an engineer at Cloudflare, and I work on Unimog (the system in question). You are right that even balancing of utilization across servers with different hardware is not necessarily the optimal strategy. But keeping faster machines busy while slower machines are idle would not be better. This is because the time to service a request is only partly determined by the time it takes while being processed on a CPU some…

Thanks for the detailed reply. It would be interesting to see your plots of latency broken down by hardware class and plotted as a function of load. I'd be pretty surprised if optimal latency was achieved near idle, since in my experience latency is a U-shape with respect to utilization: bad at 100% but also bad at 0% since it takes time to wake resources that went to sleep.

I'm sure your system has its benefits, I just get triggered by "load balancing" since it is so pervasive while also being a highly misleading and defective metaphor.

Post reply on HN