I've had a few conversations recently where people see a Service Mesh sidecar/library (e.g. Istio) as some sort of general alternative to a Service Chassis.
That seems misguided - there are a lot of cross-cutting concerns that a service mesh *won't* provide. For example:
That seems misguided - there are a lot of cross-cutting concerns that a service mesh *won't* provide. For example:
1) configuration - How does your service discover general configuration values, as well as updates to those values
2) feature flagging - a special case to configuration, but one which in my experience is worthy of treating as a first-class cross-cutting concern.
3) non-technical instrumentation and analytics - how does your service expose product-level metrics, logs, events, and so forth. Think "average shopping cart value", not "P95 request latency".
4) authz and authn - who is this service request being made on behalf of, and what is that actor allowed to do?
5) healthchecks - Does this service consider itself healthy and able to service requests. A service mesh needs to know this information, but doesn't make it easier for a service to provide it.
What other cross-cutting concerns did I miss? Which ones did I get wrong?
BTW, when I talk about "cross-cutting concerns" here I'm talking about common functionality that all microservices need and shouldn't have to implement themselves. This functionality could provided by an org-specific Service Chassis (microservices.io/patterns/micro…), or a shared library.
