Designing cloud applications for compatibility : a case study on kubernetes and OpenShift

Abstract

The transition from monolithic architectures to microservices has established Kubernetes a viable solution for container orchestration, yet the ecosystem remains fragmented across diverse implementations like Azure Kubernetes Service (AKS) and OpenShift. This fragmentation introduces compatibility challenges for DevOps teams, primarily due to vendor-specific configurations and API evolutions. This thesis investigates these challenges through a Systematic Mapping Study (SMS) and a Multivocal Literature Review, identifying API deprecations, networking, and deployment tooling as the areas of friction in the practitioner community.Central to this research is a case study involving the migration of the DBRepo application from an AKS environment to a more restrictive private OpenShift cluster. Through this "lift-and-shift" process, we formulated several design patterns to enhance application portability. A primary finding is that designing for the most restrictive security environments—specifically complying with OpenShift’s restricted-v2 Security Context Constraints (SCC) inherently improves compatibility across less stringent platforms.Furthermore, we propose a platform-independent gateway service to abstract away vendor-specific Ingress and Route configurations, facilitating a single codebase for multiple cluster types.The proposed design patterns were validated on a Minikube instance, serving as a baseline for vendor-agnosticism. The evaluation demonstrated that 6 out of 9 compatibility categories functioned "out of the box" without reconfiguration. While manual efforts remained necessary for storage onboarding and dependency updates, the results indicate that prioritizing minimal privilege requirements and architectural abstraction reduces the technical debt and effort associated with cross-platform cloud migrations.54

Der Übergang von monolithischen Architekturen zu Microservices hat Kubernetes als praktikable Lösung für die Container-Orchestrierung etabliert, doch das Ökosystem bleibt durch verschiedene Implementierungen wie Azure Kubernetes Service (AKS) und OpenShift fragmentiert. Diese Fragmentierung führt zu Kompatibilitätsproblemen für DevOps Teams, die primär auf herstellerspezifische Konfigurationen und API-Weiterentwicklungen zurückzuführen sind. Die vorliegende Arbeit untersucht diese Herausforderungen mittels einer Systematic Mapping Study (SMS) und eines Multivocal Literature Review. Dabei werden API-Abkündigungen (Deprecations), Networking und Deployment-Tools als die zentralen Reibungspunkte innerhalb der Fachcommunity identifiziert.Kern dieser Forschung ist eine Fallstudie zur Migration der Anwendung „DBRepo“ von einer AKS-Umgebung in einen restriktiveren, privaten OpenShift-Cluster. Im Zuge dieses „Lift-and-Shift“-Prozesses haben wir verschiedene Design Patterns formuliert, um die Portabilität von Anwendungen zu erhöhen. Eine wesentliche Erkenntnis ist, dass die Auslegung auf die restriktivsten Sicherheitsumgebungen – insbesondere die Einhaltung der restricted-v2 Security Context Constraints (SCC) von OpenShift – die Kompatibilität auf weniger strengen Plattformen inhärent verbessert. Darüber hinaus schlagen wir einen plattformunabhängigen Gateway-Dienst vor, um herstellerspezifische Ingress- und Route Konfigurationen zu abstrahieren und so eine einheitliche Codebasis für verschiedene Cluster-Typen zu ermöglichen.Die vorgeschlagenen Design Patterns wurden auf einer Minikube-Instanz validiert, die als Referenz für Herstellerunabhängigkeit diente. Die Evaluierung ergab, dass 6 von 9 Kompatibilitätskategorien ohne Neukonfiguration direkt („out of the box“) funktionierten. Obwohl manuelle Aufwände für das Storage-Onboarding und die Aktualisierung von Abhängigkeiten bestehen blieben, deuten die Ergebnisse darauf hin, dass die Priorisierung minimaler Berechtigungsanforderungen und architektonischer Abstraktion die technischen Schulden sowie den Aufwand bei plattformübergreifenden Cloud-Migrationen reduziert.