From 1ad605eb5cb70d51ce136eac8e2a4ff1e38db81f Mon Sep 17 00:00:00 2001 From: Mark Fussell Date: Mon, 22 Nov 2021 12:33:34 -0800 Subject: [PATCH] Update daprdocs/content/en/concepts/service-mesh.md Co-authored-by: Will --- daprdocs/content/en/concepts/service-mesh.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/concepts/service-mesh.md b/daprdocs/content/en/concepts/service-mesh.md index b618b2765..1c81221f7 100644 --- a/daprdocs/content/en/concepts/service-mesh.md +++ b/daprdocs/content/en/concepts/service-mesh.md @@ -36,7 +36,7 @@ Watch these recordings from the Dapr community calls showing presentations on ru - Demo of running [Dapr and Istio](https://youtu.be/ngIDOQApx8g?t=335) - Learn more about [running Dapr with Open Service Mesh (OSM)]({{}}). -## When to choose using Dapr a service mesh or both +## When to use Dapr or a service mesh or both Should you be using Dapr, a service mesh, or both? The answer depends on your requirements. If, for example, you are looking to use Dapr for one or more building blocks such as state management or pub/sub, and you are considering using a service mesh just for network security or observability, you may find that Dapr is a good fit and that a service mesh is not required. Typically you would use a service mesh with Dapr where there is a corporate policy that traffic on the network must be encrypted for all applications. For example, you may be using Dapr in only part of your application, and other services and processes that are not using Dapr in your application also need their traffic encrypted. In this scenario a service mesh is the better option, and most likely you should use mTLS and distributed tracing on the service mesh and disable this on Dapr.