Earlier this week I presented my talk "Need something simpler than Kubernetes?" to the CNCF Linz community.

This post is a follow-up explaining how to deploy a native workload to Nomad. Nomad is unique because of its hybrid support for many types of workload. While Kubernetes has been designed for managing container-only workloads, Nomad’s pluggable task drivers allows scheduling container, Java, native (raw), QEMU/KVM, etc. workloads.

With my previous post I demonstrated how simple it is to connect services through Nomad’s service discovery support. I promised to follow-up showing this with Consul providing the service registry and use Consul’s service discovery.

Le’s look into the service stanza documentation. The provider key allows 2 different values. We already used nomad implementing the Nomad service registry. Before Nomad 1.3 only consul was a supported service registry. This was the default for this key and would register the service with the Consul service registry. So we would go ahead and just would set provider = "consul" for the api and the db service.

With the recently released Nomad 1.3 a service registry backed by Nomad was added. This is making building complex services dependent on others really easy. Earlier we typically would have added Hashicorp Consul as service registry. In a production environment that would have meant to a add a Consul cluster running along with the Nomad cluster. Obviously this comes with some costs even when running such a cluster is really made simple by Hashicorp.

In the past 2 years I successfully architected and developed a new product for a customer and brought it to production. This product uses Hashicorp’s job scheduler Nomad for managing workload.

Nomad is an excellent alternative to Kubernetes. It is known for its simplicity in regard to usage and maintainability and allows to schedule containerized and non-containerized applications.