Differences to APPUiO Public
APPUiO Cloud is the successor to APPUiO Public. This page lists the most notable differences.
This is only a summary for convenience and may not be complete. For the exact set of features, see the APPUiO Cloud Product Documentation. In case of differences, the APPUiO Cloud Product Documentation takes precedence.
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.
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.
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
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
In APPUiO Public the timezone was set to