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.

 

 

 

Veröffentlicht am