You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a Kubernetes environment, many people turn to a service mesh such as Istio, Linkerd or Consul to authenticate and encrypt their network communications, however this is not an option for Akka cluster communication. The goal of a service mesh is to ensure that services do not need to be aware of where and how the services they talk to are deployed, a service mesh hide this, a client thinks its only talking to one logical service, while the service mesh handles concerns such as load balancing, encryption, authentication and authorization, and so on. Akka clusters however need to understand how and where the individual nodes are deployed, in order to implement their stateful features such as sharding, replication and peer-to-peer messaging. When deploying a service that uses Akka Cluster to a service mesh, the Akka Cluster communication must bypass the service mesh.
While these two statements are 100% correct, they are likely to mislead users into thinking that Akka cannot be used with a service mesh, and that Akka cannot benefit from what a service mesh has to offer. Of course, this is not true, Akka services talking to other HTTP services, or even talking to other Akka services using HTTP, as opposed to communicating within a cluster, can benefit greatly from what a service mesh has to offer, including transparent mTLS, workload identity and authorization, and routing policies used to implement deployment strategies such as blue/green, A/B and canary, etc.
I think therefore we should soften the language here to say things along the lines of "While a service mesh can complement Akka deployments well, particularly for HTTP and gRPC communication between Akka services, communication between nodes of an Akka cluster cannot be done through a service mesh." I think it would also benefit if we had some documentation somewhere that we can link to from these places about how Akka applications may take advantage of a service mesh, and include some high level instructions of what needs to be done to ensure Akka clustering still works. We do currently have this, but that's Istio specific and buried deep within the Akka Management documentation.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
The Remote Security page says:
The Remoting page that it links to says:
While these two statements are 100% correct, they are likely to mislead users into thinking that Akka cannot be used with a service mesh, and that Akka cannot benefit from what a service mesh has to offer. Of course, this is not true, Akka services talking to other HTTP services, or even talking to other Akka services using HTTP, as opposed to communicating within a cluster, can benefit greatly from what a service mesh has to offer, including transparent mTLS, workload identity and authorization, and routing policies used to implement deployment strategies such as blue/green, A/B and canary, etc.
I think therefore we should soften the language here to say things along the lines of "While a service mesh can complement Akka deployments well, particularly for HTTP and gRPC communication between Akka services, communication between nodes of an Akka cluster cannot be done through a service mesh." I think it would also benefit if we had some documentation somewhere that we can link to from these places about how Akka applications may take advantage of a service mesh, and include some high level instructions of what needs to be done to ensure Akka clustering still works. We do currently have this, but that's Istio specific and buried deep within the Akka Management documentation.
The text was updated successfully, but these errors were encountered: