In den letzten Jahren haben wir viel über die mangelnde Flexibilität im Bereich IT Operations gehört und gelesen. Sind solche Klagen berechtigt?
Diese Vorwürfe sind absolut berechtigt. In einem typischen Data Center kann es Tage dauern, bis eine neue Regel für die Firewalls oder Load Balancers implementiert ist und gar Wochen, um eine neue Applikation bereitzustellen. Das ist offensichtlich inakzeptabel.
Vergleichen Sie das einmal mit einem vernünftig ausgebauten Public-Cloud-Angebot. Auf Amazon Web Services kann der Applikationsverantwortliche die Sicherheitsregeln oder das Verhalten des Load Balancers innerhalb von Sekunden ändern. Dafür stehen einfache graphische Benutzerschnittstellen und APIs zur Verfügung.
Wie kam es dazu? Was ging schief?
Der Kardinalfehler war wahrscheinlich unser ungerechtfertigtes Vertrauen in die Allmacht von Infrastrukturtechnologie. Wir haben es den Anbietern von Infrastrukturlösungen erlaubt, uns dazu zu bringen, sämtliche Unzulänglichkeiten von Applikationen mit mehr und mit komplexerer Infrastrukturtechnologie zu überdecken. Die Alternative dazu wäre die Anpassung des Applikationsentwicklungsprozess an die Anforderungen. Es ist natürlich einfacher, den Darstellungen eines Whitepapers Glauben zu schenken. Stellt man diese aber in Frage und setzt an Stelle von mehr Hardware auf ziemlich einfache Regeln der Applikationsentwicklung, so kann das zu gut skalierbaren Applikationen führen. Grosse Webportale zeigen schon seit längerem, dass das geht.
Die vergrösserte Komplexität der IT-Infrastruktur (inklusive Rechner, Massenspeicher und Netzwerk) verbunden mit manueller Konfiguration von kritischen Komponenten hat zu einer immer grösseren Komplexität geführt, die nur schwer kontrollierbar ist. Einige Hersteller versuchen die augenscheinliche Komplexität mit einfach zu bedienenden graphischen Benutzerschnittstellen zu reduzieren. Diese helfen im Betrieb, die täglichen Arbeiten schneller auszuführen, versagen aber kläglich, wenn die darunterliegende lnfrastruktur ein unerwartetes Verhalten entwickelt.
Können Sie ein paar Beispiele nennen?
Fangen wir doch mit einem Produkt an, das wir alle kennen: VMWares High Availability soll die Verfügbarkeit von betriebskritischen Applikationen erhöhen. Viele Leute setzen es ein, ohne zu realisieren, dass es wohl gegen Hardware-Ausfälle schützt, nicht aber gegen Abstürze des Betriebssystems, Software-Bugs oder Fehler in der Applikationskonfiguration.
Wie gross ist die Anzahl von Server-Ausfällen im Vergleich zu anderen Ausfällen im Applikations-Stack? Wäre es nicht sinnvoll, sich auf alle anderen Ursachen für Applikations-Ausfälle zu konzentrieren und diese auszumerzen? Eine Architektur basierend auf horizontaler Skalierung mit redundanten Applikations-Server, die auf eine gemeinsam genutzte Datenbank zugreifen, bringt neben Ausfallsicherheit auch Kosteneffizienz und Skalierbarkeit.
Unabhängig davon, wie es eingesetzt wird, bleibt VMWares HA ein gutes Produkt, das eine signifikante operationelle Aufgabe erfüllt: Es stellt sicher, dass die virtuellen Maschinen (VM) nach einem Hardware-Ausfall wieder aufstarten. Das geht aber nicht ohne Einführung zusätzlicher Komplexität: In den meisten Fällen muss eine VM, die auf einem anderen physischen Server aufstartet, die selbe IP-Adresse verwenden, die von der VM auf dem ausgefallenen Server verwendet wurde. Um das zu bewerkstelligen, muss die IP-Adresse der ausgefallenen VM auf die neu gestartete VM übertragen werden. Dies wird üblicherweise mittels virtuellen LANs (VLAN) im Netzwerkbereich der Infrastruktur bewerkstelligt.
Sie haben das Thema VLANs aufgebracht. Sind sie so schlecht, wie manche Hersteller sie machen wollen?
VLANs sind weder gut noch schlecht, es kommt immer drauf an, für was man sie verwendet. Was oft vergessen geht, ist die Tatsache, dass jedes VLAN eine "Single Failure Domain" ist. Dehnt man ein einzelnes VLAN auf mehrer Rechenzentren aus – um VMWare HA Cluster über geographische Grenzen hinweg zu implementieren – so verbindet sich unbeabsichtigt auch das Schicksal von zwei oder mehr Rechenzentren: Ein Software- oder Hardware-Fehler in einem Rechenzentrum kann so zum totalen Zusammenbruch von mehreren Rechenzentren führen. Dies ist kein theoretisches Szenario, sondern ist schon mehr als einem meiner Kunden passiert.
Die Anbieter von Netzwerkprodukten arbeiten hart daran, um die Einschränkungen von VLANs zu umgehen. Es gibt neue Technologien im Bereich Data Center Fabric und neue Protokolle wie TRILL, SFB und OTV. Diese Technologien machen zwar VLANs stabiler, aber man bezahlt dafür mit noch mehr Technologien und noch mehr Protokollen in der Infrastruktur.
Die meisten grossen Webportale und Service Provider setzen auf skalierbare IP-Netzwerke, die auf den gleichen Architektur-Prinzipien wie das globale Internet beruhen. Applikationen sind so adaptiert, dass sie über diese stabile und skalierbare Infrastruktur betrieben werden können.
Was für eine Rolle spielen da Produkte für software-definierte Netzwerke (SDN) und software-definierte Rechenzentren (SDDC)?
Einige der aufkommenden Technologien adressieren die grundlegenden Probleme existierender Produkte. So erlauben Overlay Virtual Networks den Aufbau von Segmenten für Applikationen, ohne dass dabei Änderungen an der unterliegenden Netzwerkinfrastruktur notwendig sind. Damit fällt auch ein Grossteil des sonst benötigten Aufwands bezüglich der Überprüfung von Änderungen und des Bereitstellens von Wartungsfenstern weg. Die Virtualisierung von Netzwerkfunktionen (Network Function Virtualization/NFV) erlaubt die Bereitstellung von Netzwerkdiensten wie Firewalls und Load Balancer in virtueller Form, was der Flexibilität zugute kommt.
Leider gibt es keine Wunderlösung – die neuen Technologien und Produkte allein werden das Grundproblem nicht lösen. Um den schmerzhaften Prozess der Neugestaltung des gesamten Applikationsentwicklungs – und Bereitstellungsprozesses kommt man nicht drum herum. Die echten Vorteile dieser aufkommenden Technologien kommen erst voll zum Tragen, wenn das Applikationsentwicklungsteam die Verantwortung für die Bereitstellung und den Betrieb übernehmen muss.
Meinen Sie damit das, was mittels DevOps gelöst werden soll?
DevOps ist – wie auch Cloud – ein hübscher Oberbegriff für einen ganzen Bereich, der Prinzipien, Methodologien und Werkzeuge abdeckt. Was wirklich zählt, ist, dass alle Beteiligten – vom Applikationsentwickler bis zum Operations Engineer – zusammenarbeiten und sicherstellen, dass die bereitgestellten Applikationen die Geschäftserfordernisse der Organisation erfüllen.
Angenommen, ich stimme mit Ihnen überein. Wie kann ich diesen Prozess starten?
Wie bei jedem Paradigmenwechsel startet man mit kleinen Schritten und Pilotprojekten, welche die Skeptiker innerhalb der IT-Abteilung von der Viabilität des neuen Ansatzes überzeugen können.
Dieses Interview wurde am 21. August 2014 auf Inside-IT publiziert. Die englische Orginalfassung findet sich auf Ivan Pepelnjak's Blog auf IPspace.net.