Exploring the problem of Microservices communication and how both Kafka and Service Mesh solutions address it. We then look at some approaches for combining both.
30. Sidecar:
Components of the application, deployed in a separate
container to provide isolation and encapsulation.
This pattern allows applications to be composed of
heterogeneous components.
54. - REST API point-to-point communication
hits the wall
- Service Mesh adds discovery and operationalibility
- Kafka adds data, compatibility, immutable storage
- You can have both. In many different tastes.
- Coming soon to a proxy near you
55. Resources and Next Steps
https://github.com/confluentinc/cp-demo
https://www.confluent.io/download/
https://slackpass.io/confluentcommunity
https://www.confluent.io/blog
https://www.confluent.io/confluent-operator/
https://github.com/envoyproxy/envoy/issues/2852
Editor's Notes
Good afternoon, I’m Gwen Shapira. Glad to be here with you. This talk is kind of… experimental. When I first learned about Service Mesh, I got the impression that it solves similar problems as Apache Kafka, but from a completely different direction. In this talk, I want to explore the problem space, why I think Kafka and Service Mesh do similar things, the trade-offs involved and how these two solutions compliment each other.
The basic idea that most people end up with is that if one service needs another service to do something, it will use a REST API and call that service and ask it to do something.
Joining data sets
Exposing data
Evolving data
Basically let apps talk REST request-response like they always did, but magically get events to Kafka in order to grow
You can see a practically endless list of feature requests
This is open source, and you should get involved. You can check out the code on GitHub or play with the many examples there. Also, you are hereby solemnly adjured to join the Slack community and ask questions there!