Talking to a customer/user of Ziti after sharing with them the idea of fabric embedded, they asked the following questions related to the below slide
The Ziti fabric routes payloads between routers. Routers, hosting xgress components, are the initiating and terminating points for all traffic over the overlay. Routes with the lowest observed latency are chosen with the highest priority.
Routers that are not the initiating or terminating endpoint could participate in routing traffic, if traversing them provided the lowest latency path from an initiator to a terminator.
The fabric has a “terminator” concept, which is used to provide HA and load balancing capabilities. These are configured using “weights”. Using weights, you can create a number of useful characteristics in the configuration.
hey! Thanks, clarifies few of my queries. Pretty interesting feature ! kudos - allows great newer stuff to be done esp. on near 5G edge processing apps & gaming apps as well.
Is this allowed only for apps developed using SDK? Looks like yes from above explanation in slide. Hmm… ok!
Can I configure this similar xgress option on the NF Mgmt console in some way, for the case where I don’t want 3rd party app to be touched/modified. This would also get me freed-up from what Lang I use for apps - be it C/Go/Python/java.
Thanks.
Xgress is not part of the edge SDK, it's a part of the fabric. In order to do "fabric embedded", you would end up building new xgress initiator/terminator components, which would then be addressable on the overlay. You would do this by extending the fabric code at:
The NF console currently does not provide direct support for fabric embedded development. You would end up wanting to host your extended routers on your own deployment resources. A NetFoundry deployed network would allow traffic from your custom routers (extended with your fabric embedded integration) to be routed across NF hosted resources alongside any other Ziti traffic.
@michaelquigley I think Anantha’s has a couple of other embedded questions: (1) would it be correct to say that fabric embedded will support applications other than GoLang in the future and (2) while fabric embedded is not supported in NF Mngt console today, could it be supported in the future?
A developer who wants to create a fabric embedded application would only need to provide a very thin "shim" component in golang, which could communicate with nearly any kind of local resource including a unix domain socket, or shared memory (through c-go, etc.). The entire fabric embedded application would not need to be built in golang, just an interface that integrates it with the Xgress framework (which will become a "virtual NIC" in fabric 2.0).
We could, in the future, provide some pre-built shims that make integrations with commonly used languages very straightforward.
Fabric embedded applications could certainly be supported directly in the NF console in the future. At this point, we just need some earlyvangelists to start working with these components. As usage increases, we'll invest more into integrating support into the management console, etc.
For what it's worth, the Ziti edge is a "fabric embedded" application. So we're very much dog-fooding this ourselves.
@anantha Please feel free to reach out if you would like to discuss your use case in more detail. Would be happy to get on a call or provide support if it would be helpful.
