If you find all this service mesh stuff confusing, and you really want to understand it, start with @envoyproxy. Learn Envoy's core feature set and how to configure it by hand.
Start simple. Learn how to use Envoy as a HTTP proxy or load balancer like you would nginx.
Start simple. Learn how to use Envoy as a HTTP proxy or load balancer like you would nginx.
One of the best things about Envoy is the ability to leverage a configuration server to dynamically configure it at runtime.
Instead of configuring Envoy by hand and copying config files around, you can configure Envoy to sync configuration from remote server.
Instead of configuring Envoy by hand and copying config files around, you can configure Envoy to sync configuration from remote server.
Envoy leverages the xds protocol for discovering and streaming configs, and the best part, it will hot reload the configuration, no more restarts! https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
Envoy also has support for custom plugins, metrics, and a bunch of features you might find useful like rate limiting and circuit breakers, which can all be configured centrally, and that's what makes Envoy stand out from the crowd.
Envoy also set the bar when it comes to securing HTTP endpoints. Envoy makes it easy to centrally manage TLS certificates and rotate them without a restart.
https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret

While you can use Envoy as a HTTP proxy or load balancer, you can also use it like an application server. Think Apache and PHP.
You can run Envoy in front of an application and fine tune the configuration for just that service. This is the fundamental idea behind a service mesh.
You can run Envoy in front of an application and fine tune the configuration for just that service. This is the fundamental idea behind a service mesh.
Once you have more than a handful of these Envoy proxies running around you're going to really appreciate the ability to configure them via a central configuration service.
So why all this talk of tools like Istio when you can just use Envoy?
So why all this talk of tools like Istio when you can just use Envoy?
Well, there are many ways to generate an TLS certificate, and to be honest, Envoy's raw configuration is a bit verbose and intimidating, and that leaves room for, you guessed it, abstractions.
There is another big component to the whole service mesh thing and that's service discovery. If you're running Kubernetes, then you'll need to integrate with its service layer. You can use DNS, but you know, DNS.
In addition to Kubernetes you got VMs and other service discovery tools like Consul and etcd.
This is where custom xds control planes come in. They know how to integrate with different service discovery tools and generate Envoy configs incorporating the service endpoints.
This is where custom xds control planes come in. They know how to integrate with different service discovery tools and generate Envoy configs incorporating the service endpoints.
While you can write your own xds control plane with service discovery integration, TLS certificate management, and the ability to generate Envoy configs, I'm not sure that's the best use of your time. If you need all of that then, and only then, do you look at a "service mesh".
Which service mesh should you chose? Like I know.