Introduction to Consul Namespaces

Transcript

My name is Raymond Austin, director of marketing for Consul. I'm here today to talk to you about how Consul simplifies self-service governance, and operations with Consul namespaces—which we introduced as part of the 1.7 update.

So, what is Consul? Consul provides a foundation for cloud networking automation using a shared registry for service networking. Another way to think about it is Consul provides connectivity and security between services in any real-time platform or cloud environment.

Consul use cases

There are three use cases for Consul. The first one is around service discovery and health monitoring, where Consul can provide a real-time directory of the services that are out there and overall health status.

The second one is around network middleware automation—dynamically reconfiguring load balancers and firewalls in a dynamic IP environment as services scale up and down.

The third one is around providing a zero trust network using service mesh where a lot of the routing and authorization features are done at the endpoints and dramatically simplifies the overall network topology—especially between East and West traffic paths.

Consul—a unified networking solution for multi-cloud

Consul is great as you can deploy it on-prem, in the cloud, across regions, across data centers. It truly becomes a unified networking solution for multi-cloud.

In terms of Consul adoption, we make it easy for customers to follow a maturity model that allows them to realize value immediately with an open source offering for individuals and practitioners.

However, when deploying Consul in a larger production environment with many teams, there are some additional complexities in terms of how to establish self-service between teams to provide overall consistency across dev, test, and production.

The challenges of managing clusters

An example of these challenges includes managing clusters. In a Consul context, a cluster involves servers connected to any number of clients or nodes. For this particular example, you have one team per cluster, which means you have five teams—you have five clusters.

The advantage of this approach is you have a separation of concerns between teams so you have resource isolation between teams. The problem with this approach is that there's no real central way from an operations perspective to ensure that there's consistency between what team one is doing, what team two is doing. The other side effect of this approach is that you have Shadow IT with different teams doing different things.

The other scenario or challenge is when you start to share clusters across teams. The benefit of this approach is that while you address the Shadow IT concern, there's an additional concern that operational teams or security teams will bring up–which is around managing permissions of what teams can register which services, and making sure that there's no overlap between what team A is doing and what team B is doing.

The big problem with this is that that can lead to a service name sprawl because teams have to create either meta tags or additional service names—extra service names—and that can be very problematic in a large services-oriented environment.

Managing clusters with Consul namespaces

Consul namespaces allows you to share a single cluster across teams. It allows global operators to provide resource isolation—or management resource isolation—within a single shared cluster. It allows global operators to delegate policies on a per-tenant basis.

The overall benefit of Consul with namespaces is twofold. One is to allow the reuse of service names across teams. This removes the need to coordinate service names between teams. It also allows admins to delegate privileges for each team—those privileges can be in the form of ACLs and services. The primary benefit of that is self-service.

In summary, Consul namespaces can dramatically simplify self-service, governance, and operations, especially in larger enterprise environments where there are multiple teams. For more information, please visit learn.HashiCorp.com. Thanks.