Differences to APPUiO Public

In APPUiO Public, the Quota applied to a namespace was billed. For APPUiO Cloud we changed that completely, you only pay for what you use (metered billing).

With APPUiO Cloud we’ve well-defined Support Packages available. Community support is included by default, whereas additional support by VSHN can be ordered in addition.

Persistent storage in APPUiO Public was provided via GlusterFS, which was also being backed up automatically by the underlying system. Users that needed to restore data could request a data restore via support. In APPUiO Cloud persistent volumes aren’t automatically stored in backup. For having backups of persistent volumes we offer the latest version of K8up on the APPUiO Zones.

APPUiO Public was based on OpenShift 3.11, which was Kubernetes 1.11 under the hood. APPUiO Cloud is based on OpenShift 4 which brings a very recent Kubernetes version. The OpenShift upstream documentation discusses the differences in more detail.

Login is now handled via Keycloak which allows for Two-Factor authentication and identity brokering. It features single-sign-on throughout the whole platform. In APPUiO Public login was based on LDAP and didn’t allow for more secure login methods as well as no identity brokering.

In APPUiO Public OpenShift projects had to be created via the VSHN Portal. For APPUiO Cloud we changed that so that OpenShift projects and Kubernetes namespaces can be directly created via the Kubernetes API or via the OpenShift Webconsole. The is no need anymore to use a third part API or portal for that task.

Just use oc new-project or kubectl create namespace.

APPUiO Cloud doesn’t allow Docker builds for security reasons, as the build process still relies on elevated privileges. APPUiO Public featured a self-made build tool called Aedifex which spun-up new virtual machines for image builds. This was an error-prone process and caused a lot of operational overhead. In APPUiO Cloud we recommend building container images outside the platform and either get the image from a public registry or push the image to the integrated registry. We recommend using GitLab CI/CD or GitHub Actions for automated image building. We closely monitor the possibilities of OpenShift. As soon as image builds are unprivileged we’ll revisit this feature and might allow image builds on the platform again.

TLS certificates can only be requested by using the standard Kubernetes Ingress object. This is due to the fact that we’re using cert-manager on the platform for managing Let’s Encrypt certificates. Unfortunately cert-manager doesn’t support the OpenShift Route object and doesn’t plan to do so in the future.

Check our how-to on generating certificates to get a closer look at how the new cert-manager based setup works.

We currently don’t offer dedicated nodes on APPUiO Cloud anymore. The main reason for the dedicated nodes feature of APPUiO Public was cost, this is no longer a valid reason with APPUiO Cloud as the costs are much lower. Another reason was security, which only held partially true, as the control-plane was still shared between all users of the platform.

For sending E-Mails we recommend using a specialized E-Mail provider like mailgun. There is no SMTP Gateway available anymore.

Persistent storage is provided by what the infrastructure offers via CSI integration and with Rook. In APPUiO Public, storage was provided via GlusterFS. Because of this change, the "Access Mode" for the Persistent Volume now actually matters, RWO provisions a "block storage" with a file system on it, RWX provides a shared file system (CephFS). See the Kubernetes upstream documentation which explains the storage topic in detail.

We use Isovalent Cilium Enterprise for networking in APPUiO Cloud. In APPUiO Public the OpenShift 3 ovs-multitenant plug-in was used which for example didn’t allow Network Policies.

In APPUiO Public each project had a Quota assigned, which could be changed by the user. For APPUiO Cloud there is a generic Quota applied to all projects which protects the platform from resource abuse. It should allow for most of the normal workloads. Should it not be enough for you, please request a quota increase via APPUiO Cloud support.

In APPUiO Public, the control plane restricted the execution time of "run-once" pods to 30 minutes by default. "Run-once" pods are pods that have a restartPolicy of Never or OnFailure. This was implemented using OpenShift 3’s mechanism to limit run-once pod duration.

On APPUiO Cloud, we don’t specify a hard limit on the time such pods can be active. Instead, we only apply a limit of 30 minutes to run-once pods which don’t have activeDeadlineSeconds set already. See the quota reference docs for more details on the mechanism.

Thanks to the recent Kubernetes version we offer the latest available K8up version.

APPUiO Cloud uses UTC as timezone on the control plane which affects for example CronJobs. In APPUiO Public the timezone was set to Europe/Zurich.

APPUiO Cloud stores logs only for three days. It’s also not possible to change the log retention for individual namespaces.