How we use HashiCorp Nomad • Hacker News Board

Re: How we use HashiCorp Nomad

#111

Post by halbritt » Sun, Jun 07, 2020, 2:43 AM UTC

4636760295 wrote: post #3

I worked at a hedge fund that also used nomad. The problem, however, is not how well it scales or whatever, but the fact that all the accompanying deployment info and literature is for kubernetes, and k8s has far more features. I like the quality of products from HashiCorp, but k8s is far, far, ahead of where nomad is. What I really want is better integration for Terraform and kubernetes. The current TF k8s support l…

Why would you want TF in k8s? That hurts my soul.

Isn't exactly declarative, nor really imperative, mostly but not entirely idempotent, and worst of all, it has faux-state that may or may not reflect the actual state of the services.

I used to love Terraform, but it broke my heart. Now we're done.

Re: How we use HashiCorp Nomad

#112

Post by memexy » Sun, Jun 07, 2020, 2:58 AM UTC

macintux wrote: post #106

memexy wrote: post #98

Earlier quoted context omitted.

What language would be good for operators if not JavaScript?

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 this attitude. I personally think programming languages are much better than markup languages for almost everything. If you are presenting static content then markup languages are fine but if you're doing anything more than presenting static content then YAML just makes no sense.

Re: How we use HashiCorp Nomad

#113

Post by stitched2gethr » Sun, Jun 07, 2020, 3:02 AM UTC

aprdm wrote: post #105

Do people that aren't cloudflare scale really see the need for kubernetes and/or Nomad? Of the two Nomad seems much more sane because it does one thing only and is much simpler to manage and deploy. That said, having have used it, we are mostly moving away from it. Consul + Docker/Docker-compose with systemd in "a service per vm" model has proved much easier to administrate to our scale (couple of datacenters, ~1k VM…

From my personal experience, yes, but not just for scale. I've used Kubernetes in a 300k person organization and now in a 35 person organization. Kubernetes isn't the simplest solution, but it's just reliability in a box. You can control the network, and the servers, and the load balancing all through the API which means for most things I can install a fully clustered solution with a handful of commands. Set the number of instances I want to run and forget the whole thing exists. Suddenly I'm cloud agnostic by default and the underlying K8s management is handled by the cloud provider.

In the 300k person org it was for scale and reliability. In the 35 person org it's so that 1 guy can manage everything without trying.

Re: How we use HashiCorp Nomad

#114

Post by throwaway2048 » Sun, Jun 07, 2020, 3:17 AM UTC

SahAssar wrote: post #93

4636760295 wrote: post #76

Earlier quoted context omitted.

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.

its hard to say illumos is in good shape compared to when opensolaris was being worked on by Sun, or Joyent however.

Re: How we use HashiCorp Nomad

#115

Post by jen20 » Sun, Jun 07, 2020, 3:33 AM UTC

gavinray wrote: post #102

jen20 wrote: post #99

Earlier quoted context omitted.

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.

Pulumi is so good (even if it is just typed-SDK's over Terraform). Only sane approach to IaC IMO, using an actual programming language with types and IDE integration. Really dig using with it Cloud Run.

It’s also not typed SDKs over Terraform. The best Pulumi providers are native and offer a much richer experience than the wrapped Terraform providers (see the Kubernetes support for example). I for one look forward to those rolling out across the board!

Re: How we use HashiCorp Nomad

#116

Post by jen20 » Sun, Jun 07, 2020, 3:35 AM UTC

MuffinFlavored wrote: post #108

What can Nomad do that Terraform can't? I'm pretty sure you can blue-green rolling deploy services inside of Docker containers with Terraform too.

They’re completely different classes of tool - Nomad is a runtime component, Terraform is not.

Re: How we use HashiCorp Nomad

#117

Post by mushbino » Sun, Jun 07, 2020, 4:15 AM UTC

ridv wrote: post #103

luhn wrote: post #96

Earlier quoted context omitted.

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

Nit: Mitchell is their CTO. Dave McJannet is their CEO. (source: https://www.hashicorp.com/about/ )

Micro-nit: Mitchell is Co-CTO w/ Armon being the other

Re: How we use HashiCorp Nomad

#118

Post by solatic » Sun, Jun 07, 2020, 4:17 AM UTC

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 schedules jobs, like Nomad) is also a single Go binary that's easy to install, as is kube-proxy (which helps services running on a node to send traffic to the right node, so, roughly analogous to Consul).

If anything, the author practically makes the case against Nomad. Practically speaking, the only reason why CloudFlare adopted Nomad is because the stars aligned on their stack. Most companies will actually reduce complexity by adopting Kubernetes instead, compared to running two different schedulers for jobs and externally-managed service discovery.

Re: How we use HashiCorp Nomad

#119

Post by gavinray » Sun, Jun 07, 2020, 4:17 AM UTC

jen20 wrote: post #115

gavinray wrote: post #102

Earlier quoted context omitted.

Pulumi is so good (even if it is just typed-SDK's over Terraform). Only sane approach to IaC IMO, using an actual programming language with types and IDE integration. Really dig using with it Cloud Run.

It’s also not typed SDKs over Terraform. The best Pulumi providers are native and offer a much richer experience than the wrapped Terraform providers (see the Kubernetes support for example). I for one look forward to those rolling out across the board!

I actually have one burning question if you don't mind answering:

Pulumi has two different k8s modules, the standard one (pulumi-kubernetes) and "kubernetes-x" which has a much nicer API that reduces boilerplate:

https://github.com/pulumi/pulumi-kubernetesx

The second one doesn't seem to be used in the Pulumi tutorial content and has less stars/recognition.

Are these interchangeable? If so, why not use @pulumi/kubernetesx instead of the standard k8s module everywhere?

Re: How we use HashiCorp Nomad

#120

Post by nine_k » Sun, Jun 07, 2020, 4:30 AM UTC

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…

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 language to the task at hand, and build in guard rails that would prevent you from doing things you should not be doing, it's usually a productivity win, even if it precludes implementation of 3% of some most advanced and complex solutions. Reliability and simplicity go hand in hand, and reliability is often the thing devops people value very highly.