Issues in a Microservices Service Mesh

Microservices
a)Between MS, there are no encryption.

b)There are no retries, no failover.
The communication is often true http,and when the request fails, it will often just show an error, it will not try again, or try a replica of that application.

c)There’s no intelligent load balancing.
The Ingress controller will deplete load balance based on route dropping.
If a pod communicates up to in Kubernetes,then it will go to a service.
The service will again use routing to send traffic to the different pods.
So there’s no intelligent load balancing.
It doesn’t recheck the latency that it has over different pods.
It just routes it using a simple algorithm.
There’s no routing decisions that you can make so the routing is still very simple.
You can make some routing decisions in the ingress controller, but then once you are between the applications, there is no decisions that are being made.

d) No logs or tracings

e) No detailed metrics to study various calibrations such as resource usages, API traffic, resource limits etc.

f) No access control between microservices. This means that microservices can communicate among themselves without any access control mechanism in place.

g) Absence of a circuit breaker pattern which will check any false or unhealthy calls to microservices.

h) Rate limiting provisioning using which traffic to any service can be limited.