The Doppler Quarterly (DEUTSCHE) Sommer 2018 | Page 26

Container Orchestration – Diese Plattformen –
beispielsweise Kubernetes, Swarm und Mesos –
zeichnen sich durch eine Leistungsfähigkeit aus, von
der Entwickler auf einer PaaS-Plattform oder ande-
ren konventionellen Entwicklungsplattformen nur
träumen konnten. Sie können portierbare Anwen-
dungen entwickeln und implementieren und überall
ausführen, ohne sie für unterschiedliche Umgebun-
gen neu konfigurieren und bereitstellen zu müssen.
Diese Fähigkeit verleiht Entwicklern eine enorme
Flexibilität und Kontrolle darüber, welche spezifi-
schen Imageversionen sie wo bereitstellen möchten.
Sie überblicken praktisch die gesamte Infrastruktur
und entscheiden letztendlich über Laufzeiten, die
Wiederverwendbarkeit von Images und die Umlage-
rung containerisierter Anwendungen in die Cloud.
Nachteile der Container Orchestration Der Prozess
wird komplexer. Der Aufbau eines hochverfügbaren
Kubernetes-Clusters ist keine leichte Aufgabe. Je
höher die Zahl der Container-Orchestratoren, umso
besser müssen Entwickler Dinge wie Serviceerken-
nung, Lastenausgleich, Kapazitätsmanagement, Über-
wachung, Protokollierung, Versionsupgrades und
andere allgemeine Services im Blick behalten. So müs-
sen Entwickler entweder eine schwierige Aufgabe
meistern oder auf verwaltete Kubernetes-Orchestra-
toren wie EKS, Fargate, AKS oder GKE zurückgreifen,
die eine gewisse Anbieterabhängigkeit mit sich brin-
gen und nicht immer auf dem neuesten Stand sind.
Serverless – Serverless-Plattformen verursachen
einen geringeren Arbeitsaufwand als Container-Or-
chestratoren. Dank Tools wie AWS Lambda, Azure
Functions oder IBM Openwhisk können Entwick-
lungsteams Logik in Codefragmente einbetten, um
auf spezifische Ereignisse zu reagieren. Bei Server-
less handelt es sich im Wesentlichen um einen Mana-
ged Service. Entwickler können sich auf Anwendun-
gen konzentrieren, die auf Auslöser reagieren, und
der Plattform den Rest überlassen – automatische
Skalierung, Patching, flexibler Lastenausgleich usw.
Eine hervorragende Voraussetzung für Entwickler,
die ein Pay-as-you-Go-Modell nutzen möchten, da
nur Gebühren entstehen, während der Code tatsäch-
lich ausgeführt wird. Die Lösung eignet sich gut für
ereignisgesteuerte, unvorhersagbare Workloads wie
IoT, Big Data und Messaging. Im Laufe der Zeit kön-
nen Middleware-Schichten optimiert werden, um die
Anwendungsleistung zu verbessern. Außerdem
ermöglicht das Serverless-Modell die einfache Integ-
ration in APIs und Plug-Ins von Drittanbietern.
24 | THE DOPPLER | SOMMER 2018
Aber es gibt auch Nachteile. Da Serverless ein weni-
ger ausgereiftes Computing-Modell ist, gibt es nicht
genügend umfassende Beispiele und Dokumentatio-
nen sowie zuverlässige Tools und Best Practices.
Auch das Debuggen gestaltet sich bei dieser Platt-
form schwieriger als bei anderen. Aufgrund der
On-Demand-Struktur können „Kaltstarts“ bei einem
inaktiven System Probleme verursachen. Darüber
hinaus sind Laufzeiten von Serverless-Workloads auf
fünf Minuten begrenzt. Alle längeren Vorgänge erfor-
dern eine zusätzliche Orchestrierung oder ein Refac-
toring in mehrere Mikroservices.
Wahl der richtigen Plattform
Für welche Plattform entscheiden Sie sich? Auf diese
Frage gibt es keine allgemeingültige Antwort, weil es
keine universelle Lösung gibt. Für bestimmte
Workloads sind Container besser geeigne