Layer 7 Observability and Centralized Configuration with Consul Service Mesh

Microservices architecture unlocks greater efficiency, agility, and stability for application development. However, there's a significant trade-off in networking complexity due to the rapid expansion of service-to-service communication. Business applications will have to deal with real-time interaction across hundreds of services over the network. Therefore, SRE teams will need visibility and control over the dynamic connectivity between services in a distributed environment.

There have been many creative solutions for implementing a core set of reliability patterns in application networking over the past few years. These patterns include:

• Service discovery
• Load balancing
• Retries
• Circuit breaking
• Rate limiting

In this webinar, HashiCorp Developer Advocate Erik Veld discusses several of the creative solutions that organizations have used for implementing reliability patterns and he'll explain why service meshes have emerged as the most elegant option for most teams.

A service mesh is a dedicated networking layer designed to tackle reliability challenges and its support for broad observability has become the key feature that draws in more adoption as users try to better understand and optimize the behavior of their applications and their systems.

Layer 7 observability features are part of Consul service mesh—a distributed networking layer that connects, secures, and configures services across any runtime platform and cloud. Consul's new Layer 7 observability features enable a unified workflow for metric collection, distributed tracing, and logging. It also allows centralized configuration to manage and configure the distributed data plane.

In the second half of the webinar, Veld will demo the L7 observability features of Consul by showcasing several centralized metrics configurations.

Outline

0:00 — Understanding the shift from static to dynamic networking

7:10 — Introduction to service mesh in Consul

11:01 — Overview of observability practices

14:44 — L7 observability features

17:42 — Demo Introduction: Centralized metrics configuration in Consul service mesh

24:44 — Demo: Metrics configuration in Consul service mesh

42:26 — Q&A

Q&A

• How would the architecture you showed on slide 34 be implemented if you were using HashiCorp Nomad instead of Kubernetes? Which proxy can be used for sidecars? Is this similar to CA API Gateway?

• When he says "localhost" does he mean the gateway? Or inside the container?

• Is the Consul proxy based on Envoy?

• Lets say service A connects to service B and service C. Service B and service C both are exposed in the same port. Will I be able to use this kind of setup with Consul proxy?

• If an existing service uses mDNS for service discovery, can I somehow integrate that with my Consul cluster?

Additional resources

• HashiCorp blog announcement: Layer 7 Observability with Consul Service Mesh

• HashiCorp Learn: Layer 7 Observability with Kubernetes and Consul Connect

• Instruqt's sandbox environment with a Consul cluster on Kubernetes

• Demo repo: A COBOL app running with Consul service mesh

Slides