System idea

The system idea displays a high-level architecture of APPUiO Cloud.

Figure 1. APPUiO Cloud system idea

Keycloak

An instance of Keycloak is responsible for authoritatively store data for:

Organizations
Teams

The instance of Keycloak is not necessarily authoritative for user identities. It’s expected that most instances will setup user federation, identity brokering or social logins where users are authenticated externally. That being the case, user sign up or registration is not part of core APPUiO Cloud.

User and group sync

User and groups managed by Keycloak will be replicated to each APPUiO Zone using synchronization services running separately on each APPUiO Zone. It makes the cluster more resilient against connectivity issues between APPUiO IdP and an APPUiO Zone.

Policy engine

A policy engine, also installed on each APPUiO Zone, is enforcing policies that go beyond the capabilities of Kubernetes RBAC.

API Endpoint

APPUiO Cloud will be designed "API-first." This enables different client profiles to interact with the product. Clients could be user or command line interfaces and other automation services. The endpoint itself will be using foreign services for certain features.

Web User Interface

A graphical user interface will provide management, reporting and dashboard features. It’s not intended to be replacing the OpenShift Console on an APPUiO Zone, but rather an extension for things that affect all APPUiO Zones.

Adapters

APPUiO Cloud is not responsible for invoicing or payments. Those functionalities are provided by foreign services using APIs. APPUiO Cloud will define plugin-like APIs for which different implementations or adapters can be plugged in. See Adapters.

Namespace

This is the Kubernetes Namespace object that the developer creates and maintains. A namespace is always owned by and associated to an organization.