Certification: Consul Associate (002)

Why get certified in Consul?

Joaquín Menchaca (智裕)
5 min readApr 7, 2024


I recently got certified for Hashicorp Consul, a Service Discovery solution as well as a Service Mesh solution using the connect feature. Some of you may ask the question, why?

There are so many other certifications that are in market demand, such as Kubernetes or certifications from the top three cloud providers: Azure, GCP, AWS.

Well, you would not be wrong. The too TL;DR summary is one word: architecture.

The concepts around Service Discovery are at the heart of modern cloud native computing architecture, especially with distributed clusters and microservices architecture (more on this later).

Discovery has always been with us from the Iron Age to the Cloud Age. In days of static configuration with CFEngine, Puppet and Chef, there was a form of limited discovery (synchronous) with a centralized database and the change configuration agent. In the days of dynamic configuration with short lived systems that are common on cloud platforms, there is discovery at the instance level using EC2 tags or GCE labels combined with dynamic inventory (Ansible) or a roster module (Salt Stack).

Ultimately these solutions did not scale, so we needed orchestration platforms that can dynamically schedule, configure, discover, and recover (heal) the services it manages, and thus platforms like Swarm, Nomad, and Kubernetes have not only become essential, but popular.

Service Discovery

The reason such orchestration platforms like Kubernetes are so successful is because Service Discovery is baked into it, and because of this Kubernetes provides opportunities for disaster recovery. The essential pieces of Service Discovery should the following:

  • health checks: mechanism to test the health of the service, to determine if it is ready to service clients.
  • service registration: system to register the services along with the health check into a catalog.
  • service registry catalog: the database that stores the catalog of available services.
  • query interface: DNS or API to query for the services that are available.

When these features are available for the discovery platform, you can architect an infrastructure to include support for failover.

As an example, if your application uses MongoDB in an US datacenter and becomes unavailable, the Service Discovery could automatically route traffic to an equivalent database in the EU datacenter. When the database is brought back up in the US datacenter, the services will automatically reroute back to the local available solution.

Some of this is already baked Kubernetes, but for cross datacenter connectivity and failover, you need to explore solutions that can connect the Kubernetes clusters across regions together, such as a multi-cluster Service Mesh.

Service Mesh

There is some overlap between Service Discovery and Service Mesh. A Service Discovery solution can be client side, meaning the client does the load balancing, or server side, where an intermediary, such as a proxy, does the load balancing and tracks availability on behalf of the client (called a service consumer). Consul acts as an intermediary for discovery, and has extended its functionality with a Connect to add Service Mesh features.

A Service Mesh provides a proxy service between all its members. These small proxies not only do the load balancing and know the availability of the service instances, but also have features to provide encryption and authentication for its members using mutual TLS that is automatically configured at the launch of these applications

Service Mesh with a sidecar Proxy

Many implementations today use a sidecar proxy container that is installed into each pod adjacent to the client service container. Some solutions today include Istio, Linkerd, Kuma, Nginx Service Mesh†, and of course Consul Connect (now Consul Service Mesh).

📓NOTE: Recently, the Nginx Service Mesh has been canceled by F5 Currently, F5 is promoting a non-Nginx alternative with F5 Aspen Mesh built around Istio that uses Envoy instead of Nginx to proxy traffic.

There’s also some more recent interesting Service Mesh alternatives that use a single proxy per node, such as Ambient and Cilium Service Mesh. Cilium is interesting in that it can encrypt data-in-flight at Layer4 level and can do real load balancing of gRPC (HTTP/2) traffic without a Service Mesh. Ambient uses ztunnel proxy, and both Cilium and Ambient have superior traffic control through eBPF.


The understanding of the Consul platform encompasses principles integral to Service Discovery and Service Mesh technologies. These principles offer insights into designing secure, resilient platforms equipped with disaster recovery capabilities.

Service Discovery is a core component of contemporary orchestration systems like Kubernetes and is enhanced by Service Mesh technologies. Even without Kubernetes, Consul can replicate some features, such as automatic healing, and with Connect functionality, Consul can provide automated authentication, encryption, and access control for your applications.

Consequently, the Consul Associate (002) certification is a critical qualification for grasping concepts that are fundamental to both traditional and modern architectural frameworks.


Service Discovery Articles and Documenation

Recent Articles on Service Mesh

My Blogs on Service Mesh