Nomad Fireside Chat with Mitchell & Armon: The Path to Nomad 1.0

Transcript

Mitchell Hashimoto: Welcome to the Nomad product keynote. I'm joined here with Armon, and in a moment, Yishan's going to join us to talk more about what we have in store for Nomad later this year.

To start, I want to talk about how Nomad has been on this journey for many years towards a 1.0 — and talk about what a 1.0 means for HashiCorp. A lot of our community expects us to release 1.0s much sooner than we generally do. The average time for us to get to a 1.0 for our products is around four years, maybe. Well, Nomad was released in 2015, so it's very on-topic to talk about what 1.0 looks like for Nomad today.

What makes a HashiCorp 1.0 Product?

To do that, I want us first to talk about what is important in a 1.0 for us at HashiCorp generally across any of our products. We look for a number of different things when we talk about a 1.0. One of the first things is enough adoption and stability in that adoption. So people are using it for various use cases, those use cases stable, and they're use cases that we do want to support for the product.

We look for architectural stability as well. Is the product’s core design in a shape that we could support for years and years to come with limited breaking changes and feel comfortable doing that?

In addition, the user experience of our products is super important. That's something we've always taken to heart from a 0.1 for all our products. Even if the product's super stable and used for various use cases, if we feel we could smooth out some rough edges and make things more enjoyable to use, we like to do that ahead of time. So that when we release a 1.0 and many users come and join the community they have a good experience out of the box.

A lot of these things we look for at 1.0 are hard to define — they're hard to measure. A lot of people say "You reached them years ago," or "We're not quite there yet." As a team, we just ask ourselves with every release, are we ready to be 1.0 yet, and what does it look like to be 1.0? We're getting there with Nomad — and Yishan is going to talk more about that. Armon, do you have anything to add about 1.0s?

Armon Dadgar: No, that largely covers it. The other piece that's sometimes hard for us to articulate is that often we might have an idea of the use cases for the product, but those use cases might not yet be well-defined or polished in the product itself.

HashiCorp 1.0 Products and “The Big Vision”

I think what's tough is if you're only using the product for that happy path and the use cases that we do well support, you might say this already feels like a 1.0 product. What's HashiCorp waiting for? Sometimes there are these other use cases that we'll say you know what? When we first imagined this product, we thought about use cases A, B, and C as being core to it. We've nailed A and B. Those are already at a 1.0 stage, but C is not quite there. Let's flesh that out before we consider the product truly a 1.0.

Sometimes that's a little bit tough from the community aspect because you're using the tool, you feel like I've been using it in production, it does task A really well. But we have this bigger vision for a lot of our products, and that's why it takes them many years to get there.

Mitchell Hashimoto: We've talked about this before. Even though a product is at 1.0, it doesn't mean that it's not being used heavily in production or that we support it for production. Nomad is a great example of a product that we've sold to enterprises, sold support contracts alongside it, sold enterprise features alongside of it for production use cases for many years — yet it's not 1.0; it’s direction ready. I think we view a 1.0 as a commitment to our community that we've reached a very important milestone that we're committed to with a product.

Armon Dadgar: That point you made is also a good one. Part of that commitment is that we won't have breaking changes immediately after around those core use cases. The other key aspect is if we anticipate the need to introduce breaking changes, let's do that before we ship it and call it a 1.0. So when we get there, there's the stronger promise of forward compatibility. That's a good point around that notion of “What's the commitment we're making?”

Mitchell Hashimoto: Yep, and a lot of it is around staging the product for changes we want to make after 1.0 in a way where we don't need to make breaking changes to get there.

Adding Auto-Scaling to Nomad before 1.0

A good example with Nomad is introducing the auto-scaling capability that we had in the past couple of releases. We weren't quite sure if that auto-scaling capability required breaking changes to Nomad. We wanted to get the autoscaler in before 1.0, even though we didn't expect the auto-scaling functionality to reach 1.0 quality alongside Nomad.

Armon Dadgar: That's a great example of the type of use case where we always imagine auto-scaling would be a part of the original vision for the 1.0 product. You might say you didn't need the autoscaler — that we could have gone 1.0 with earlier release. But that's a great example of a piece that we always imagined being part of a 1.0 deliverable.

The Tao of HashiCorp and the HashiCorp Principles

Mitchell Hashimoto: As a company, we publish a lot of principles. We have something called The Tao, and we have something called the HashiCorp Principles that both define how we build our products, as well as how we interact with each other in our community — it's worth talking about if you would, Armon, how we look at these principles and The Tao and how they impact our product development with Nomad in particular.

Armon Dadgar: We talk a lot about both these documents. They guide a lot of the design and the behavior at HashiCorp. When we talk about The Tao of HashiCorp, it's the core design ethos. How do we think about the problem itself? Whether it's this notion of workflow over technology; meaning really what Nomad cares about is that workflow. When you say defining a job file, the CLI interaction, the UI interaction. All of that workflow is kind of the same, whether you're deploying a Docker container to the cloud or whether you're deploying a VM image on-premise. That technology — the underlying piece of it is pluggable — but the workflow on top is what we focus on; the consistent layer.

There are a bunch of other elements within The Tao. The Tao focuses on our design ethos, which is common across all of the tools. The principles is a different one, which is also interesting. The Principles of HashiCorp are meant to drive less technical design decisions and more human decision-making — how do we act as people, and how do our processes reflect that internally.

Aligning Principles to 1.0 Products

There are a few different pieces when we talk about how the HashiCorp principles apply to a 1.0 or apply to a product like Nomad. Not all of them apply, but certainly, some of them do.

Vision

One big piece of it is vision. When we talk about vision as part of The Principles of HashiCorp, the idea is if we don't have a destination in mind — if we don't have a clear picture of where we're going as a group — then it's hard to rally around. Especially if you talk about a large group, including our customers, our community, our internal developers, etc. How do we rally everyone around a common vision of where the product is going? Part of that is the destination setting. Having that vision of when we get to a 1.0, this includes A, B, and C — let’s say — as core use cases. That’s piece one.

Pragmatism

A second piece of it is pragmatism. We had to be super practical when we started Nomad six years ago. You have to be pragmatic and say, great. You have this grand vision for what the product should be when it gets to a 1.0. Practically speaking, it's going to take you years and years of development to achieve that. So, where can we start to add value right away? Where can we be pragmatic about evolving and growing the product over time to get to that 1.0, but realizing that it takes the fullness of time to get there?

Integrity

This has been true with all of our products. This ties back into Mitchell's point that HashiCorp tends to be unconventional in how long it takes us to get to a 1.0. We pride ourselves on it means something. We see a lot of folks in the ecosystem that treat a 1.0 as the software compilers call it 1.0. Versus for us, this speaks to our principle of integrity.

Does it show and demonstrate intellectual integrity if we call a product a 1.0 if we don't feel like it's robust; if we don't feel like the architecture is stable — if we don't think there aren't future breaking changes? Integrity is also a key part of it — an intellectual integrity and honesty. If — no this thing isn't a 1.0 yet — here's the bar, here's how we're going to get there pragmatically.

Reflection

Reflection is a huge part of our principles, which is how do we actively challenge ourselves? And to Mitchell's point — with every release — we ask ourselves, is this 1.0 ready? If not, what else do we need to do to incrementally get there? But we have to actively reflect and ask ourselves, are we ready? Are we ready? Are we ready? If not, what should we do differently? Where do we need to focus in hard on it?

Those are a few of the different principles that come to play when we talk about applying the principles, which is a human-oriented concept to a product development process.

Mitchell Hashimoto: This comes up a lot. The principles are a result of the human element of software development. That human element comes through in a few ways. We like to make software that has a more tightly defined surface area in what it does — it doesn't try to do everything all at once. Nomad was very focused on being a cluster scheduler.

Another human element is that we know people are going to use this thing, so we want to make it as easy to operate as possible — fun to use — things like that. You can see the results of that in some of the case studies that we published. One of our customers talked about a junior developer upgrading the entire production Nomad cluster. That's the core system that runs all their applications, and a junior person was able to do that. I loved that because that fits perfectly with our design ethos and those human elements.

A Deeper Dive into Pragmatism

The last one with pragmatism is understanding that people have problems to solve. You are usually going from a place you previously were towards getting that solution. When we started this project back in 2015, we recognized containers are obviously the future. But there are a huge number of workloads that are both non-containerized and also non-Linux.

That same case study I previously mentioned is a very large Windows user, and Nomad was huge to them because it works on Windows. These are all a reflection of those principles that we believe in around pragmatism, vision, workflows — things like that — to build a product that’s quintessential HashiCorp.

Armon Dadgar: I like one of the points you raised when we talk about pragmatism. It sometimes gets interpreted as only focusing on a few narrow, practical things that the market cares about. Often we get asked why does Nomad, for example, support things other than containers?

You make a great job of pointing out that some of our largest users run non-containerized workloads on Windows. The market would tell you that containers on Linux are the only workload that matter. At the same time, I think people will tell you "Well, practically, does anyone need to run more than a few thousand containers?"

People made a whole point out of it when we did this Million Container Challenge. We ran a million containers on top of Nomad. People were like "Well, but is that practical? Does anyone need that?" And the reality is, yes, we have paying customers that run workloads many times larger than that. For us, pragmatism goes beyond what's the common knowledge of the industry I'm in — what's hot — to listening to customers, understanding what they're doing, and focusing on that as pragmatically, as that's their problem; that's their reality.

Aligning Principles to Nomad 1.0

I love that point you made, Mitchell. At this point, I want to introduce Yishan Lin — who is the product manager for Nomad — to talk to us a little bit more about what a 1.0 does mean in the context of Nomad.