Telefon:
(0221) 95490614
Adresse:
skillbyte GmbH
Zollstockgürtel 57
50969 Köln
Ein kleines Beispiel: Das Unternehmen XYZ hat die Vorteile um Microservices, automatisierten Tests, Containern und CI/CD verstanden und hat es eingeführt. sie haben sich entschieden ihren software Monolithen in Modul A und Modul B zu zerteilen, die als eigenständige Services laufen. Ferner ein Modul C mit einigen neuen und unabhängigen Funktionen. Diese Module wurden in Container gepackt und unter Kubernetes deployed. Als sie anfingen diese Module in Produktion zu deployen stellten sie erste Probleme fest:
XYZ wurde langsam nervös und begann die Berater zu beschuldigen, die die tolle neue Welt versprochen hatten. Die Probleme sind aber nicht XYZ spezifisch, sondern inhärent in Service Orientierten Systemen:
Dies sind die Haupt Probleme, um serviceorientierte Architekturen auf Cloud Infrastruktur zu bauen. In den Zeiten vor der Cloud gab es diese Herausforderungen zwar auch, aber durch die vielen beweglichen Teil von Cloud Infrastrukturen werden die Probleme verstärkt.
Auch wenn wir als Nutzer der Cloud die aktuelle Hardware nicht sehen, Cloud Umgebungen bestehen aus einer riesigen Menge an beweglichen Teilen von Hardware und Software. Diese Komponenten sind virtualisierte Compute, Storage und Network Ressourcen welche wir per Self-Service API provisionieren können. Und: jede dieser Komponenten kann und wird ausfallen. In der Vergangenheit haben wir uns darauf konzentriert Infrastrukturen ausfallsicher zu machen und unsere Applikationen darauf aufzubauen mit Annahmen über Verfügbarkeit und Verlässlichkeit. In der Cloud: Pustekuchen! Geht nicht. Komponenten können und werden ausfallen; die ganze Zeit. Doch was ist die Lösung dann?
Nehmen wir an Service A ruft Service B auf und aufgrund irgend eines Problems antwortet Service B nicht. Dies kann ein Problem mit der Infrastruktur sein oder auch was völlig anderes. Service A kann nicht wissen was das Problem ist. Service A kann folgende Dinge probieren:
Diese Aufzählung hat einiges gemeinsam mit den Mechanismen in einem Packt Netzwerk wie TCP/IP, nur dass die Maßnahmen auf „Message“ Ebene greifen sollen und nicht auf Packet Ebene.
Was wir ausserdem verstehen wollen ist : Was geht vor sich in unserer Servicelandschaft, und zwar in Echtzeit. Welcher Service redet mit wem. Wie sieht ein typische, durchschnittliche Antwortzeit von Service B aus? Wir brauchen Logs, Metriken und Traces um zu verstehen wie Services miteinander interagieren.
Die ersten Unternehmen, die anfingen Ihre Applikationen in der Cloud zu betreiben waren große Internet Konzerne. Sie investierten viel Zeit und Geld um Software Bibliotheken zu bauen, die die oben genannten Anforderungen von Services in der Cloud zu gewährleisten. Z.B. baute Netflix:
Diese werden in vielen Java basierten Applikationen in der Cloud eingesetzt. Doch diese haben wiederum einige Nachteile: sie sind meist nicht sprachneutral. Die von Netflix erstellten Libraries können nur von Java Applikationen genutzt werden und sie sind nicht ganz trivial als Ganzes zu implementieren. Und das Wort sagt es schon: Implementieren, d.h. man muss die Anforderungen durch zu Hilfenahme dieser Libraries in Code gießen. Die Idee ist nun die Angelegenheit auf die Infrastruktur Ebene zu bringen. Also weg von den Entwicklern, hin zu den DevOps Kollegen, die es für die Applikationen deklarativ umsetzen. Und da sind wir bei dem Thema Service Mesh. Implementierungen hier sind Istio oder Linkerd. All die genannten Probleme lassen sich mit einem Service Mesh lösen und transparent darstellen. Der Entwickler muss sich um diese Themen nicht kümmern und kann sich auf Business Logik konzentrieren. Service Meshes verdienen sicherlich eigene Artikel. Damit ist diese Artikelreihe der Digitalen Transformation auf technischer Ebene vorbei. Wenn Sie Hilfe bei der Umsetzung oder eine Beratung über die erwähnten Technologien und Vorgehensweisen oder bei der Einführung von „DevOps“ im Unternehmen benötigen, dann kontaktieren Sie uns bitte.