Versions Compared

Old Version 13

changes.mady.by.user Ken Sayers

Saved on

compared with

New Version 14

changes.mady.by.user Ken Sayers

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

SUBJECTUI Deployment
STATUSOpen

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.

Item

Cloud Specific

Cloud Agnostic

How

Using S3 and other AWS specific technologies

Deploy as pod inside Kubernetes

Performance

Very good performance

Less performant

Availability

The UI itself is more available, but the api isn’t any more available

The UI is subject to the same availability as the API

Cost

Very inexpensive

More cost, TBD

Scalability

Infinite scalability, subject to API

Not as scalable, but good

Complexity

More complex for multi-cloud

Less complex for multi-cloud

Managability

More difficult to manage in remote nodes

Less complex for remote nodes

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.

...