Der Mythos einer einzelnen Glasscheibe

Seit ich zurückdenken kann – und ich kann mich an eine lange Zeit erinnern – hat der Sirenengesang einer einzigen Glasscheibe, durch die man die Infrastruktur betrachten und bedienen kann, die IT angelockt. Wie der Heilige Gral wurde es nie entdeckt und viele IT-Experten sind zu Zynikern geworden, was seine Existenz betrifft.

Die digitale Transformation hat den letzten Nagel in den Sarg dieses mythischen Managementkonstrukts geschlagen und stattdessen ein neues hervorgebracht: eine einzige Kontrollebene.

Die gute Nachricht ist, dass im Gegensatz zu der einheitlichen Glasscheibe, die unerschrockene IT-Forscher der Vergangenheit anstrebten, eine einheitliche Kontrollebene in unserer Reichweite liegen könnte. Das liegt daran, dass es nicht auf einer GUI, sondern auf der API basiert.

Und nicht nur irgendeine API, sondern eine deklarative API.

Um zu verstehen, warum das so ist, lassen Sie mich in das Jahr 2010 zurückgehen, als der Begriff „Infrastruktur 2.0“ in Mode war.

Die unterste Ebene der Architektur bildet die Infrastruktur 2.0 . Bei Infrastructure 2.0 steht die Ermöglichung von Dynamik und Zusammenarbeit über die Netzwerk- und Application hinweg im Mittelpunkt. Auf diese Weise wird den (aus Kommunikations- und Verwaltungssicht) traditionell getrennten Grundkomponenten eines Rechenzentrums die Fähigkeit zur Verbindung und Zusammenarbeit verliehen. Dies wird vor allem durch offene, standardbasierte APIs erreicht, die einen detaillierten Satz an Betriebsfunktionen bereitstellen, die über eine Vielzahl von programmgesteuerten Methoden wie Orchestrierungssystemen, benutzerdefinierten Applications und durch die Integration mit herkömmlichen Rechenzentrumsverwaltungslösungen aufgerufen werden können. Bei Infrastruktur 2.0 geht es darum, das Netzwerk sowohl aus Verwaltungs- als auch aus Laufzeitsicht (Ausführung) intelligenter zu machen. Im Hinblick auf die Beziehung zur Cloud und zu IT as a Service konzentriert sich der Blick allerdings in erster Linie auf die Verwaltung.

Infrastruktur 2.0 umfasst die Service-Aktivierung von allem, von Routern bis zu Switches, von Lastenausgleichsmodulen bis zur Application , von Firewalls bis zu Application für Webanwendungen und Server-Infrastrukturen (physisch und virtuell). Im Wesentlichen handelt es sich dabei um API-fähige Komponenten.

Von < https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait >

Kommt Ihnen das bekannt vor? Wir nennen es nicht mehr Infrastruktur 2.0, sondern „kontinuierliche Bereitstellung“ und „Automatisierung“ und andere DevOps-artige Begriffe. Aber das Konzept ist dasselbe. In dieser Idee liegt auch der Grund, warum die Idee einer „einzelnen Glasscheibe“ nie verwirklicht wurde. Denn damit ein solches mythisches Konstrukt existieren kann, müsste eine einzige Lösung eine große Bandbreite an Netzwerk-, Application und Sicherheitslösungen umfassen (mit manuellen Methoden integrieren).

Das hätte nie passieren können.

Ehrlich gesagt, wäre das trotz der API-Fähigkeit des Großteils dieser Infrastruktur nie passiert . Warum? Denn all diese APIs waren zwingend erforderlich und ebenso eng mit dem Objektmodell der einzelnen Geräte verknüpft wie deren GUIs. Imperative APIs sind von Natur aus an geräte-/dienstspezifische Objektmodelle gebunden, die von denjenigen, die sie verwenden, eine große Belastung an betrieblichem Fachwissen abverlangen. Stellen Sie sich nun einen Alleskönner in Ihrer IT-Organisation vor, dem Sie die operative Verwaltung von Routern, Switches, Sicherheitsgeräten und fünf verschiedenen Kategorien von Application mehrerer Anbieter anvertrauen .

Genau. So eine Kreatur ist wie Bigfoot. Oft gehört, aber nie bewiesen, dass es sie gibt.

Was meine ich damit? Ich meine das:

Die Art und Weise, wie wir beispielsweise einen Pool oder eine VIP (virtuelle IP-Adresse) oder ein VLAN (virtuelles LAN) darstellen, ist nicht die gleiche, wie Cisco , Citrix oder Juniper dieselben Netzwerkobjekte darstellen. Tatsächlich kann unsere Terminologie sogar unterschiedlich sein; wir verwenden Pool, andere ADC-Anbieter verwenden „Farm“ oder „Cluster“, um dasselbe Konzept darzustellen. Kommt noch der Begriff Virtualisierung hinzu, so kommt ein weiterer Satz Begriffe hinzu, der häufig im Widerspruch zu den Begriffen steht, die von den Anbietern der Netzwerkinfrastruktur verwendet werden. Wenn der virtueller Server von einem Anbieter für Application verwendet wird, bedeutet er etwas völlig anderes als wenn er von einem Virtualisierungsanbieter wie VMWare oder Microsoft verwendet wird.

Von < https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards >

DAS ist der Grund, warum wir keine schönen Dinge wie eine einzelne Glasscheibe haben können. Weil die Branche nicht über eine einheitliche Glasscheibe verfügt, durch die sie die Infrastruktur betrachtet.

Aber dieser Beitrag soll Sie weder deprimieren, noch Sie auf den Weg zu einem IT-Dasein führen, das auf Dauer durch die Verwaltung einzelner Geräte beeinträchtigt wird. Im Gegenteil. Deklarative – wirklich deklarative – APIs können zu einer einzigen Kontrollebene führen.

Dazu müssen wir uns allerdings von der Vorstellung lösen, dass deklarativ bedeutet, unsere Gerätekonfigurationen in JSON oder YAML zu kodieren. Dies ist nicht wirklich deklarativ, da es immer noch auf betrieblichem Fachwissen basiert, das an gerätespezifische Objektmodelle gebunden ist – und niemand sonst kann diese aufnehmen und verwenden.

Lassen Sie mich Kubernetes-Dienst- und Endpunkt-Ressourcenbeschreibungen als Beispiel für ein deklaratives Modell verwenden:

Alles, was ich zum Konfigurieren eines virtueller Server brauche, finden Sie hier in diesen sehr prägnanten – und implementierungsunabhängigen – Definitionen. Die externe IP ist die virtuelle IP-Adresse – die Adresse, mit der der Benutzer oder die mobile App kommunizieren wird. Der Name „my-Service“ beschreibt einen virtueller Server, wobei die Spezifikation die Netzwerkdetails bereitstellt, beispielsweise welche Ports verwendet werden sollen und welcher Pool („MyApp“). Die Endpunktressourcen beschreiben jeden der Knoten, aus denen „mein Dienst“ besteht, und stellen die Mitglieder für den Pool „MyApp“ bereit. Das einzige, was hier fehlt, ist eine Möglichkeit, einen Lastausgleichsalgorithmus für die Dienste auszuwählen, der mehr kann als Round Robin.  Und wir könnten den Abschnitt „ Spezifikationen “ der Servicebeschreibung problemlos um einen „Algorithmus“ erweitern: RR | WRR | LC | FR“-Option, die universell auf alle Lastausgleichslösungen anwendbar ist. Dort. Erledigt.

Theoretisch kann ich diese gleiche Ressource einer von zehn verschiedenen Lastausgleichslösungen zuführen, und jede davon würde bestimmen, wie die Absicht der Beschreibung modelliert und implementiert wird – nämlich einen virtuellen Dienst an 80.11.12.10, Port 80 zu konfigurieren, der HTTP-Anfragen über zwei Application an 1.2.3.4 und 2.3.4.5 auf Port 80 skaliert.

Man kann sich das auch anders vorstellen, indem man den Unterschied zwischen „Ich hätte gern eine Pizza mit Peperoni“ und der langwierigeren Aussage „Ich möchte, dass du einen Pizzateig anrührst und ihn dann zu einem Kreis mit 25 cm Durchmesser ausrollst“ betrachtet. Mit Tomatensoße bedecken. Bedecken Sie es mit Mozzarella-Käse und verteilen Sie nun die Peperoni darüber. 15 Minuten bei 220 °C (425 °F) backen."

Eines dieser Dinge ist einfacher und erschließt Ihnen die Einzelheiten. Bei der anderen müssen Sie nicht nur wissen, was Sie wollen (Peperonipizza), sondern auch, wie Sie sie zubereiten. Das ist wirklich betriebswirtschaftliches Fachwissen.

Wie bei der Bestellung einer Pizza ist die Kubernetes-Ressourcenbeschreibung allgemein gehalten. Nichts darin erzwingt ein bestimmtes Objektmodell oder eine bestimmte Implementierungsmethode auf dem Gerät, das diese Ressource verbraucht. Es beschreibt, was vorhanden sein muss, hat aber keinerlei Einfluss darauf, wie ich es implementieren könnte.

Wirklich deklarativ zu sein bedeutet, die Möglichkeit zu bieten, die Absicht und den gewünschten Endzustand zu kommunizieren. Irgendwann in der Zukunft können wir einfach sagen: „Konfiguriere einen virtuellen Dienst für ‚meine App‘“ und voilà! Mithilfe von Metadaten und Application Tags sowie einer automatisierten, intelligenten Erkennung konfiguriert sich der Dienst von oben bis unten selbst*. 

Wenn wir jemals dieses Nirwana einer einzigen Kontrollebene erreichen wollen, müssen wir uns anstrengen und neutrale deklarative Spezifikationen entwickeln, die die Notwendigkeit beseitigen, jedes Gerät im Rechenzentrum über eine imperative API zu integrieren. Denn die gerätespezifische API-Integration unterscheidet sich eigentlich nicht groß von der gerätespezifischen Verwaltung.

Wir wollen schöne Dinge. Wir wollen eine einheitliche, einzelne Kontrollebene. Doch um dieses Ziel zu erreichen, muss die Branche mehr tun, als nur in Richtung deklarativer Ansätze zu nicken und zu erkennen, dass Ihre deklarative Schnittstelle gar nicht wirklich deklarativ ist, wenn niemand sonst sie aufnehmen und verwenden kann.

*Ein Mädchen darf träumen, oder nicht?