Produktionsfähige Microservices

Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Dieses Buch entstand aus einer Initiative zur Produktionsbereitschaft, die ich einige Monate nach meinem Einstieg bei Uber Technologies als Site Reliability Engineer (SRE) startete. Die gigantische, monolithische API von Uber wurde langsam in Microservices aufgeteilt, und als ich zu Uber kam, gab es bereits über tausend Microservices, die von der API abgespalten worden waren und neben ihr liefen. Jeder dieser Microservices wurde von einem eigenen Entwicklungsteam entworfen, entwickelt und gewartet, und über 85 % dieser Services hatten wenig bis gar keine SRE-Beteiligung und auch keinen Zugang zu SRE-Ressourcen.

Die Einstellung von SREs und der Aufbau von SRE-Teams ist eine absurd schwierige Aufgabe, denn SREs sind wahrscheinlich die am schwersten zu findende Art von Ingenieuren: Site Reliability Engineering als Fachgebiet ist noch relativ neu, und SREs müssen (zumindest bis zu einem gewissen Grad) Experten für Softwareentwicklung, Systemtechnik und verteilte Systemarchitektur sein. Es gab keine Möglichkeit, alle Teams schnell mit einem eigenen SRE-Team auszustatten, und so wurde mein Team (das Consulting SRE Team) geboren. Unsere Vorgabe von oben war einfach: Wir sollten einen Weg finden, hohe Standards für die 85 % der Microservices zu schaffen, an denen SRE nicht beteiligt war.

Unsere Aufgabe war einfach, und die Richtlinie war vage genug, dass sie mir und meinem Team viel Freiraum ließ, um eine Reihe von Standards zu definieren, die jeder Microservice bei Uber befolgen konnte. Es war nicht einfach, hohe Standards zu finden, die für jeden einzelnen Microservice in dieser großen technischen Organisation gelten sollten. Deshalb habe ich mit Hilfe meines großartigen Kollegen Rick Boone (dessen hohe Standards für die von ihm unterstützten Microservices dieses Buch inspiriert haben) eine detaillierte Checkliste mit den Standards erstellt, die meiner Meinung nach jeder Service bei Uber erfüllen sollte, bevor er für den Produktionsverkehr zugelassen wird.

Dazu mussten wir eine Reihe übergeordneter Prinzipien festlegen, unter die jede spezifische Anforderung fallen sollte. und wir kamen auf acht solcher Prinzipien: Jeder Microservice bei Uber, so sagten wir, sollte stabil, zuverlässig, skalierbar, fehlertolerant, performant, überwacht, dokumentiert und auf jede Katastrophe vorbereitet sein. Für jedes dieser Prinzipien gab es eigene Kriterien, die definierten, was es bedeutet, dass ein Dienst stabil, zuverlässig, skalierbar, fehlertolerant, leistungsfähig, überwacht, dokumentiert und für jede Katastrophe gerüstet ist. Wichtig war, dass jedes Prinzip quantifizierbar war und dass jedes Kriterium messbare Ergebnisse lieferte, die die Verfügbarkeit unserer Microservices drastisch erhöhten. Ein Dienst, der diese Kriterien erfüllt, ein Dienst, der diese Anforderungen erfüllt, wurde von uns als produktionsreif eingestuft.

Der nächste Schritt bestand darin, diese Standards in den Teams effektiv und effizient umzusetzen. Ich schuf einen sorgfältigen Prozess, bei dem sich die SRE-Teams mit geschäftskritischen Diensten trafen (Dienste, deren Ausfall die Anwendung zum Erliegen bringen würde), Architekturüberprüfungen mit den Teams durchführten, Audits ihrer Dienste erstellten (einfache Checklisten, die mit "ja" oder "nein" bewerteten, ob der Dienst die einzelnen Anforderungen an die Produktionsbereitschaft erfüllte), detaillierte Roadmaps erstellten (Schritt-für-Schritt-Anleitungen, die detailliert aufzeigten, wie der betreffende Dienst in einen produktionsbereiten Zustand gebracht werden konnte) und jedem Dienst Produktionsbereitschaftswerte zuwiesen.

Die Architekturbesprechungen waren der wichtigste Teil des Prozesses: Mein Team versammelte alle Entwickler, die an einem Dienst arbeiteten, in einem Konferenzraum und bat sie, die Architektur ihres Dienstes innerhalb von 30 Minuten oder weniger auf einem Whiteboard darzustellen. Auf diese Weise konnten sowohl mein Team als auch das Host-Team schnell und einfach herausfinden, wo und warum der Dienst fehlschlug: Wenn ein Microservice in seiner ganzen Pracht dargestellt wurde (Endpunkte, Anfrageströme, Abhängigkeiten und alles), stach jeder Fehlerpunkt wie ein wunder Daumen hervor.

Jede Architekturprüfung brachte eine Menge Arbeit mit sich. Nach jeder Prüfung gingen wir die Checkliste durch und prüften, ob der Dienst die Anforderungen an die Produktionsreife erfüllte, und teilten diese Prüfung dann mit den Managern und Entwicklern des Teams. Als ich feststellte, dass das Konzept " produktionsreif" oder "nicht produktionsreif " einfach nicht detailliert genug war, um die Produktionsreife von Diensten zu bewerten, fügten wir den Prüfungen eine Punktebewertung hinzu. Deshalb wurde jeder Anforderung eine bestimmte Anzahl von Punkten zugewiesen und dann eine Gesamtnote für den Dienst vergeben.

Aus den Audits gingen Roadmaps hervor. Die Roadmaps enthielten eine Liste der Anforderungen an die Produktionsreife, die der Dienst nicht erfüllte, sowie Links zu Informationen über die jüngsten Ausfälle, die durch die Nichterfüllung dieser Anforderungen verursacht wurden, Beschreibungen der Arbeiten, die zur Erfüllung der Anforderungen erforderlich waren, einen Link zu einer offenen Aufgabe und den Namen des/der Entwickler(s), der/die mit der entsprechenden Aufgabe betraut war(en).

Nachdem ich die Produktionsbereitschaft dieses Prozesses (auch bekannt als Susan-Fowlers Produktionsbereitschaftsprozess als Service) selbst überprüft hatte, wusste ich, dass der nächste Schritt die Automatisierung des gesamten Prozesses sein musste, der auf allen Uber-Microservices zu jeder Zeit laufen würde. Zum Zeitpunkt des Schreibens dieses Buches wird das gesamte Produktionsbereitschaftssystem von einem fantastischen SRE-Team bei Uber unter der Leitung der furchtlosen Roxana del Toro automatisiert.

Jede der Anforderungen an die Produktionsbereitschaft in den Produktionsbereitschaftsstandards und die Details ihrer Umsetzung sind das Ergebnis unzähliger Stunden sorgfältiger, bewusster Arbeit von mir und meinen Kollegen in der SRE-Organisation von Uber. Bei der Erstellung der Anforderungsliste und dem Versuch, sie in allen Microservices von Uber umzusetzen, haben wir uns unzählige Notizen gemacht, lange miteinander diskutiert und alles recherchiert, was wir in der aktuellen Microservice-Literatur finden konnten (die sehr spärlich ist und fast nicht existiert). Ich traf mich mit einer Vielzahl von Microservice-Entwicklerteams, sowohl bei Uber als auch bei anderen Unternehmen, um herauszufinden, wie Microservices standardisiert werden können und ob es einen universellen Satz von Standardisierungsprinzipien gibt, der auf jeden Microservice in jedem Unternehmen angewendet werden kann und messbare, geschäftswirksame Ergebnisse liefert. Aus diesen Notizen, Argumenten, Treffen und Recherchen entstand die Grundlage für dieses Buch.

Erst als ich anfing, meine Arbeit mit Site Reliability Engineers und Softwareentwicklern in anderen Unternehmen in der Bay Area zu teilen, wurde mir klar, wie neu sie nicht nur in der SRE-Welt, sondern in der gesamten Tech-Branche war. Als die Ingenieure anfingen, mich um jedes bisschen Information und Anleitung zu bitten, das ich ihnen geben konnte, um ihre Microservices zu standardisieren und produktionsreif zu machen, begann ich zu schreiben.

Zum Zeitpunkt der Erstellung dieses Artikels gibt es nur sehr wenig Literatur zur Microservice-Standardisierung und nur wenige Leitfäden zur Pflege und zum Aufbau des Microservice-Ökosystems. Außerdem gibt es keine Bücher, die die Frage beantworten, die sich viele Ingenieure stellen, nachdem sie ihre monolithische Anwendung in Microservices aufgespalten haben: Wie geht es weiter? Das ehrgeizige Ziel dieses Buches ist es, diese Lücke zu schließen und genau diese Frage zu beantworten. Kurz gesagt: Dies ist das Buch, das ich mir gewünscht hätte, als ich bei Uber mit der Standardisierung von Microservices begann.

Für wen dieses Buch geschrieben ist

Dieses Buch richtet sich in erster Linie an Softwareentwickler und Site Reliability Engineers, die entweder einen Monolithen aufgespalten haben und sich fragen, wie es weitergeht, oder die Microservices von Grund auf aufbauen und von Anfang an stabile, zuverlässige, skalierbare, fehlertolerante und performante Microservices entwickeln wollen.

Die Relevanz der Grundsätze in diesem Buch ist jedoch nicht auf die primäre Zielgruppe beschränkt. Viele der Grundsätze, von der guten Überwachung bis zur erfolgreichen Skalierung einer Anwendung, können zur Verbesserung von Diensten und Anwendungen jeder Größe und Architektur in jedem Unternehmen angewendet werden. Ingenieure, technische Leiter, Produktmanager und hochrangige Führungskräfte können dieses Buch aus verschiedenen Gründen nützlich finden, z. B. um Standards für ihre Anwendung(en) festzulegen, Veränderungen in der Organisationsstruktur zu verstehen, die sich aus Architekturentscheidungen ergeben, oder um die architektonische und betriebliche Vision ihrer technischen Organisation(en) festzulegen und voranzutreiben.

Ich setze voraus, dass der Leser mit den grundlegenden Konzepten von Microservices, mit der Microservice-Architektur und mit den Grundlagen moderner verteilter Systeme vertraut ist - Leser, die diese Konzepte gut verstehen, werden am meisten von diesem Buch profitieren. Lesern, die mit diesen Themen nicht vertraut sind, widme ich im ersten Kapitel einen kurzen Überblick über die Microservice-Architektur, das Microservice-Ökosystem, die organisatorischen Herausforderungen, die mit Microservices einhergehen, und die praktische Umsetzung der Zerlegung einer monolithischen Anwendung in Microservices.

Was dieses Buch nicht ist

Dieses Buch ist keine Schritt-für-Schritt-Anleitung: Es ist keine explizite Anleitung, wie man die in den Kapiteln behandelten Dinge tut. Um eine solche Anleitung zu schreiben, wären viele, viele Bände nötig: Jeder Abschnitt jedes Kapitels in diesem Buch könnte zu einem eigenen Buch erweitert werden.

Daher ist dieses Buch sehr abstrakt und so allgemein gehalten, dass die Lektionen, die man hier lernt, auf fast jeden Microservice in fast jedem Unternehmen angewendet werden können, aber auch spezifisch und granular genug, dass es in eine Entwicklungsorganisation integriert werden kann und eine echte, greifbare Anleitung zur Verbesserung und Standardisierung von Microservices bietet. Da sich das Microservice-Ökosystem von Unternehmen zu Unternehmen unterscheidet, ist es nicht von Vorteil, wenn man Schritt für Schritt einen autoritativen oder pädagogischen Ansatz verfolgt. Stattdessen habe ich beschlossen, Konzepte vorzustellen, ihre Bedeutung für den Aufbau produktionsreifer Microservices zu erläutern, Beispiele für jedes Konzept zu geben und Strategien für ihre Umsetzung zu vermitteln.

Wichtig ist, dass dieses Buch keine enzyklopädische Darstellung aller Möglichkeiten ist, wie Microservices und Microservice-Ökosysteme aufgebaut und betrieben werden können. Ich werde der Erste sein, der zugibt, dass es viele gültige Wege gibt, Microservices und Microservice-Ökosysteme aufzubauen und zu betreiben. (Zum Beispiel gibt es neben dem Staging-Canary-Production-Ansatz, den ich in Kapitel 3, Stabilität und Zuverlässigkeit, vorstelle und befürworte, viele verschiedene Möglichkeiten, neue Builds zu testen). Einige Methoden sind jedoch besser als andere, und ich habe mich bemüht, nur die besten Methoden für die Erstellung und den Betrieb produktionsreifer Microservices vorzustellen und jedes Prinzip der Produktionsreife in allen Entwicklungsorganisationen anzuwenden.

Außerdem entwickelt sich die Technologie bemerkenswert schnell weiter und verändert sich. Wann immer und wo immer möglich, habe ich versucht, den Leser nicht auf eine bestehende Technologie oder eine Reihe von Technologien zu beschränken. Anstatt zum Beispiel dafür zu plädieren, dass jeder Microservice Kafka für das Logging verwendet, stelle ich die wichtigen Aspekte des produktionsreifen Loggings vor und überlasse die Wahl einer bestimmten Technologie und die tatsächliche Implementierung dem Leser.

Schließlich ist dieses Buch keine Beschreibung der technischen Organisation von Uber. Die Prinzipien, Standards, Beispiele und Strategien sind weder spezifisch für Uber noch ausschließlich von Uber inspiriert: Sie wurden von Microservices vieler Technologieunternehmen entwickelt und inspiriert und können auf jedes Microservice-Ökosystem angewendet werden. Dies ist kein beschreibender oder historischer Bericht, sondern ein Leitfaden für den Aufbau produktionsreifer Microservices.

Wie man dieses Buch benutzt

Es gibt mehrere Möglichkeiten, wie du dieses Buch verwenden kannst.

Die erste Herangehensweise ist die am wenigsten aufwändige: Du liest nur die Kapitel, die dich interessieren, und überfliegst den Rest (oder überspringst ihn). Diese Herangehensweise hat viele Vorteile: Du lernst neue Konzepte kennen, erhältst Einblicke in Konzepte, die du vielleicht schon kennst, und erfährst neue Denkansätze zu Aspekten der Softwareentwicklung und Microservice-Architektur, die dir in deinem Alltag und bei deiner Arbeit nützlich sein können.

Eine andere Herangehensweise ist eine etwas aufwändigere, bei der du das Buch überfliegst, indem du die Abschnitte, die für deine Bedürfnisse relevant sind, sorgfältig liest und dann einige der Prinzipien und Standards auf deinen Microservice bzw. deine Microservices anwendest. Wenn dein(e) Microservice(s) zum Beispiel eine bessere Überwachung benötigen, könntest du den Großteil des Buches überfliegen und nur Kapitel 6, Überwachung, aufmerksam lesen und dann das Material in diesem Kapitel verwenden, um die Überwachung, die Alarmierung und die Reaktion auf Ausfälle deines(r) Services zu verbessern.

Der letzte Ansatz, den du wählen kannst, ist (wahrscheinlich) der lohnendste und derjenige, den du wählen solltest, wenn dein Ziel darin besteht, entweder den Microservice, für den du verantwortlich bist, oder alle Microservices in deinem Unternehmen vollständig zu standardisieren, so dass er oder sie wirklich produktionsreif sind. Wenn es dein Ziel ist, deinen Microservice stabil, zuverlässig, skalierbar, fehlertolerant, performant, ordnungsgemäß überwacht, gut dokumentiert und für jede Katastrophe gerüstet zu machen, solltest du diesen Ansatz wählen. Um das zu erreichen, solltest du jedes Kapitel sorgfältig lesen, jeden Standard verstehen und jede Anforderung an die Bedürfnisse deines Microservices anpassen und anwenden.

Am Ende jedes Standardisierungskapitels (Kapitel 3-7) findest du einen Abschnitt mit dem Titel "Evaluiere deinen Microservice", der eine kurze Liste von Fragen enthält, die du dir zu deinem Microservice stellen kannst. Die Fragen sind nach Themen geordnet, so dass du (der Leser) schnell die Fragen heraussuchen kannst, die für deine Ziele relevant sind, sie für deinen Microservice beantworten und dann bestimmen kannst, welche Schritte du unternehmen kannst, um deinen Microservice produktionsreif zu machen. Am Ende des Buches findest du zwei Anhänge(Anhang A, Checkliste für die Produktionsreife, und Anhang B, Evaluiere deinen Microservice), die dir helfen, den Überblick über die Standards für die Produktionsreife und die Fragen zur Evaluierung deiner Microservices zu behalten, die im ganzen Buch verstreut sind.

Wie dieses Buch strukturiert ist

Wie der Titel schon sagt, ist Kapitel 1, Microservices, eine Einführung in Microservices. Es behandelt die Grundlagen der Microservice-Architektur, geht auf einige Details der Aufteilung eines Monolithen in Microservices ein, stellt die vier Schichten eines Microservice-Ökosystems vor und schließt mit einem Abschnitt, der einige der organisatorischen Herausforderungen und Kompromisse beleuchtet, die mit der Einführung der Microservice-Architektur einhergehen.

In Kapitel 2, Production-Readiness, werden die Herausforderungen der Microservice-Standardisierung dargestellt und die acht Production-Readiness-Standards vorgestellt, die alle auf der Verfügbarkeit von Microservices basieren.

In Kapitel 3, Stabilität und Zuverlässigkeit, geht es um die Grundsätze der Entwicklung stabiler und zuverlässiger Microservices. Der Entwicklungszyklus, die Deployment-Pipeline, der Umgang mit Abhängigkeiten, Routing und Discovery sowie die stabile und zuverlässige Abschaltung und Stilllegung von Microservices werden hier behandelt.

Kapitel 4, Skalierbarkeit und Leistung, befasst sich mit den Anforderungen für den Aufbau skalierbarer und leistungsfähiger Microservices. Dazu gehören die Kenntnis der Wachstumsskalen von Microservices, die effiziente Nutzung von Ressourcen, Ressourcenbewusstsein, Kapazitätsplanung, Skalierung von Abhängigkeiten, Verkehrsmanagement, Aufgabenbearbeitung und -verarbeitung sowie skalierbare Speicherung von Daten.

Kapitel 5, Fehlertoleranz und Katastrophenvorsorge, behandelt die Grundsätze für den Aufbau fehlertoleranter Microservices, die auf jede Katastrophe vorbereitet sind. Dazu gehören häufige Katastrophen und Ausfallszenarien, Strategien für die Fehlererkennung und -behebung, die Vor- und Nachteile von Resiliency-Tests und der Umgang mit Zwischenfällen und Ausfällen.

In Kapitel 6, Überwachung, geht es um die Feinheiten der Microservice-Überwachung und darum, wie du die Komplexität der Microservice-Überwachung durch Standardisierung vermeiden kannst. Logging, die Erstellung nützlicher Dashboards und der richtige Umgang mit Alarmen werden in diesem Kapitel behandelt.

Nicht zuletzt geht es in Kapitel 7, Dokumentation und Verständnis, um eine angemessene Microservice-Dokumentation und Möglichkeiten zur Verbesserung des architektonischen und betrieblichen Verständnisses in den Entwicklungsteams und im gesamten Unternehmen sowie um praktische Strategien zur Umsetzung von Standards für die Produktionsbereitschaft in einer Entwicklungsorganisation.

Am Ende des Buches gibt es zwei Anhänge. Anhang A, Checkliste für die Produktionsreife, ist die Checkliste, die am Ende von Kapitel 7, Dokumentation und Verständnis, beschrieben wird, und ist eine kurze Zusammenfassung aller Standards für die Produktionsreife, die im Buch verstreut sind, zusammen mit den entsprechenden Anforderungen. Anhang B, Evaluate Your Microservice, ist eine Sammlung aller "Evaluate Your Microservice"-Fragen, die in den entsprechenden Abschnitten am Ende der Kapitel 3-7 zu finden sind.

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Constant width bold

Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

Tipp

Dieses Element steht für einen Tipp oder eine Anregung.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Warnung

Dieses Element weist auf eine Warnung oder einen Warnhinweis hin.

O'Reilly Safari

Hinweis

Safari (ehemals Safari Books Online) ist eine mitgliedschaftsbasierte Schulungs- und Nachschlageplattform für Unternehmen, Behörden, Lehrkräfte und Einzelpersonen.

Mitglieder haben Zugang zu Tausenden von Büchern, Schulungsvideos, Lernpfaden, interaktiven Tutorials und kuratierten Playlists von über 250 Verlagen, darunter O'Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett und Course Technology, um nur einige zu nennen.

Weitere Informationen erhältst du unter http://oreilly.com/safari.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Nord
• Sebastopol, CA 95472
• 800-998-9938 (in den Vereinigten Staaten oder Kanada)
• 707-829-0515 (international oder lokal)
• 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter http://bit.ly/prod-ready_microservices aufrufen .

Wenn du Kommentare oder technische Fragen zu diesem Buch stellen möchtest, sende eine E-Mail an [e-mail].

Weitere Informationen zu unseren Büchern, Kursen, Konferenzen und Neuigkeiten findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia

Danksagungen

Dieses Buch ist meiner besseren Hälfte, Chad Rigetti, gewidmet, der sich die Zeit genommen hat, Quantencomputer zu bauen, um sich all meine Tiraden über Microservices anzuhören, und der mich bei jedem Schritt freudig ermutigt hat. Ohne seine Liebe und uneingeschränkte Unterstützung hätte ich dieses Buch nicht schreiben können.

Es ist auch meinen Schwestern Martha und Sara gewidmet, deren Mut und Freude mich in jedem Moment und in jedem Aspekt meines Lebens inspirieren, und auch Shalon Van Tine, die seit vielen Jahren meine engste Freundin und größte Unterstützerin ist.

Ich bin all jenen zu großem Dank verpflichtet, die mir Feedback zu frühen Entwürfen gegeben haben, meinen Kollegen bei Uber und den Ingenieuren, die mutig daran gearbeitet haben, die Prinzipien und Strategien dieses Buches in ihren eigenen Unternehmen umzusetzen. Besonders dankbar bin ich Roxana del Toro, Patrick Schork, Rick Boone, Tyler Dixon, Jonah Horowitz, Ryan Rix, Katherine Hennes, Ingrid Avendano, Sean Hart, Shella Stephens, David Campbell, Jameson Lee, Jane Arc, Eamon Bisson-Donahue und Aimee Gonzalez.

Nichts von alledem wäre ohne Brian Foster, Nan Barber, die technischen Prüfer und den Rest der fantastischen O'Reilly-Mitarbeiter möglich gewesen. Ohne euch hätte ich diesen Artikel nicht schreiben können.