...
SUBJECT | UI Deployment | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
STATUS | Open | ||||||||||||||||||||||||
DECISION | The UI will be deployed inside kubernetes | ||||||||||||||||||||||||
DISCUSSION | There are two main choices for deploying the ui. Here is the discussion about the relative merits for the options.
We deploy the applications inside kubernetes so they are more manageable. This includes the APIs and the UIs. Deploying at the edge is a best practice, but manageability is more important in this case. We can deliver updates to the code as images in a container registry and have them deployed much easier than if we used AWS (or other cloud) specific services. Q: Why not have a centralized UI? A: The UI is configured to access the API. iI has to have private access to the API inside the node, not go out onto the internet and have the apis exposed publicly. The apis are private to the member cloud, actually private to the kubernetes cluster. Because manageability is a very high priority item for the ui components, this outweighs the differences in other aspects. |
...