Verteilte Systeme mit Kubernetes entwerfen: Patterns und Prinzipien für skalierbare und zuverlässige Services

KAPITEL 1

Einführung

Die heutige Welt der Always-on-Anwendungen und APIs stellt Anforderungen an Verfügbarkeit und Zuverlässigkeit, für die noch vor einiger Zeit eine Handvoll missionskritischer Systeme verteilt über die ganze Welt erforderlich gewesen wären. Genauso sorgt das Potenzial für ein schnelles und virales Wachstum eines Service dafür, dass jede Anwendung so gebaut werden muss, dass sie als Reaktion auf Benutzeranforderungen nahezu sofort skaliert. Diese Sachzwänge und Anforderungen führen dazu, dass so gut wie jede zu bauende Anwendung – sei es eine mobile App für Endverbraucher oder eine Backend-Payments-Anwendung – ein verteiltes System sein muss.

Aber das Bauen verteilter Systeme ist eine Herausforderung. Häufig handelt es sich um Unikate und die Entwicklung verteilter Systeme zeigt eine erstaunliche Ähnlichkeit zur Welt der Software-Entwicklung vor dem Entstehen moderner objektorientierter Programmiersprachen. Zum Glück brachte die Entwicklung wie bei objektorientierten Sprachen technische Fortschritte mit sich, die die Herausforderungen beim Bauen verteilter Systeme drastisch verringert haben. In diesem Fall ist es die wachsende Beliebtheit von Containern und Container-Orchestrierern. Wie beim Konzept der Objekte bei der objektorientierten Programmierung bilden diese containerisierten Bausteine die Grundlage für die Entwicklung wiederverwendbarer Komponenten und Muster, welche das Erstellen zuverlässiger verteilter Systeme drastisch vereinfachen und mehr Leuten zugänglich machen. In der folgenden Einführung gebe ich einen kurzen Überblick über die Entwicklungen, die zur heutigen Situation geführt haben.

Eine kurze Geschichte der System-Entwicklung

In den Anfängen gab es Maschinen, die für bestimmte Zwecke gebaut wurden, wie zum Beispiel das Berechnen von Artillerie-Tabellen oder den Tidenzeiten, das Entschlüsseln von Codes oder andere präzise und komplizierte mathematische Routine-Aufgaben. Schließlich entwickelten sich diese zweckgebundenen Maschinen zu allgemein programmierbaren Rechnern. Und irgendwann konnten diese Computer nicht nur ein Programm, sondern mehrere gleichzeitig ausführen – mithilfe von Timesharing-Betriebssystemen –, aber diese Computer waren immer noch getrennt voneinander.

Nach und nach wurden die Maschinen miteinander verbunden und es entstanden Client/Server-Architekturen, sodass auch recht schwachbrüstige Computer auf einem Schreibtisch genutzt werden konnten, um auf die größere Leistung eines Mainframes in einem anderen Raum oder Gebäude zugreifen zu können. Während diese Form der Client/Server-Programmierung schon etwas komplizierter war, als ein Programm für einen einzelnen Rechner zu schreiben, war es doch immer noch ganz gut zu verstehen. Der oder die Clients stellten Requests, der oder die Server beantworteten diese.

In den frühen 2000ern führte die zunehmende Verbreitung des Internets und großer Datacenter mit Tausenden verhältnismäßig günstiger, »normaler« Computer, die miteinander vernetzt sind, zu einer zunehmenden Entwicklung verteilter Systeme. Anders als Client/Server-Architekturen bestehen Anwendungen in verteilten Systemen aus vielen verschiedenen Anwendungen, die auf unterschiedlichen Maschinen laufen, oder aus vielen Replicas auf mehreren Rechnern, die alle miteinander kommunizieren, um ein System wie eine Websuche oder eine Verkaufsplattform zu implementieren.

Aufgrund der verteilten Natur der Systeme sind diese – bei ordentlichem Aufbau – inhärent zuverlässiger. Und wenn die Architektur sauber ist, können sie zu besser skalierbaren Organisationsmodellen für die Software-Entwicklungsteams führen, die diese bauen. Leider bringen diese Vorteile auch einen Preis mit sich. Die verteilten Systeme können signifikant komplizierter zu entwerfen, bauen und debuggen sein. Die erforderlichen Entwickler-Fähigkeiten zum Bauen eines zuverlässigen verteilten Systems sind deutlich umfangreicher als die, die zum Bauen einer Anwendung für einen Rechner gebraucht werden, wie für Mobile oder Web-Frontends. Aber der Bedarf nach zuverlässigen verteilten Systemen wächst trotzdem. Daher gibt es auch weiterhin zunehmenden Bedarf für die Werkzeuge, Muster und Praktiken, um sie zu bauen.

Zum Glück hat die verbesserte Technologie auch das Bauen verteilter Systeme vereinfacht. Container, Container-Images und Container-Orchestrierer sind in den letzten Jahren beliebt geworden, weil sie die Grundlage und Bausteine für zuverlässige verteilte Systeme legen. Mit Containern und Container-Orchestrierern als Grundlage können wir eine Reihe von Mustern und wiederverwendbaren Komponenten umsetzen. Diese sind ein Toolkit, auf das wir zum zuverlässigeren und effizienteren Bauen unserer Systeme zurückgreifen können.

Eine kurze Geschichte von Mustern in der Software-Entwicklung

Es ist nicht das erste Mal, dass solche eine Transformation in der Software-Branche abläuft. Um den Einfluss von Mustern, Praktiken und wiederverwendbaren Komponenten auf die frühere System-Entwicklung besser zu verstehen, hilft es, sich diese vergangenen Transformationen nochmals anzuschauen.

Formalisierung der algorithmischen Programmierung

Donald Knuths Sammlung The Art of Computer Programming (Addison-Wesley Professional) markiert einen wichtigen Meilenstein in der Entwicklung der Informatik, auch wenn vor der Veröffentlichung im Jahr 1962 schon über ein Jahrzehnt lang programmiert wurde. Insbesondere enthalten die Bücher keine Algorithmen, die für einen bestimmten Computer entworfen sind, sondern sie sollen dem Leser die Algorithmen selbst erklären. Diese Algorithmen können dann an die spezifische Architektur des eingesetzten Computers oder des zu lösenden Problems angepasst werden. Diese Formalisierung war wichtig, weil sie den Anwendern einen allgemein nutzbaren Werkzeugkasten zur Verfügung stellte, mit denen sie ihre Programme bauen konnten, aber auch, weil sie zeigte, dass es ein universelles Konzept gibt, das Programmierer lernen sollten, um es dann im Folgenden in verschiedensten Kontexten anzuwenden. Es lohnte sich, die Algorithmen selbst – unabhängig von einem zu lösenden spezifischen Problem – zu verstehen.

Muster für die objektorientierte Programmierung

Knuths Bücher repräsentieren einen wichtigen Meilenstein beim Nachdenken über Computer-Programmierung, und Algorithmen repräsentieren eine wichtige Komponente in der Entwicklung der Computer-Programmierung. Aber mit wachsender Komplexität der Programme und zunehmender Anzahl an Leuten, die an einem einzelnen Programm schreiben (von wenigen über Dutzende bis hin zu Tausenden), wurde klar, dass prozedurale Programmiersprachen und Algorithmen für die Aufgaben moderner Programmierung nicht ausreichend waren. Diese Änderungen in der Computer-Programmierung führten zur Entwicklung objektorientierter Programmiersprachen, die Daten, Wiederverwendbarkeit und Erweiterbarkeit zu Ebenbürtigen der Algorithmen machten.

Als Reaktion auf diese Veränderungen in der Programmierung gab es auch Änderungen an den Mustern und Praktiken. Während der frühen bis mittleren 1990er kamen haufenweise Bücher zu Mustern in der objektorientierten Programmierung heraus. Das bekannteste davon ist das der »Gang of Four«: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software von Erich Gamma et al. (Addison-Wesley). In diesem Buch wurden eine gemeinsame Sprache und ein Framework für das Programmieren definiert. Es beschreibt eine Reihe Schnittstellenbasierter Muster, die sich in einer Vielzahl von Situationen einsetzen lassen. Aufgrund der Vorteile der objektorientierten Programmierung und insbesondere der Schnittstellen konnten diese Muster auch als allgemein wiederverwendbare Bibliotheken implementiert werden. Diese ließen sich einmalig von einer Entwickler-Community schreiben und dann wieder und wieder verwenden, wodurch Zeit gespart und die Zuverlässigkeit erhöht wurde.

Der Aufstieg von Open-Source-Software

Obwohl das Konzept, dass Entwickler gemeinsam Quellcode nutzen, schon nahezu seit Beginn des Computerzeitalters bekannt ist und formal freie Software-Organisationen seit Mitte der 1980er Jahre existieren, gab es in den späten 1990ern und 2000ern ein drastisches Wachstum bei der Entwicklung und Verbreitung von Open-Source-Software. Auch wenn Open Source nur am Rande mit der Entwicklung von Mustern für verteilte Systeme zu tun hat, ist es insoweit wichtig, dass durch die Open-Source-Communitys zunehmend klar wurde, dass Software-Entwicklung im Allgemeinen und verteilte Systeme im Speziellen gemeinschaftliche Anstrengungen erfordern. Es ist wichtig, darauf hinzuweisen, dass die gesamte Container-Technologie, die die Grundlage für die in diesem Buch beschriebenen Muster bildet, als Open-Source-Software entwickelt und freigegeben wurde. Der Wert von Mustern zum Beschreiben und Verbessern der Praktiken verteilter Entwicklung wird besonders dann klar, wenn Sie sie aus Sicht der Community betrachten.

Der Wert von Mustern, Praktiken und Komponenten

Bevor Sie etwas von Ihrer wertvollen Zeit dafür aufwenden, etwas über eine Reihe von Mustern zu lesen, von denen ich behaupte, dass sie Ihre Entwicklungspraktiken verbessern, Sie etwas Neues lehren und – seien wir ehrlich – Ihr Leben verändern werden, dürfen Sie durchaus fragen: »Warum?« Worum geht es bei den Entwurfsmustern und Praktiken, die die Art und Weise ändern können, wie wir Software entwerfen und bauen? In diesem Abschnitt werde ich die Gründe erläutern, warum das meiner Meinung nach ein wichtiges Thema ist, und Sie hoffentlich davon überzeugen, mir für den Rest des Buches zu folgen.

Auf den Schultern von Riesen stehen

Als Ausgangsbasis ist der Wert, den Muster für verteilte Systeme bieten können, die Möglichkeit, im übertragenen Sinne auf den Schultern von Riesen zu stehen. Nur selten sind Probleme, die wir lösen wollen, oder Systeme, die wir bauen, wirklich einmalig. Vielleicht sind die Kombination aus Elementen, die wir zusammensetzen, und das gesamte Geschäftsmodell, das die Software ermöglicht, etwas, was die Welt noch nicht gesehen hat. Aber der Weg, auf dem das System gebaut wird, und die Probleme, die entstehen, weil es zuverlässig, agil und skalierbar sein soll, sind nicht neu.

Das ist daher der erste Wert von Mustern: Sie erlauben es uns, aus den Fehlern anderer zu lernen. Vielleicht haben Sie noch nie zuvor verteilte Systeme gebaut oder noch nie diese Art von verteilten Systemen. Statt also zu hoffen, dass ein Kollege in diesem Bereich ein bisschen Erfahrung hat, oder zu lernen, indem Sie die gleichen Fehler wie andere machen, können Sie Muster als Lotsen nutzen. Muster für die Entwicklung verteilter Systeme erlernen Sie genauso wie andere Best Practices im Computerumfeld. Sie beschleunigen Ihre Fähigkeit, Software zu bauen, ohne schon direkte Erfahrung mit den Systemen, Fehlern und Lehren aus erster Hand zu haben, die zum Kodifizieren der Muster geführt haben.

Eine gemeinsame Sprache für Gespräche über unsere Praktiken

Etwas über verteilte Systeme zu lernen und unser Verständnis dazu zu verbessern, ist nur der erste Wert eines gemeinsamen Satzes an Mustern. Muster haben auch für erfahrene Entwickler verteilter Systeme, die diese schon verstehen, einen Wert, denn sie liefern ein gemeinsames Vokabular, durch das wir uns gegenseitig schnell verstehen können. Dieses Verständnis bildet die Basis für die Weitergabe von Wissen und fortlaufendes Lernen.

Um dies besser zu verstehen, stellen Sie sich vor, wir nutzen beide das gleiche Objekt, um unser Haus zu bauen. Ich nenne dieses Objekt »Foo«, während Sie es als »Bar« bezeichnen. Wie lange werden wir uns über den Wert eines Foo im Gegensatz zum Bar unterhalten oder versuchen, die unterschiedlichen Eigenschaften von Foo und Bar zu diskutieren, bis wir bemerken, dass wir über das gleiche Objekt sprechen? Haben wir einmal erkannt, dass Foo und Bar das Gleiche sind, können wir endlich gegenseitig von der Erfahrung des anderen lernen.

Ohne gemeinsames Vokabular verschwenden wir Zeit mit unnötigen Diskussionen oder beim Erläutern von Konzepten, die andere verstehen, aber unter einem anderen Namen kennen. Daher ist ein weiterer Wert von Mustern, einen gemeinsamen Satz an Begriffen und Definitionen bereitzustellen, sodass wir unsere Zeit nicht mit Namensverwirrung verbringen und uns stattdessen direkt mit den Details und der Implementierung der zentralen Konzepte befassen können.

Ich habe das in der kurzen Zeit, in der ich mit Containern arbeite, schon erlebt. Dabei hat sich der Begriff des Sidecar-Containers (in Kapitel 2 beschrieben) in der Container-Community verbreitet. So müssen wir uns nicht mehr damit herumschlagen, was ein Sidecar ist, und können uns direkt darum kümmern, wie das Konzept genutzt werden kann, um ein bestimmtes Problem zu lösen. »Wenn wir ein Sidecar nutzen ...« – »Ja und ich kenne genau den Container, den wir dafür nehmen können.« Dieses Beispiel führt zum dritten Wert von Mustern – dem Erstellen wiederverwendbarer Komponenten.

Gemeinsame Komponenten für einfache Wiederverwendung

Neben dem Ermöglichen des gegenseitigen Lernens und dem Bereitstellen eines gemeinsamen Vokabulars für Gespräche über die Kunst des Bauens von Systemen sind Muster noch ein weiteres Werkzeug für die Programmierung: die Möglichkeit, gemeinsame Komponenten zu identifizieren, die dann nur einmal implementiert zu werden brauchen.

Müssten wir den gesamten Code, den unsere Programme nutzen, selbst schreiben, würden wir nie das Ziel erreichen. Vermutlich würden wir noch