HashiCorp Nomad Distributes Scheduling. The Namespace That Organizes It Is Still Central.

Nomad's architecture is deliberately simple. A single binary handles scheduling across heterogeneous workloads without the complexity of Kubernetes. Multi-datacenter federation is built in. The gap described here is not a criticism of Nomad's design. It is an observation about what scheduling alone cannot solve.

Scheduling distributes. Namespace authority does not.

Nomad distributes workload placement across clients in multiple data centers. A job submitted to any server in the cluster is evaluated and placed on the most appropriate client based on constraints, affinities, and resource availability. The scheduling itself is distributed.

But the namespace that defines what a job is, how it relates to other jobs, and how it can be discovered is governed by Nomad's server cluster. The servers maintain the state store, evaluate job specifications, and hold the authoritative view of the namespace. Clients execute. Servers govern.

For service discovery, Nomad depends on Consul. When a Nomad job registers a service, that registration flows to Consul's service catalog. Consul's catalog is itself a central registry, governed by Consul's server cluster through Raft consensus.

Multi-datacenter federation has the same property

Nomad supports multi-datacenter and multi-region federation. Jobs can target specific data centers. Servers in different regions can be federated. But federation in Nomad means that multiple server clusters coordinate through a designated authoritative region.

The authoritative region holds the canonical state for ACL policies, namespaces, and cross-region job definitions. Other regions participate in the federation but receive their namespace authority from the authoritative region. The topology is hub-and-spoke. The authority flows from center to edge.

What resolving it requires

Resolving the namespace governance gap means distributing the authority that organizes workloads, not just the scheduling of those workloads. Each region or scope would govern its own segment of the namespace through locally held policy, with resolution traversing anchor-governed scopes rather than querying a central service catalog.

In an anchor-governed index, a workload in one data center resolving a service in another would traverse through scoped anchors, each validating the resolution against locally held policy. Structural changes such as new services registering, services migrating between regions, or namespace segments splitting under load would be governed by local anchors through scoped consensus.

The authoritative region would not disappear. Its authority would distribute. Each scope would become its own governance plane, governed by the nodes that hold it. A region under regulatory pressure would not propagate that pressure to other regions because its anchors govern its scope and adjacent scopes govern themselves.

The remaining gap

Nomad solved the scheduling problem with elegant simplicity. The remaining gap is in the namespace layer: how workloads find each other across administrative boundaries, how that discovery persists through structural changes, and who governs the namespace that makes it all possible. That layer is still centrally defined.