HashiConf 2018 Keynote: Nomad Use Cases

Now I want to transition a little bit and spend some time talking about Nomad. Often when we talk about Nomad, we’re also asked about Kubernetes. The question we tend to get is, “Doesn’t Kubernetes obviate the need for Nomad?” I think the way we see it is that, as a company, we are deeply invested in both.

We are integrating all of our tools—Terraform, Consul, Vault—in both Nomad and Kubernetes. Both of these ecosystems are super important to us. But at the same time, we believe that there are use cases that are just a better fit for Nomad, and our users tend to agree. If we look today across the HashiCorp portfolio, Nomad is our fastest-growing tool, quarter over quarter, year over year. You’re going to see talks from many large-scale Nomad users at the conference today talking about use cases where they also felt that Nomad was the best fit for their job.

Simple scheduler

When we talk about use cases for Nomad, there are 3 categories we tend to see. One is looking at: What if I just want a container scheduler, not a container platform? I want to be able to run my containers, but compose it with Consul for service discovery, Vault for secrets management, other tooling I have for load balancing. If I have these existing investments and I just want a scheduler, not a full platform with opinions, then that’s a great fit for Nomad because that’s all Nomad is: It’s a scheduler.

Scheduling non-containerized workloads

Then there’s the use case of applications that are non-containerized. These are Java applications, there may be traditional Windows applications, there are statically compiled C++ binaries. They’re things that we haven’t put in containers and maybe don’t want to invest in putting in containers, but how do we get some of the benefits of the self-service automation and all the monitoring and health checking and recovery capabilities that scheduler affords us? For those kinds of workloads, Nomad’s also a great fit because we can just hand it a Java JAR and say, “Go run this in an isolated environment.”

Batch and high-performance computing

The last major use case for us that we see is batch and high-performance computing. Nomad is designed to be able to handle thousands of scheduling events per second, tens of thousands of cores under management. So when we have these use cases of very high throughput, bursty traffic, then Nomad is a great fit for that. It’s designed for this very ephemeral infrastructure and for high-scale scheduling activity. There are plenty of use cases where we feel like these technologies are complementary to one another. Within the last year, we have spent a lot of time developing out Nomad. We’ve added a ton of new features. There are going to be some great sessions here that I encourage you to check out.

A few that I want to highlight: Things like cloud auto-discovery. This makes it really easy to bootstrap a Nomad cluster, give it a few flags, and it’ll automatically form a cluster. Advanced node draining makes it easy as operators for us to go in and say, “These 50 machines, take them out of service. You have 4 hours,” and to drain the workload gracefully. There’s much better node event information and telemetry that lets us understand what’s happening inside of our systems to understand, “Why are things rescheduling? What’s going on with the cluster itself?” A revamped UI, a revamped CLI, lots more polish that’s been making the system easier to use at scale.