We should also add Kuma (https://kuma.io), which already supports a "kuma.io/protocol" attribute that can be extended with any other protocol type (as long as Envoy support it) and that can be used to apply Kuma policies like TrafficRoute, TrafficPermission and so on.
Suggestion was deleted
Show more
Show less
Comment details cannot be verified
Jonathan Beri
Sep 12, 2020
Approver
Thanks Marco! kuma.io/protocol is 404ing for me - is that the right URL?
This alternative routing implementation document has no bearing to the goals of this document on adding new protocol support. The alternative routing implementation is purely an istio internals related document.
Suggestion was deleted
Show more
Show less
Comment details cannot be verified
Jonathan Beri
Mar 10, 2020
Approver
Oh, than I misunderstood the goal of the proposal. From the objective, "This document outlines an Istio meta Routing API which enables users to steer traffic for various protocols without requiring the Istio APIs to be continuously updated for new protocol(s) support.
This enhancement will allow users to route traffic for protocols like Thrift/Kafka/MongoDB without tightly coupling the Istio API surface and Envoy supported protocols."
While internals-related, doesn't that enable users to add new protocols?
Reply was deleted
Show more
Show less
Comment details cannot be verified
Shriram Rajagopalan
Mar 11, 2020
Approver
No. Its just fancy wording.
Reply was deleted
Show more
Show less
Comment details cannot be verified
2 replies
New
Evan Anderson
Mar 10, 2020
Approver
KEDA requires a component which can queue messages and expose a count of how many messages are queued to trigger the autoscaler. This works for something like Kafka or ActiveMQ, but may not work for a forwarding-only architecture. (My basic understanding of MQTT implementations is that they are mostly forwarding rather than persist and then send.)
Suggestion was deleted
Show more
Show less
Comment details cannot be verified
Jonathan Beri
Mar 25, 2020
Approver
In systems where devices are expected to go offline often, like wireless sensor networks, they have do have persistence. But they're often more simple proxies that try to deliver when a device is back online, rather than a stream processing system like Kafka et al. But yes, many are proxy/caching layers too.
Reply was deleted
Show more
Show less
Comment details cannot be verified
Evan Anderson
Mar 25, 2020
Approver
Aha, I take back my comment about MQTT being mostly forwarding; it sounds like most implementations are closer to publish-subscribe systems.
Reply was deleted
Show more
Show less
Comment details cannot be verified
2 replies
New
You're suggesting
Gemini created these notes. They can contain errors so should be double-checked. How Gemini takes notes
Drag image to reposition
11
10
9
8
7
6
5
4
3
2
1
1
2
3
4
5
6
7
8
9
10
Outline
Outline
Document tabs
Adding new protocols to the cloud native ecosystem
3
Headings you add to the document will appear here.
Adding new protocols to the cloud native ecosystem
Background
Exposing Services
Service Objects
Ingress Objects
Network Service Mesh (NSM)
Service to Service
Envoy
Service Mesh
Service Mesh Interface
Istio
L7mp: A multiprotocol service mesh
Application serving
Knative
cloudevents
Topics to Investigate
Relevant Links
Changes by
Adding new protocols to the cloud native ecosystem