Clarification on SOVD Gateway vs SOVD Server Architectural Model #9
Description
In the current SOVD specification, the concept of a “public SOVD server” is mentioned, but it does not explicitly defined whether this should be a single combined component or split into separate roles (e.g. Gateway + Server).
In OpenSOVD desgin => these are currently represented as two independent blocks.
Therefore it becomes an architectural question that affects interoperability and standard interpretation.
Intention of this discussion:
Clarify in the community, how SOVD should be interpreted:
- Is Gateway just an implementation option, not a defined SOVD role?
- Is it intended to be a architectural role separate from the SOVD Server?
Possible advantages:
-
One combined component (Server also acts as Gateway)
- Reusable reverse proxy logic on nested sovd servers.
- Fewer deployment units.
- Close to SOVD spec.
-
Separate Gateway + Server components
- Clearer separation of concerns
- Easier to integrate with different routing / security models, flexible cloud access strategies
- Less burden on SOVD Server.
- Less possible vender lock-in (OEMS can choose Chassis domain supplier with their SOVD stack).