You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gateways is a built in feature of ZOS which allows users to create public gateways from the public internet to the private workloads of the user over wireguard or yggdrasil.
Benefits of using zos gateway primitive:
Integrated with the same ZOS api workload/deployment so no need to develop different APIs for it
Integrated with the billing system, consumption are reported as part of user consumption report
Most importantly, integration with the zos networking and user layout network, which allows the gateway to reach to the user private workloads.
If we have to build a standalone gateways that acts like this, it will need to re-implement huge parts of zos specially for the networking part. This is why i think the best course of action is to run entire zos node and limit it's support to only network+gateway workloads.
Gateways always also work as access points as well.
So from here we can tell we have only 2 paths:
Use ZOS for standalone gateways, you get everything for free.
Strip down the gateway with all supporting components, this is actually more work than it sounds to get everything right specially running the network workloads, and billing
Make zos installable on any system with say apt ?!
The other path is to make zos usable on other service providers, this still require some work to be able to deal with provided hardware (specially the networking) but in total that's still less work than separating the gateway part.
Gateways is a built in feature of ZOS which allows users to create public gateways from the public internet to the private workloads of the user over wireguard or yggdrasil.
Benefits of using zos gateway primitive:
If we have to build a standalone gateways that acts like this, it will need to re-implement huge parts of zos specially for the networking part. This is why i think the best course of action is to run entire
zos
node and limit it's support to only network+gateway workloads.So from here we can tell we have only 2 paths:
The other path is to make zos usable on other service providers, this still require some work to be able to deal with provided hardware (specially the networking) but in total that's still less work than separating the gateway part.
The text was updated successfully, but these errors were encountered: