<resource xmlns:datacite="http://datacite.org/schema/kernel-4">
<creators>
<creator>
<creatorName nameType="Personal">Casper De Keyser</creatorName>
<givenName>Casper</givenName>
<familyName>De Keyser</familyName>
</creator>
</creators>
<contributors>
<contributor contributorType="Other">
<contributorName>Christoph Lang-Muhr</contributorName>
<givenName>Christoph</givenName>
<familyName>Lang-Muhr</familyName>
</contributor>
</contributors>
<titles>
<title>Shifting the Orchestration Monoculture</title>
</titles>
<descriptions>
<description descriptionType="Other">Container-Orchestrierung hat sich zu einem wesentlichen Bestandteil für die Bereitstellung verteilter Anwendungen in großem Stil entwickelt. Innerhalb dieses Bereichs hat sich durch die Popularität von Kubernetes als Standardlösung eine Art "Monokultur" entwickelt, wodurch sich Kubernetes in vielen Orchestrierungsszenarien wiederfinden lässt. Der umfassende Funktionsumfang und die damit verbundene Komplexität von Kubernetes sind jedoch möglicherweise nicht für die spezifischen Anforderungen jedes Anwendungsfalls oder Entwicklungsteams geeignet und erschweren folglich Migrations- und Implementierungsbemühungen erheblich. Andere Technologien, welche einen stärkeren Fokus auf Einfachheit und Benutzerfreundlichkeit anstelle umfangreicher Anpassungsmöglichkeiten und damit verbundener Konfiguration legen, könnten für diese speziellen Anwendungsfälle alternative Lösungen darstellen.

In der vorliegenden Arbeit wurden zwei potenzielle Alternativen – Docker Swarm und HashiCorp Nomad – einer praxisorientierten Evaluierung unterzogen. Dazu wurde ein vordefinierter Use Case mit typischen, Produktions-tauglichen Elementen herangezogen. Die Analyse des Status quo hinsichtlich Orchestrierungs-Frameworks diente als Grundlage für die Auswahl der Kandidaten. Der Fokus der Analyse lag auf relevanten Open-Source-Technologien, welche die im Use Case definierten Anforderungen erfüllten. Durch eine detaillierte Gegenüberstellung jedes Kandidaten hinsichtlich gängiger Orchestrierungsfunktionen wie Skalierung, Lastausgleich, Service Discovery und Netzwerk konnten wertvolle Erkenntnisse gewonnen werden, die in eine abschließende Bewertung der Eignung beider Technologien für diesen speziellen Anwendungsfall mündeten. Die Analyse ergab, dass die Orchestrierungsfunktionen von Swarm die Anforderungen mit minimalem zusätzlichem Konfigurationsaufwand erfüllen. Nomad bedingt einen erhöhten Aufwand in Bezug auf Konfiguration und Recherche, weswegen sein erweiterter Funktionsumfang insbesondere für sehr große Deployments konzipiert zu sein scheint. In der abschließenden Diskussion wurde festgehalten, dass zukünftige Forschungsvorhaben potenziell weitere Erkenntnisse generieren könnten, welche die Orchestrierungslandschaft in ihrer Gesamtheit bereichern könnten. Dies könnte beispielsweise durch die Integration eines dedizierten Reverse-Proxys im Swarm-Umfeld oder durch den Einsatz des Consul-Service-Mesh im Nomad-Ökosystem erfolgen.</description>
<description descriptionType="Other">Container orchestration has become a crucial component for deploying distributed applications at scale. Within this domain, Kubernetes’ popularity has established a “monoculture”, resulting in it becoming the “go-to” solution for many orchestration scenarios. However, Kubernetes’ exhaustive feature set and its intrinsic complexity may not align with the specific requirements of every use-case or development team,
thereby complicating migration or implementation efforts. Other technologies, with a more significant focus on simplicity and ease of use rather than advanced customization and accompanying configuration, could present a more suitable solution for these specific cases.

This thesis investigates two potential alternatives—Docker Swarm and HashiCorp Nomad—through a practical evaluation based on a predefined use-case containing typical production-grade elements. Both candidates result from a review of the current state of the art in orchestration frameworks, focusing on relevant and open-source technologies that satisfy the use-case’s specified requirements. By evaluating each candidate in detail against common orchestration features such as scaling, load balancing, service discovery and networking, we uncover valuable insights, which result in a final verdict on both candidates’ suitability for this specific use-case. We find that Swarm’s orchestration capabilities meet the requirements with minimal additional configuration required. Nomad demands a more significant investment in terms of configuration and knowledge, although its advanced feature set appears more geared towards deployments on a larger scale. Finally, we acknowledge that future research could result in insights that benefit the broader orchestration landscape, particularly in terms of more advanced application stacks leveraging components—such as a dedicated reverse proxy in case of Swarm, or Consul’s service mesh in case of Nomad’s ecosystem.</description>
<description descriptionType="Other">Fachhochschule St. Pölten, Masterarbeit 2025, Studiengang Cyber Security and Resilience</description>
<description descriptionType="Other">This thesis covers the comparison of different technologies for hosting and orchestrated computing workloads known as containers. Through a practical evaluation with a predefined use-case, different elements in the domain of computing, networking and security were evaluated. The resulting insights can be used by architects, developers and other technical profiles in order to make an informed decision for their specific requirements or use-case.</description>
</descriptions>
<resourceType resourceTypeGeneral="Text">PDFDocument</resourceType>
<language>eng</language>
<dates>
<date dateType="Created">2025-09-25T11:30:21.856815Z</date>
</dates>
<subjects>
<subject>containers</subject>
<subject>orchestration</subject>
<subject>kubernetes</subject>
<subject>nomad</subject>
<subject>docker</subject>
<subject>microservices</subject>
</subjects>
<sizes>
<size>20232479 b</size>
</sizes>
<formats>
<format>application/pdf</format>
</formats>
<rightsList>
<rights rightsURI="http://rightsstatements.org/vocab/InC/1.0/">http://rightsstatements.org/vocab/InC/1.0/</rights>
</rightsList>
</resource>
