Re:Containers, microservices, and service meshes
by fogetti on Tuesday May 21, 2019 @07:23AM
(#19969131)
I don't really see how the service mesh solves eventual consistency. You might call a service which handles all the tasks asynchronously similarly to a message in a message broker system.
Service discovery is also inherent in the routing rules itself when you use something like AMQP for example.
Observability might be something that the broker system lacks of I agree.
Re:Containers, microservices, and service meshes
by jordanbeiber on Tuesday May 21, 2019 @09:52AM
(#19970138)
Oh no, it doesn’t and it wasn’t what I wanted to imply.
But you might have scenarios where you want or require synchronous or continous direct service to service communication is what I meant.
The protocol has less to do with it, see grpc for example.
Having run an operationally critical microservice infrastructure with consul for service discovery I realized that a mesh makes sense.
When you start hitting a few hundreds of services you’ll want:
1. The observability. Scenario: Why is the application slow? The application depends on two different services each with individual sets of downstream dependencies.
2. Making the services discovery process more resilient. An outage of consul without other means of discovery sucks!
Message brokering as well as event sourcing seems to this layman like awesome patterns where eventual consistency is perfectly ok.
In most scenarios it probably is, but for some it is not.
Whatever works!