Providing a tenant (1)

It does not matter what deployment model is chosen, a client has to provide a landscape that can provide user accounts (IAM, IDP, potentially Just-In-Time or Privileged Access Management).

The requirements are vastly different per client and per option (customer managed or on premise) and are always already regulated by the client internally. Unique can advice but most clients have this set in stone how it will work except if they started to adopt the cloud a week before where it would not be realistic to run Unique there within reasonable time (in that case, look in the direction of the ).

Networking

From the inter-/intranet to Uniques deployment lead many ways. The planning and implementation as well as maintenance of the way is the clients responsibility. Unique has a which uses an internet facing Application Gateway but if clients would like to wire Unique differently, they must do so on their own knowledge and expense if needed with advisory at a rate.

Hosting Unique / Dedicated resources (2)

Clients must provide means to provision a set of resources needed to run Unique successfully. Depending on the use cases, more or less of these services are needed.

¹ Unique currently only supports Kubernetes as orchestrator. Other orchestrators are available at a premium.

² Unique currently only supports Prometheus as metrics export. Other solutions might be available at a premium.

³ These services can also be self-hosted on top of the orchestrator which is discouraged but possible. The client is responsible for these workloads.

Workload configurations and supporting services (3)

¹ These services are recommended to be provisioned outside of the orchestrator, see (2).

Unique workloads (4)

The Unique workloads themselves have no requirements except all the services mentioned above, CPU and memory. Some require some disk space to locally ephemerally cache file or similar content.

Supporting tooling

Both Customer Managed Tenants as well as On Premise installations might not be able to leverage all internet facing tooling Unique provides.

You can get familiar with those in .

Some key bullets in that regard are:

• The orchestrator has no internet access

  • Unique advises against pulling directly from our docker registry as it is a central, single point of failure or more importantly the client does not want to directly run images from Unique

• The cluster ing- and e-gress is restricted or isolated from the internet

• The client must always apply some customisations on their side (especially around Vaults and Secrets)

• The deploying entity/machine has no internet access

Depending on a clients setup, further tooling is needed on site so either within their tenant/environment or also On Premise.