Über DevOps und Snowflakes

Man kann heutzutage in der IT kaum die sprichwörtliche Katze schwingen, ohne dass Menschen über DevOps reden. DevOps ist das heiße neue Thema in der Branche, das dort anknüpft, wo das Gerede über die Cloud aufgehört hat, und wenn man Menschen darüber reden hört, könnte man glauben, dass die traditionelle Systemadministration bereits tot und begraben ist.

Zunächst müssen wir darüber sprechen, was wir mit DevOps meinen. Dies kann verwirrend sein, denn wie bei der Cloud wird oft ein älterer Begriff entwendet, um etwas anderes zu bezeichnen oder, bestenfalls, etwas, das mit bereits Existierendem verwandt ist. Traditionelles DevOps war die Verschmelzung von Entwickler- und Betriebsrollen. Von den 1960er bis in die 1990er Jahre war dies die übliche Art, Systeme zu betreiben. In dieser Welt waren die Menschen, die die Software schrieben, im Allgemeinen dieselben, die sie bereitstellten und warteten. Daher die Verschmelzung von „Entwickler“ und „Betrieb“, wobei Betrieb ein halb-standardisierter Begriff für die Rolle des Systemadministrators ist. Diese Rollen wurden bis zum Aufstieg der „IT-Abteilung“ in den 1990er und 2000er Jahren nicht häufig voneinander getrennt. Seitdem hat die Rückkehr zur Verschmelzung der beiden Rollen wieder an Beliebtheit gewonnen, in erster Linie aufgrund der Art und Weise, wie die beiden in vielen modernen, gehosteten Webanwendungssituationen mit großem Nutzen zusammenarbeiten können.

Wo heute oft über DevOps gesprochen wird, ist nicht als strikte Verschmelzung der Entwickler und des Betriebspersonals, sondern als eine Modifikation des Betriebspersonals mit einem wesentlich stärkeren Fokus auf das Programmieren – nicht der Anwendung selbst, sondern auf die Definition von Anwendungsinfrastrukturen als Code, als natürliche Erweiterung von Cloud-Architekturen. Dies kann zunächst recht verwirrend sein. Wichtig festzuhalten ist, dass traditionelles DevOps nicht das ist, was heute üblicherweise geschieht, sondern ein neues „falsches“ DevOps, bei dem Entwickler Entwickler bleiben und der Betrieb der Betrieb bleibt, der Betrieb sich aber zu einer neuen „codelastigen“ Rolle entwickelt hat, die sich weiterhin auf die Verwaltung von Servern konzentriert, auf denen von den Entwicklern bereitgestellter Code läuft.

Bedeutsam ist heute, dass die Rolle des Systemadministrators begonnen hat, sich in zwei verwandte, aber deutlich unterschiedliche Rollen aufzuspalten, von denen eine von den meisten in der Branche heute fälschlicherweise als DevOps bezeichnet wird (wobei der Großteil der Branche zu jung ist, um sich an die Zeit zu erinnern, als DevOps die Norm war, nicht die Ausnahme, und gewiss nichts Neues und Neuartiges). Ich bezeichne diese beiden Aspekte der Systemadministratorrolle hier als die DevOps- und die Snowflake-Ansätze.

Ich verwende den Begriff Snowflake, um auf traditionelle Architekturen für Systeme zu verweisen, da jeder einzelne Server als „einzigartige Schneeflocke“ betrachtet werden kann. Sie sind alle unterschiedlich, zumindest insofern, als sie nicht auf irgendeine Weise so verwaltet werden, dass sie identisch gehalten werden. Das bedeutet nicht, dass sie alle einzigartig sein müssen, sondern nur, dass sie das Potenzial behalten, es zu sein. In traditionellen Umgebungen meldet sich ein Systemadministrator bei jedem Server einzeln an, um daran zu arbeiten. Ein gewisses Maß an Scripting ist üblich, um Administrationsaufgaben zu erleichtern, doch im Kern umfasst die Rolle viel Zeit, die mit der Arbeit an einzelnen Systemen verbracht wird.

Die Erleichterung der Administration von Snowflake-Architekturen umfasste oft Versuche, Unterschiede zwischen Systemen auf vernünftige Weise zu minimieren. Dies beginnt im Allgemeinen mit Dingen wie der Wahl eines einzigen Standardbetriebssystems und einer Standardversion (Windows 2012 R2 oder Red Hat Enterprise Linux 7), statt zuzulassen, dass jede Serverinstallation ein anderes Betriebssystem oder eine andere Version ist. Diese Standardisierung mag grundlegend erscheinen, doch vielen Betrieben fehlt diese Standardisierung selbst heute noch.

Ein nächster Schritt ist häufig die Erstellung einer standardisierten Bereitstellungsmethodik oder eines Golden-Master-Images, das zur Erstellung aller Systeme verwendet wird, sodass das Basisbetriebssystem und alle Basispakete, oft einschließlich Systemanpassungen, Monitoring-Pakete, Sicherheitspakete, Authentifizierungskonfiguration und ähnlicher Modifikationen, standardisiert und einheitlich bereitgestellt werden. Dies bietet einen gemeinsamen Ausgangspunkt für alle Systeme, um Abweichungen zu minimieren. Doch technisch gesehen gewährleisten sie nur einen standardisierten Ausgangspunkt, und im Laufe der Zeit muss mit Abweichungen in der Konfiguration gerechnet werden.

Über diese Schritte hinaus verwenden Snowflake-Umgebungen typischerweise individuelle, maßgeschneiderte Administrationsskripte oder Verwaltungstools, um im Laufe der Zeit eine gewisse Standardisierung zwischen den Systemen aufrechtzuerhalten. Je mehr Gemeinsamkeiten zwischen Systemen bestehen, desto einfacher sind sie zu warten und zu beheben und desto weniger Wissen wird vom Administrationspersonal benötigt. Mehr Standardisierung bedeutet weniger Überraschungen, weniger Unbekannte und wesentlich bessere Testmöglichkeiten.

In einer Umgebung mit einem einzigen Systemadministrator mit guten Praktiken und Werkzeugen können Snowflake-Umgebungen ein hohes Maß an Standardisierung annehmen. Doch in Umgebungen mit vielen Systemadministratoren, insbesondere solchen, die rund um die Uhr aus vielen Regionen unterstützt werden, und mit einer großen Anzahl von Systemen kann die Standardisierung selbst bei sehr gewissenhaften Praktiken sehr schwierig werden. Und das, noch bevor wir die offensichtlichen Probleme rund um die Tatsache angehen, dass auf Systemen, die unterschiedliche Rollen erfüllen, unterschiedliche Pakete und möglicherweise unterschiedliche Paketversionen benötigt werden.

Der DevOps-Ansatz erwächst organisch aus dem Cloud-Architekturmodell. Cloud-Architektur ist um automatisch erstellte und automatisch zerstörte, weitgehend identische Systeme (zumindest in Gruppen) herum konzipiert, die über eine programmatische Schnittstelle oder API gesteuert werden. Dieses Modell eignet sich, ganz offensichtlich, für eine zentrale Steuerung über ein Verwaltungssystem statt über die manuellen Bemühungen eines Systemadministrators. Manuelle Administration ist unter diesem Modell faktisch unmöglich und völlig unpraktikabel. Einzelne Systeme sind nicht einzigartig wie im Snowflake-Modell, und jede Abweichung wird ernsthafte Probleme verursachen.

Die Idee, die aus der Welt der Cloud-Architektur hervorgegangen ist, lautet, dass die Systemarchitektur zentral „im Code“ definiert werden sollte und nicht auf den Servern selbst. Das klingt zunächst verwirrend, ergibt aber viel Sinn, wenn wir es genauer betrachten. Um dieses Modell zu unterstützen, hat sich eine neue Art von Systemverwaltungstool herauszubilden begonnen, das sich noch keinen wirklich standardisierten Namen zugelegt hat, aber oft als Systemautomatisierungstool, DevOps-Framework, IT-Automatisierungstool oder schlicht „Infrastructure as Code“-Tool bezeichnet wird. Zu den gängigen Toolsets in diesem Bereich gehören Puppet, Chef, CFEngine und SaltStack.

Die Idee hinter diesen Automatisierungs-Toolsets ist, dass ein zentraler Dienst verwendet wird, um alle Systeme zu verwalten und zu steuern. Diese zentrale Instanz verwaltet einzelne Server mittels codebasierter Beschreibungen dessen, wie das System aussehen und sich verhalten soll. In der Welt von Chef werden diese, um niedlich zu sein, „Recipes“ (Rezepte) genannt, doch die Analogie funktioniert gut. Der Code jedes Systems könnte Informationen enthalten wie eine Liste, welche Pakete und Paketversionen installiert werden sollen, welche Systemkonfigurationen geändert werden sollen und welche Dateien auf die Maschine kopiert werden sollen. In vielen Fällen werden Entscheidungen über diese Bereitstellungen oder Modifikationen über potenziell komplexe Logik gehandhabt, und daher die Notwendigkeit von tatsächlichem Code statt etwas Simplerem wie Markup oder Templates. Systeme werden dann nach Rolle gruppiert und als Gruppen verwaltet. Die Rolle „Webserver“ könnte einem Satz von Systemen mitteilen, Apache und PHP zu installieren und den Speicher so zu konfigurieren, dass nur sehr wenig ausgelagert wird. Die Rolle „SQL Server“ könnte MS SQL Server und spezielle Backup-Tools installieren, die nur für diese Anwendung verwendet werden, und den Speicher so konfigurieren, dass er wie gewünscht für einen Pool von SQL-Server-Maschinen abgestimmt ist. Dies sind lediglich Beispiele. Typischerweise hätte eine Organisation sehr viele Rollen, manche mögen generisch sein wie „Webserver“ und andere wesentlich spezifischer, um ganz bestimmte Anwendungen zu unterstützen. Rollen können im Allgemeinen geschichtet werden, sodass ein System sowohl ein „Webserver“ als auch ein „Java-Server“ sein könnte, wobei die kombinierten Anforderungen beider erfüllt werden.

Diese standardisierten Definitionen bedeuten, dass Systeme, sobald sie als zu der einen oder anderen Rolle gehörig bestimmt wurden, sich automatisch „selbst aufbauen“ können. Ein neues System könnte erstellt werden, indem ein Administrator ein System anfordert, oder ein Kapazitätsüberwachungssystem könnte entscheiden, dass zusätzliche Kapazität für eine Rolle benötigt wird, und ohne jegliches menschliches Eingreifen automatisch neue Serverinstanzen erzeugen. Zum Zeitpunkt, an dem das System angefordert wird, sei es durch einen Menschen oder automatisch, wird die Rolle bestimmt, und das System wird sich mittels des Automatisierungs-Frameworks in einen vollständig konfigurierten und aktuellen „Node“ verwandeln. Kein menschliches Eingreifen in die Systemadministration erforderlich. Der Prozess ist schnell, einfach und, was am wichtigsten ist, vollständig wiederholbar.

Die Definition von Systemen im Code hat einige nicht offensichtliche Konsequenzen. Eine davon ist, dass Backups vollständiger Systeme nicht mehr benötigt werden. Warum ein System sichern, das Sie mit minimalem Aufwand nahezu sofort neu erstellen können? Lokale Daten von Datenbanksystemen müssten gesichert werden, aber nur die Datenbankdaten, nicht das gesamte System. Dies kann die Belastung von Backup-Infrastrukturen erheblich reduzieren und Wiederherstellungsprozesse schneller und zuverlässiger machen.

Die Menge an Dokumentation, die für bereits im Code definierte Systeme benötigt wird, ist sehr gering. In Snowflake-Umgebungen muss der Systemadministrator für jeden Host spezifische Dokumentation pflegen und diese Dokumentation manuell aktuell halten. Dies ist sehr zeitaufwendig und fehleranfällig. Systeme, die mittels zentralem Code definiert sind, benötigen wenig bis keine Dokumentation, und die Dokumentation kann auf Gruppenebene gehandhabt werden, nicht auf der Ebene der einzelnen Nodes.

Das Testen von Systemen, die im Code definiert sind, ist ebenfalls einfach zu bewerkstelligen. Sie können ein System mittels Code erstellen, es testen und wissen, dass das Produktionssystem, wenn Sie diese Definition in die Produktion überführen, wiederholbar genau so erstellt wird, wie es in der Testumgebung erstellt wurde. In Snowflake-Umgebungen ist es sehr verbreitet, Testpraktiken zu haben, die versuchen, dies zu tun, dies jedoch über manuelle Bemühungen tun und anfällig dafür sind, schlampig und nicht exakt wiederholbar zu sein, und sehr oft wird die Politik diktieren, dass es schneller ist, Wiederholbarkeit vorzutäuschen, als sie tatsächlich anzustreben. Im Code definierte Systeme umgehen diese Probleme und machen das Testen weitaus wertvoller.

Abgesehen davon, dass eine Anzahl von Nodes definiert werden muss, die innerhalb jeder Rolle existieren sollen, kann das System eine gesamte Architektur von Grund auf automatisch neu bereitstellen. Der Wiederaufbau nach einer Katastrophe oder die Inbetriebnahme eines sekundären Standorts kann sehr schnell und einfach erfolgen. Auch der Wechsel zwischen lokal gehosteten Systemen und remote gehosteten Systemen, einschließlich solcher von Unternehmen wie Amazon, Microsoft, IBM, Rackspace und anderen, ist äußerst einfach.

Natürlich liegt in der DevOps-Welt ein großer Wert darin, Cloud-Architekturen zu nutzen, um das extremste Maß an Automatisierung zu ermöglichen, doch die Nutzung von Cloud-Architekturen ist nicht erforderlich, um diese Arten von Tools zu nutzen. Und natürlich könnte eine im Code definierte Architektur teilweise verwendet werden, während für einen hybriden Ansatz auch manuelle Administration implementiert werden könnte, doch dies wird auf einzelnen Systemen selten empfohlen. Es ist im Allgemeinen weitaus besser, zwei Umgebungen zu haben, eine, die als Snowflakes verwaltet wird, und eine, die als DevOps verwaltet wird, wenn die beiden Ansätze vorgeschrieben sind. Dies ergibt eine weitaus bessere Hybridisierung. Ich habe erlebt, dass dies in einer Unternehmensumgebung mit mehreren Zehntausenden von „Snowflake“-Servern, jeder davon sehr einzigartig, äußerst gut funktioniert hat, daneben aber mit einer dedizierten Umgebung von zehntausenden Nodes, die auf DevOps-Weise verwaltet wurde, weil alle Nodes identisch und austauschbar sein sollten, unter Verwendung einer von zwei möglichen Konfigurationen. Die Hybridisierung war sehr effektiv.

Der DevOps-Ansatz bringt jedoch ebenfalls erhebliche Vorbehalte mit sich. Die Kompetenzen, die erforderlich sind, um ein System auf diese Weise zu verwalten, sind weitaus umfangreicher als jene, die für die traditionelle Systemadministration benötigt werden, da, mindestens, weiterhin das gesamte traditionelle Wissen der Systemadministration benötigt wird, hinzu kommen solide Programmierkenntnisse, typischerweise in modernen Sprachen wie Python und Ruby, sowie Kenntnisse der jeweiligen spezifischen Frameworks. Diese erweiterte Anforderung an die Wissensbasis bedeutet, dass DevOps-Praktiker nicht nur selten, sondern auch teuer sind. Sie bedeutet auch, dass die universitäre Ausbildung, die ohnehin weit davon entfernt ist, Systemadministratoren oder Entwickler auf die Berufswelt vorzubereiten, nun noch weiter davon entfernt ist, Absolventen auf die Arbeit unter einem DevOps-Modell vorzubereiten.

Systemadministratoren, die in jedem dieser beiden Lager arbeiten, neigen dazu, alle Systeme so zu sehen, als müssten sie in ihre eigene Form passen. Neue DevOps-Praktiker glauben oft, dass Snowflake-Systeme veraltet sind und aktualisiert werden müssen. Snowflake-Administratoren (traditionelle) neigen dazu, die „Infrastructure as Code“-Bewegung als albern zu betrachten, voller unnötigem Overhead, übermäßig kompliziert und sehr nischenhaft.

Die Realität ist, dass beide Ansätze außerordentlich viel Verdienst haben und beide äußerst praktikabel bleiben werden. Beide ergeben für sehr unterschiedliche Workloads Sinn, und große Organisationen werden, so vermute ich, häufig beide über irgendeine Form der Hybridisierung im Einsatz haben. Im SMB-Markt, wo es typischerweise nur eine winzige Anzahl von Servern gibt, keine Skalierungshebel, um Cloud-Architekturen zu rechtfertigen, und eine hohe Ungleichheit zwischen den Systemen, vermute ich, dass DevOps nahezu unbegrenzt außerhalb der Norm bleiben wird, da der Overhead und die zusätzlichen Kompetenzen, die erforderlich sind, um es funktionsfähig zu machen, unpraktikabel oder sogar unmöglich zu erlangen sind. Größere Organisationen müssen sich ihre Workloads ansehen. Viele traditionelle Workloads und ein Großteil traditioneller Software sind für den DevOps-Ansatz, insbesondere die Cloud-Automatisierung, nicht gut geeignet und werden entweder eine Hybridisierung erfordern oder ein unpraktikabel hohes Maß an Programmierung auf einer Pro-System-Basis, was das DevOps-Modell unmöglich zu rechtfertigen macht. Doch Workloads, die auf Webarchitekturen aufbauen oder die sich äußerst gut horizontal skalieren lassen, werden im großen Maßstab stark vom DevOps-Modell profitieren. Dies könnte auf große Unternehmenskonzerne oder kleinere Unternehmen zutreffen, die wahrscheinlich gehostete Anwendungen für den externen Gebrauch produzieren.

Dieser Unterschied im Ansatz bedeutet, dass, um die Vereinigten Staaten als Beispiel zu nehmen, der Großteil der USA aus Unternehmen besteht, die sich weiterhin auf das Snowflake-Verwaltungsmodell konzentrieren werden, während einige Unternehmen an der Ostküste das DevOps-Modell effektiv evaluieren und beginnen könnten, sich in diese Richtung zu bewegen. Doch an der Westküste, wo modernere Architekturen und ein wesentlich stärkerer Fokus auf gehostete Anwendungen und Anwendungen für den externen Gebrauch die treibenden wirtschaftlichen Faktoren sind, bewegt sich DevOps bereits vom Neuankömmling zur reifen, etablierten Normalität. DevOps- und Snowflake-Ansätze werden auf diese Weise wahrscheinlich stark nach Regionen getrennt bleiben, genauso wie die IT im Allgemeinen erlebt, dass unterschiedliche Kompetenzen in unterschiedliche Regionen abwandern. Es wäre nicht überraschend, zu sehen, dass DevOps in Märkten wie Austin Fuß zu fassen beginnt, wo die traditionelle IT eher schlecht abgeschnitten hat.

Keiner der beiden Ansätze ist besser oder schlechter, es sind zwei unterschiedliche Ansätze, die zwei sehr unterschiedliche Arten der Bereitstellung von Systemen und zwei unterschiedliche grundlegende Anforderungen dieser Systeme bedienen. Mit dem Aufstieg von Cloud-Architekturen und dem DevOps-Modell ist es jedoch von entscheidender Bedeutung, dass bestehende Systemadministratoren verstehen, was das DevOps-Modell bedeutet und wann es zur Anwendung kommt, sodass sie ihre eigenen Workloads und einzigartigen Anforderungen korrekt evaluieren können. Ein großer Teil der traditionellen Welt der Snowflake-Systemadministration wird im Laufe der Zeit zum DevOps-Modell migrieren. Wir sind noch sehr weit davon entfernt, in der Branche einen stationären Zustand hinsichtlich des Gleichgewichts dieser beiden Modelle zu erreichen.

Ursprünglich veröffentlicht im StorageCraft Blog.