Remove Consul drawback

[blake]

I am proposing this change because I am not entirely clear as to what this drawback may be referring to.

Consul is platform agnostic and works across a wide range infrastructure platforms/cloud environments. It can be used in physical, VM, or container-based environments such as Kubernetes. It is not limited to a particular infrastructure platform.

In that context I'm not sure it makes sense to keep this drawback. I'm happy to discuss if you disagree, or if this is referring to something else.

[HPrinz]

The drawback refers to the fact that the Consul Connect Service Mesh depends on installing Consul. Of course Consul can be installed everywhere. But in case a team has already adopted Kubernetes, they need to install and configure Consul, even if they are only interested in some Service Mesh features only.

This is different in Service Meshes like Istio and Linkerd since they heavily rely on Kubernetes. Which of course is a drawback if Kubernetes is not used.

Please correct me if I am wrong.

[blake]

Thanks for clarifying that. Yes, that is true and it can be a drawback for organizations who are only looking to use a service mesh in Kubernetes.

Perhaps it would be better to clarify this point across all of the listed mesh solutions which do not utilize the control plane provided by the underlying infrastructure platform.

[HPrinz]

IMHO all other service meshes rely on either Kubernetes (Istio, Linkerd 2, Maesh), on AWS Infrastructure (AWS App Mesh). Kuma can either integrate with the Kubernetes Service Registry or be installed in VMs.

So from my perspective, Consul is the only Service Mesh that is integrated with Kubernetes and still implements Service Discovery on its own. Istio for example is only capable of extending the Service Registry it fetches from Kubernetes. So Consul is more powerful, which can be a drawback when you don't need that complexity.

[blake]

Consul does support synchronizing its service catalog with Kubernetes (https://www.consul.io/docs/platform/k8s/service-sync.html) & AWS Cloud Map (https://github.com/hashicorp/consul-aws). Its pretty common for folks to utilize Kubernetes' native service discovery within K8s, and then rely on Consul service discovery for workloads that are outside of Kubernetes.

Aside from requiring you to run a separate control plane, Consul tries to integrate fairly seamlessly with runtime environment in which you're deploying workloads.

Do you still feel there are large drawbacks with Consul in comparison to how other solutions integrate with Kubernetes?

[HPrinz]

Thank you for your patience. I would still say that in Kubernetes environments, Linkerd 2 or Maesh are more lightweight since they use components like the service registry instead of introducing their own implementation (which, again, can have positive and negative effects). However, in comparison to Istio, Consul might not add as much technical complexity. I will discuss this with my colleagues and let you know.

[ewolff]

The factual statement (requires Consul) is correct and not debated, it seems. Whether it is a drawback is of course a different issue and I can see why it would be considered. Of course, we could clarify ("relies on Consul control plane") or change the drawback for other service meshes - but that would be a different PR.

[blake]

I'm in favor of clarifying that compared to other solutions Consul uses its own control plane in Kubernetes, as that seems to be what the original text was attempting to convey.

I agree it makes sense to propose that change in a separate PR.