Cloud-native vs. Rechenzentrum

Im ultimativen Infrastrukturvergleich treten zwei unterschiedliche Plattformansätze einer Anwendungsfamilie gegeneinander an. Anhand der Prinzipien der 12-Factor App vergleichen wir eine cloud-native mit einer Rechenzentrum-basierten Infrastruktur.

Teil 1: Einführung und Regeln

Nach fünf Runden endet das Duell – mit einem Sieg nach Punkten und wichtigen Erkenntnissen auf beiden Seiten:

Übersicht: Duell über fünf Runden

In einer Reihe von Beiträgen haben wir einen detaillierten Vergleich von Entwicklung und Betrieb zweier fachlich verwandter Anwendungen durchgeführt, wobei eine der beiden Applikationen (APP1) im Rechenzentrum (RZ) betrieben wird, wohingegen die andere (APP2) auf Cloud Foundry läuft. Hierbei haben wir gesehen, dass Best Practices für eine cloud-native Entwicklung, wie sie zum Beispiel in der 12-Factor App festgehalten sind und in APP2 umgesetzt werden, auch wertvollen Input für einen flexibleren und robusteren Betrieb im RZ liefern können.

Der Grund dafür ist, dass neben cloud-spezifischen Aspekten auch allgemeine Konzepte des Software-Designs sowie des Betriebs und der Entwicklung berücksichtigt werden. Insbesondere haben wir festgestellt, dass die meisten Aspekte auf einer agilen Kultur mit Fokus auf DevOps basieren. Sind solche Strukturen nicht ausreichend gewährleistet, lassen sich die Prinzipien der 12-Factor App nur sehr eingeschränkt umsetzen – sowohl in der Cloud als auch im RZ. Und genau an dieser Stelle haben wir einige der grundlegenden Probleme von APP1 identifizieren können. Die meisten der beschriebenen Schwierigkeiten haben ihren Ursprung in der strikten Trennung von Betrieb und Entwicklung.

Um besser abzuschätzen, inwieweit DevOps bzw. die in der 12-Factor App festgehaltenen Ideen helfen können, diese Probleme zu überwinden, haben wir anhand ausgewählter Faktoren den Status Quo in APP1 und APP2 beschrieben und Vorschläge für eine Adaption der Faktoren im RZ präsentiert. Die zentralen Ergebnisse zu den verschiedenen Faktoren sind noch einmal in der folgenden Tabelle zusammengefasst:

Faktor	APP1	APP2
Config – Store config in the environment	Konfigurationen werden in im Code in Form von application-<STAGE>.yml Dateien stage-abhängig gepflegt. Theoretisch ist es im RZ möglich, auf Umgebungsvariablen zur Konfigurationspflege zu setzen. In diesem Fall empfehlen wir das Management der Umgebungen in Form von Skripten etc. zu automatisieren.	Die Mechanismen von Cloud Foundry und Spring Boot werden verwendet. Der Code ist vollständig stage-unabhängig. Eine Codebasis dient als Grundlage für alle stages. Somit können schnell und nach Bedarf stages hinzugefügt (und wieder entfernt) werden.
Backing Services – Treat backing services as attached resources	Wird aufgrund der im RZ etablierten Prozesse nicht konsequent umgesetzt. Der Bedarf an Infrastruktur und deren Wartung erschwert die Realisierung zusätzlich. Ein stärkerer Fokus auf DevOps kann helfen, die Umsetzung dennoch zu ermöglichen.	APP2 verwendet Dienste (zum Beispiel Caching oder Logging) über Netzwerkprotokolle wie http. Die Anbindung erfolgt automatisiert und wird durch die Entwickler umgesetzt. Die Dienste können einfach ausgetauscht werden. Bei Bedarf können Ressourcen unabhängig skaliert werden.
Port Binding – Export services via port binding	Der Betrieb erwartet die Auslieferung als .war Datei. Statt des integrierten Spring Boot Tomcats muss pro stage und pro server dediziert eine Tomcat-Instanz installiert und gewartet werden. Dies erhöht das Fehlerpotenzial durch unterschiedliche Konfiguration.	Die Anwendung wird als .jar ausgeliefert. Das gleiche Artefakt wird auf die unterschiedlichen stages deployed. Infrastructure-as-code minimiert zusätzlich Fehlerpotenzial durch manuelle Anpassungen.
Dev/Prod parity – Keep development, staging and production as similar as possible	Hier wird versucht manuell sicherzustellen, dass die stages sich möglichst gleichen. Ein solcher Prozess ist fehleranfällig und führt zu Verzögerungen bei Auslieferungen. Automatisierung durch Skripte, sowie engere Zusammenarbeit von Betrieb und Entwicklung im DevOps Sinne wären hier hilfreich und durchaus umsetzbar.	Cloud Foundry stellt die Infrastruktur für alle stages gleichartig bereit. Durch Infrastructure-as-code und passende Skripte wird in APP2 automatisiert sichergestellt, dass die stages sich gleichen. Nachdem die Entwickler zudem die Hoheit über die Deployment Pipelines haben, führt dies zu einfachen und schnelleren Deployments.
Logs – Treat logs as event streams	Eventbasiertes Logging mit grafischer Aufbereitung wird durch Splunk ermöglicht. Zuvor wurden die Logs auf den Servern abgelegt und mussten dort mühsam analysiert werden. Die strikte Trennung von Dev und Ops hat zu Verzögerungen bei der Einführung von Splunk geführt.	Kibana und ElasticSearch werden im Sinne des Backing Services Faktors an die Anwendung gebunden. Anpassungen können von den Entwicklern vorgenommen werden und erfordern somit keinen aufwändigen Prozess.

Fazit

Zusammenfassend werden hier zwei grundlegende Probleme bei APP1 deutlich. Zum einen führt die strikte Trennung von Entwicklung und Betrieb zu Verzögerungen und schränkt die Flexibilität stark ein. Zum anderen gibt es eine Vielzahl manueller Prozesse, wie das Mikromanagement der Infrastruktur, die zu Fehlern führen.

Es ist jedoch klar, dass die genannten Probleme nicht exklusiv für das RZ sind. Auch in der Cloud würden sie die Flexibilität drosseln und das Fehlerpotenzial erhöhen (obwohl Abstraktionen wie Infrastructure-as-a-Service oder Platform-as-a-Service die Gefahr manueller Fehlkonfigurationen zumindest auf Serverebene einschränken, nicht jedoch auf Ressourcenebene).

Die wesentlichen Take-aways die wir dem Leser mit dieser Reihe an Beiträgen daher auf den Weg geben wollen, sind folgende:

Die Cloud ist der optimale Rahmen, um skalierbare und flexible Anwendungen zu entwickeln, vorausgesetzt die Entwicklung folgt entsprechenden Empfehlungen, wie zum Beispiel der 12-Factor App im Falle von Cloud Foundry. In diesem Fall bietet uns die Plattform viele Mechanismen, die uns die Arbeit vereinfachen und gleichzeitig Skalierbarkeit und Portierbarkeit sicherstellen.
Best Practices für cloud-native Anwendungen sollten auch bei der Entwicklung und beim Betrieb von Applikationen im RZ in Betracht gezogen und wenn sinnvoll für den eigenen Use Case adaptiert werden. Das bedeutet nicht, dass jeder der Faktoren eins-zu-eins im RZ umgesetzt werden muss. Vielmehr ist es wichtig abzuwägen, welche Aspekte davon uns tatsächlich dabei helfen, schneller und stabiler zu entwickeln, um somit die Kundenzufriedenheit zu maximieren. Grundvoraussetzung hierfür ist das passende Mindset und Automatisierung.
Die beiden obigen Punkte können nur dann optimal umgesetzt werden, wenn Entwicklung und Betrieb in engem Austausch sind bzw. eine Kultur der Eigenverantwortung und des Vertrauens etabliert sind. Dieser DevOps-Gedanke erfordert aber auch Lernbereitschaft und das aktive Mitwirken aller Beteiligten.

Noch Fragen?

Weitere Informationen und Hilfestellungen rund um die Gestaltung und Weiterentwicklung hochperformanter IT-Infrastrukturen und Applikationslandschaften finden Sie unter:

Mehr zu Infrastruktur & Cloud

Cloud-native vs. Rechenzentrum – Entscheidung nach Punkten