Ihr DevOps-Team, Webentwickler oder erfahrener Hosting-Partner spricht von Cloud, Containern und Kubernetes als Zukunftslösung zur effizienten Skalierbarkeit Ihrer Webapplikation? Wir erklären Ihnen worüber Ihre IT-Projektleiter sprechen, welche Vorteile Cloud-Lösungen gegenüber traditionellen Methoden haben, was Ihnen Kubernetes bietet und ob der vermeintliche Cloud-Himmel wirtschaftlich sinnvoll oder ein Fass ohne Boden für Sie ist.

Der Cloud Gott und seine Marketing-Apostel

Cloud-Dienst hier, Cloud-Computing da, Containering, Docker, Kubernetes. Die Unendlichkeit! Alles Cloud – Alles kein Problem! Die Sprachrohre von Clouddienst-Anbietern versprechen Ihnen alles, was Sie sich immer gewünscht haben. Die Worttraube „Cloud“ besitzt zweifelsohne Strahlkraft und ist im Mainstream überwiegend positiv besetzt. Der Heilbringer, der all Ihre Probleme und betriebsbedingten IT-Aufwände in Luft auflöst ist in der Praxis leider nur selten zu finden. Zweifelsfrei liegen die Kostenersparnisse für eine komplett ausgelagerten IT-Infrastruktur für Ihren Softwarebetrieb auf der Hand. Klein- und mittelständische Unternehmen können so ohne große Aufwände für On-Premise Hardware und IT-Personal sofort loslegen. In der Praxis bleibt das süße IT-Leben auf Wolke 7 immer öfters aus. Setzen signifikante Einsparungen bei Inhouse Personal und On-Premise Hardware an der falschen Stelle an, geht die Rechnung der Cloud-Investition nicht auf.

 

Der Mythos Cloud-Himmel

Während serverbasierte Lösungen seit Jahren erfolgreich extern administriert werden, tritt bei cloud-nativen Lösungen ein zusätzlicher Layer an Administration und Zuständigkeiten aufs Parkett. Software, Applikationen und CMS ohne nativen Cloud-Support sind ohne zusätzliche Programmierarbeiten und Software-Adaption nicht in ein echtes cloud-basiertes System implementierbar. Eine Inkompatibilität, die vor jeder Inbetriebnahme containerbasierter Dienste abgeklärt werden muss. Neben den genannten Initialaufwendungen für die Adaption bereits bestehender Applikationen werden zusätzlich laufende betriebsbedingte Aufwendungen in Form von IT-Personal anfallen. Cloud-Anbieter stellen Infrastruktur und Architektur zur Verfügung. Ihr Ansprechpartner kümmert sich um den reibungslosen Betrieb, stellt Ihnen alle Schalter und Hebel zur Verfügung, um Funktionen und Applikationen erfolgreich in cloud-native Systeme zu integrieren. Bedienen werden Sie Hebel und Schalter jedoch selber müssen. Die vermeintlich kosteneinsparende Cloud-Alternative kann sich so durch zusätzlich benötigtes 24/7 DevOps-Personal rasch zum Kosten-Boomerang entwickeln. Vorausgesetzt Sie finden es. IT-Personal mit fundierter Fachkenntnis zur Administration cloud-nativer Dienste und Containering sind rar.

 

Die Cloud ist ein alter Hut

Cloud-Technologie ist für die IT nichts Neues. Alle nicht On-Premise Lösungen für Unternehmen lassen sich prinzipiell als Cloud-Lösungen bezeichnen. So ist jede Webapplikation die auf Hosting-Servern läuft, technisch gesehen in der Cloud. Und das schon seit Jahrzehnten. Viel wichtiger ist, ob Ihre Webapplikation cloud-native ist.

Die klassische Methode Ihre Applikationen zu betreiben geht den Weg über einzelne Server: Die Installation der Anwendung auf einem Server mit eigenständigem Betriebssystem und Paket-Manager. Dabei sind Dateien, Konfigurationen und Libraries unweigerlich an das Betriebssystem des Servers gekoppelt. In der Praxis ist diese Methode weniger komplex und dadurch auch oft weniger fehleranfällig. Werden Infrastruktur und Server an Managed Service-Provider ausgelagert, können Kosten für zusätzliches Inhouse-IT-Personal und Hardware komplett eingespart werden. Ihre Daten sind in der „Cloud“. Cloud-native müssen sie deshalb aber nicht sein.

Der neue cloud-native Weg heißt Containering. Container besitzen ein eigenes Dateisystem, sind vom Host-Dateisystem entkoppelt und agieren flexibel im Ressourcenverbrauch. Container-Images sind so über Cloud-Dienste sowie Betriebssysteme hinweg einsetzbar, frei konfigurierbar und bieten eine effiziente Anwendungsbereitstellung. Der versprochene reibungslose Betrieb verlangt allerdings Personal mit Container-Kenntnissen und setzt Applikationen voraus, die cloud-native betrieben werden können.

 

Rudimentärer Vergleichsaufbau zwischen Non-Portable Serverbetrieb und Portable cloud-nativem Containering

Stehen Sie vor der Entscheidung Containering in Ihr System zu implementieren, klären Sie alle Fragen, die Ihre betriebsrelevanten Anwendungen und Applikationen betreffen. Versuchen Sie sich in einer Einschätzung der zusätzlichen Personalkosten und stellen Sie einen Kostenplan für mindestens fünf Jahre auf, in dem Sie klassische Serverlösung und cloud-nativen Betrieb gegenüberstellen. Beginnen Sie damit, Ihre IT-Abteilung zu fragen, welche betriebsrelevanten Applikationen cloud-native Unterstützung besitzen.

 

Die Hybrid-Wahrheit

Prinzipiell lässts sich beinahe jede Applikation in Container betreiben. Um nicht-cloud-native-Anwendungen in Container zu verfrachten, sind aber nicht selten tiefgehende Software-Änderungen nötig. Je nach Applikation können hier hohe zusätzliche Aufwände entstehen. Besonders gut für Containering geeignet sind horizontale Prozesse und Funktionen Ihrer Applikation, die bestmöglich unabhängig von Datenbanken skaliert werden können. Fragen Sie nicht nach dem „ob“. Viel wichtiger bei der Entscheidung zwischen Container und klassischen Server ist die Frage nach dem „wofür“. Nicht jede Anwendung ist für Containering konzipiert. Lassen Sie sich nicht von der „Container“ und „Cloud“-Trendwelle überrollen, sondern holen Sie mehrere unabhängige Meinungen ein. Eine genaue Abschätzung, ob und inwiefern Containering Sinn für Ihre Applikationen und Dienste macht, können unvoreingenommene FachexpertInnen einschätzen, die sowohl Ihre Anwendungen, Ihr Hosting Setup, Ihre Virtual-Machines und Ihr Containering genauestens kennen. Sie werden bereits bei der Abklärung betriebsrelevanter Applikationen merken, dass ein Großteil keine cloud-native Lösungen besitzt. Als Beispiel: Der CMS-Gigant WordPress, der zwischen 60-70 Prozent Marktanteil besitzt, bietet keine cloud-native Unterstützung. Spätestens bei der Cloud-native-Checkliste endet der wolkige Traum. In der Praxis findet sich nach dem anfänglichen Cloud-Enthusiasmus zumeist eine Hybrid-Lösung: Eine Kombination von Server- und Cloud-Diensten.

 

Cloud All-In

Obwohl die Kosten-Nutzen-Analyse gegenteiliges behauptet: Sie wollen die All-In-Cloud-Lösung. Die komplexe Netzwerk-Architektur macht Cloud-Containering zur Herausforderung. Da Container im Gegensatz zu Server kein für sich alleinstehendes System, sondern ein Netzwerk aus Funktionen bildet, stellt Containering besondere Ansprüche an Ihre Architektur. Um der Funktionskomplexität einzelner Container Herr zu werden und mehrere laufende Applikationen gleichzeitig zu managen, empfiehlt sich ein System zur Container Orchestration. Ein Container Orchestration-System stellt Ihnen alle Mittel des Container-Managing zur Verfügung: Provisionierung, Konfiguration, Scaling, Allocation, Load Balancing, Health Monitoring, u.v.m. All das setzt voraus, dass Funktionen Ihrer Applikation cloud-native eingebunden werden können. Um Überraschungen zu vermeiden, prüfen Sie jedenfalls vorab Ihre Applikationen und rechnen Sie bei nicht cloud-nativen Anwendungen mit erheblichen Kosten für Programmierung und Adaption. Sprechen Sie sich gründlich mit Ihrem erfahrenen Business-Hosting-Anbieter ab. internex-TechnikerInnen besitzen reichlich Erfahrung und kennen die Fallstricke bei der Implementierung von Cloud-Diensten und Containering.

 

Komplexes Containering richtig steuern

Je nach Komplexität und Architektur empfehlen wir die Verwendung eines Orchestration Systems. Der Markt bietet etliche Anbieter zur erfolgreichen Container-Cluster-Steuerung. Die meisten davon basieren auf einer Adaption des ursprünglich von Google entwickelten Kubernetes. Kubernetes fasst multiple Container in einer Überkategorie namens Pods zusammen und trägt erheblich zur Betriebserleichterung bei. Ein Kubernetes-Cluster kann so mehrere Pods innerhalb einer ausführenden Node besitzen. Eine übergeordnete Master-Node managed dabei Funktionen und Komponenten aller Nodes und die darin befindlichen Pods.

 

Unter Last skaliert das System in Echtzeit flexibel und mit den Anforderungen mit. Je nach Bedarf werden so Container gestartet und wieder entfernt. Service-Updates geschehen ohne Server-Downtime. Funktions-Updates werden per Container Stück für Stück, in den laufenden Betrieb integriert. Ein Traum der CI/CD-Zuständigen wird wahr. Die größte Herausforderung liegt in der Komplexität des Erstellens, Betreibens und Updates eines Kubernetes-Clusters. Kluge Köpfe, viel Erfahrung und der richtige Partner sind Voraussetzung für die erfolgreiche Implementierung. Bei internex finden Sie all das an einem Ort. Wir klären gemeinsam unverbindlich mit Ihnen Ihre ersten Fragen zur cloud-native Checkliste, Hybrid-Lösung und Kubernetes Orchestration.

Unsere TechnikerInnen freuen sich auf Sie. Kontaktieren Sie uns noch heute.