<div class="csl-bib-body">
<div class="csl-entry">Esberger, M. (2026). <i>Designing Cloud Applications for Compatibility: A Case Study on Kubernetes and OpenShift</i> [Diploma Thesis, Technische Universität Wien]. reposiTUm. https://doi.org/10.34726/hss.2026.123042</div>
</div>
-
dc.identifier.uri
https://doi.org/10.34726/hss.2026.123042
-
dc.identifier.uri
http://hdl.handle.net/20.500.12708/229305
-
dc.description
Arbeit an der Bibliothek noch nicht eingelangt - Daten nicht geprüft
-
dc.description
Abweichender Titel nach Übersetzung der Verfasserin/des Verfassers
-
dc.description.abstract
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.
de
dc.description.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.
en
dc.language
English
-
dc.language.iso
en
-
dc.rights.uri
http://rightsstatements.org/vocab/InC/1.0/
-
dc.subject
Kubernetes
en
dc.subject
OpenShift
en
dc.subject
Cloud Compatibility
en
dc.subject
Microservices
en
dc.subject
Design Patterns
en
dc.subject
Software Migration
en
dc.subject
Container Orchestration
en
dc.subject
Vendor Agnosticism
en
dc.subject
Kubernetes
de
dc.subject
OpenShift
de
dc.subject
Cloud-Kompatibilität
de
dc.subject
Microservices
de
dc.subject
Design Patterns
de
dc.subject
Software-Migration
de
dc.subject
Container-Orchestrierung/Herstellerunabhängigkeit
de
dc.title
Designing Cloud Applications for Compatibility: A Case Study on Kubernetes and OpenShift
en
dc.title.alternative
Design von Cloud-Anwendungen mit Fokus auf Kompatibilität: Eine Fallstudie zu Kubernetes und OpenShift
de
dc.type
Thesis
en
dc.type
Hochschulschrift
de
dc.rights.license
In Copyright
en
dc.rights.license
Urheberrechtsschutz
de
dc.identifier.doi
10.34726/hss.2026.123042
-
dc.contributor.affiliation
TU Wien, Österreich
-
dc.rights.holder
Manuel Esberger
-
dc.publisher.place
Wien
-
tuw.version
vor
-
tuw.thesisinformation
Technische Universität Wien
-
dc.contributor.assistant
Weise, Martin
-
tuw.publication.orgunit
E194 - Institut für Information Systems Engineering