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

121–130 of 166 posts

Re: How we use HashiCorp Nomad

#121

Post by memexy »

nine_k wrote: post #120
memexy wrote: post #112

Earlier quoted context omitted.

Pulumi has support both for Python and Go along with TypeScript and JavaScript. I never understand when people say operators don't like programming languages. Always seems weird to me that a person that constantly works with computers would prefer a static markup language instead of full programming language for managing the complexity of operating software in production environments. My original comment was about th…

A full programming language gives too much flexibility. In particular, this includes the flexibility allowing to shoot oneself in the foot. A person who constantly works with computers is painfully aware of the people's ability to screw things up by an honest mistake when programming them. The more complex the thing, the easier it is to make a mistake, because human attention is finite. Whenever you can limit the lan…

I can build DSLs (domain specific languages) with programming languages. I can't build DSLs with YAML. And when someone says "You will use YAML because you can't be trusted with a programming languages" then I find that very disrespectful and condescending.

The solution to finite attention isn't less powerful tools. The solution is more powerful tools that augment operators and let them extend their finite attention spans into longer time horizons.

How is your description and viewpoint different from what I just described?

Re: How we use HashiCorp Nomad

#122

Post by shaklee3 »

solatic wrote: post #118

So basically, when CloudFlare was making the decision to adopt Nomad, they had already adopted Consul and had already built in-house a custom scheduler (unimog) for their customer traffic. It's rather disingenuous to compare to Kubernetes-based installations by pointing out that Nomad is a single Go binary that's easy to install, because they're also running Consul and unimog. For what it's worth, kubelet (which sche…

The single binary thing is a tired trope. Kubernetes has had hyperkube for many years, which is a single binary for many years.

But in really, a single binary should be at the bottom of your list of concerns.

Re: How we use HashiCorp Nomad

#123

Post by shaklee3 »

luhn wrote: post #96
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.

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

It would be very odd if he said the opposite, since customers could be spooked. But saying it's going to be around is very different from saying it will always have a lot of resources on it going forward, especially compared to their cash cows of consul and vault.

Re: How we use HashiCorp Nomad

#124

Post by shaklee3 »

toomuchtodo wrote: post #94
closeparen wrote: post #89

Earlier quoted context omitted.

Google. Commoditizing the cloud is their strategy to make GCP relevant.

Question was rhetorical, I still appreciate the effort though.

Not at all. Hashicorp literally pays for all development of nomad. They're the only commits short of a small number of PRs. Kubernetes commits are from a wide array of companies, and Google is only one.

Re: How we use HashiCorp Nomad

#125

Post by topspin »

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.

> Terraform was a huge breath of fresh air after Cloudformation.

Humans shouldn't write CloudFormation templates. If you're doing that here is a important free clue: use CDK.

One advantage of CDK over Terraform is that the 'state' is the CloudFormation stacks themselves as opposed to Terraform's state system. Another is that you get a real programming language (your choice of several) using CDK.

The disadvantage of CDK is that it's AWS only.

Re: How we use HashiCorp Nomad

#126

Post by gen220 »

solatic wrote: post #118

So basically, when CloudFlare was making the decision to adopt Nomad, they had already adopted Consul and had already built in-house a custom scheduler (unimog) for their customer traffic. It's rather disingenuous to compare to Kubernetes-based installations by pointing out that Nomad is a single Go binary that's easy to install, because they're also running Consul and unimog. For what it's worth, kubelet (which sche…

I agree with everything you said, but it’s important to note that the blogpost isn’t comparing nomad to K8s, but describing why nomad makes sense for cloudflare.

From cloudflare’s perspective, K8s is a riskier choice, precisely because it’s large and multifunctional. If Nomad (or Consul) upstream went south, CF would probably be able to maintain it without seriously growing their headcount. And they’d probably be playing the lead role in that ensemble.

If kubernetes upstream went south, the above statements would almost certainly not hold.

For them, picking a stack means picking something they need to stick to, potentially for the next decade or two. When your decisions are made with that long term in focus, the biggest, shiniest, and most exciting community is not always the right choice.

Like you said, it seems like this is the right choice for CF. It’s probably not the right choice for $TECH_STARTUP, for whom pinning the future of business critical infrastructure to Google and RedHat’s stewardship of K8s is the least of their concerns, and that’s OK.

Re: How we use HashiCorp Nomad

#127

Post by shaklee3 »

chucky_z wrote: post #57
candiddevmike wrote: post #25

The biggest hurdle with adopting nomad is the kubernetes ecosystem and related network effects. Things like operators only run on Kubernetes, and they're driving an entirely new paradigm of infrastructure and application management. HashiCorp is doing their best to keep up while supporting standard kube interfaces like CSI/CNI/CRI, but I don't know how they can possibly stay relevant with Kubernetes momentum. In my o…

This is what Nomad is though... It works without their other products and also natively integrates into them. Deploying Vault, Consul, and Nomad gives you a very nice experience. Also with Consul 1.8 and Nomad 0.11 you’ll get Consul Connect with Ingress gateways which solves some of those problems you mentioned.

Nomad uses consul as the kv store, so it doesn't work without their other products.

Re: How we use HashiCorp Nomad

#128

Post by turtlebits »

memexy wrote: post #112
macintux wrote: post #106

Earlier quoted context omitted.

Speaking as a 25-year sys/netadmin who writes a fair bit of code too: nearly anything. I'd rather learn Go than deal with JavaScript. Python would be fine. Elixir would be great (I'd much prefer Erlang but there are only so many miracles I'm allotted in this lifetime). Perl, please.

Pulumi has support both for Python and Go along with TypeScript and JavaScript. I never understand when people say operators don't like programming languages. Always seems weird to me that a person that constantly works with computers would prefer a static markup language instead of full programming language for managing the complexity of operating software in production environments. My original comment was about th…

When I tried it late last year, python was a second class citizen- if you wanted to use all the features, you had to use JS.

Re: How we use HashiCorp Nomad

#129

Post by rayanimesh »

sciurus wrote: post #87
rayanimesh wrote: post #30

Earlier quoted context omitted.

> Helm charts are declarative way of deploying app(s) and their accompanying resources. How do you make helm chart deployment declarative? `helm install` is not declarative (in my understanding `kubectl apply` is declarative and `kubectl create` is not. Let me know if my understanding of declarative is wrong). Thanks.

`helm template | kubectl apply` ?

This is one way of doing declarative using helm, but this doesn't guarntee resource creation order. `helm install` creates resources in order while `kubectl apply` creates in order of alphabetically filename. This may lead to some unexpected issues.

Re: How we use HashiCorp Nomad

#130

Post by memexy »

turtlebits wrote: post #128
memexy wrote: post #112

Earlier quoted context omitted.

Pulumi has support both for Python and Go along with TypeScript and JavaScript. I never understand when people say operators don't like programming languages. Always seems weird to me that a person that constantly works with computers would prefer a static markup language instead of full programming language for managing the complexity of operating software in production environments. My original comment was about th…

When I tried it late last year, python was a second class citizen- if you wanted to use all the features, you had to use JS.

Which features were missing?
Post reply on HN