Lese-Empfehlung: Release It! - Michael Nygard
19.01.2016 Thomas Mohme
Release It!
Erster Eindruck
Lange habe ich das Buch ignoriert, weil der Titel mir suggerierte, dass es ein weiteres Buch aus der Release-Management / Continuous-Deployment Schwemme ist.
Weil ich jedoch in unterschiedlichsten Quellen immer wieder sehr positive Verweise auf das Buch fand, habe ich mir doch die Zeit genommen, mich näher mit dem Inhalt zu befassen.
Ich musste feststellen, dass ich mich gründlich geirrt habe und der Untertitel "Design and Deploy Production-Ready Software" den Inhalt recht gut umschreibt.
In einem Interview auf InfoQ bringt der Autor es auf den Punkt:
Other books on design and architecture only tell you how to meet functional requirements. They help your software pass QA. In "Release It!", I'll show you how to make your software production ready.
Inhalt
Es geht also um die berühmt-berüchtigten "non-functional requirements" (z.B. SLAs, aber auch der Wunsch nach graceful degradation), deren Verletzung ein an sich erfolgreiches Projekt im Live-Betrieb scheitern lassen kann.
Ich habe die Bezeichnung "non-functional requirements" noch nie gemocht. Zu häufig wird in den Köpfen der Projektbeteiligten "non-functional" mit "non-important" gleichgesetzt.
Dass die "non-functional requirements" im Gegensatz zu den "functional requirements" nahezu nie schriftlich festgehalten werden, trägt weiter dazu bei, sie in der Entwicklung zu ignorieren.
Michael Nygard versteht es, uns mit "Realease It!" diese "non-functional requirements" klar vor Augen zu führen - zu einem guten Teil durch lebendige Schilderungen von Situationen, in denen sie missachtet wurden.
Im Vorwort beschreibt der Autor eindrücklich, worum es bei Softwareentwicklung geht:
And finally, despite our collective love of technology, nifty new techniques, and cool systems, in the end you have to face the fact that none of that really matters. In the world of business - which is the world that pays us - it all comes down to money. Systems cost money. To make up for that, they have to generate money, either in direct revenue or through cost savings. Extra work costs money, but then again, so does downtime. Inefficient code costs a lot of money, by driving up capital and operation costs. To understand a running system, you have to follow the money. And to stay in business, you need to make money - or at least not lose it.
Nygard vertitt die also Meinung, dass Software und ihre Entwicklung in der Geschäftswelt nie Selbstzweck ist, sondern immer nur ein Mittel ist, um einen anderes Ziel zu erreichen.
Für dieses Mittel gilt eine einfache Regel: Es muss mehr erwirtschaften als kosten.
Weiterhin konfrontiert er uns mit einer Tatsache: "Things will break." - und folgert daraus, dass es unsere Aufgabe ist, zu verhindern, dass sich Fehler ausbreiten.
No one designed this failure mode into the combined system, but no one designed it out either.
Kaum ein Satz beschreibt besser als der obige, dass IT-Sysyteme meist nicht wegen eines einzelnen Problems zusammenbrechen.
Große Probleme entstehen, weil ein ursprünglich kleiner Fehler eine Lawine von Folgeproblemen auslöst - und keine (wirkungsvollen) Maßnahmen vorgesehen sind, um die Folgeprobleme einzudämmen.
Dies ist das Kernthema des Buches: Stabilen, effizienten Betrieb von Software zu ermöglichen, in dem von Anfang an Design-Maßnahmen ergriffen werden, die dies förden und solche vermieden werden, die Problem-Lawinen begünstigen.
Aufbau
Das Buch ist in die vier Abschnitte "Stability", "Capacity", "General Design Issues" und "Operations" unterteilt.
Drei dieser vier Abschnitte beginnen mit einer "Case Study" - einer unterhaltsamen kurzen Geschichte über einen kleinen Fehler und seine Folgen.
Anschließend folgt jeweils eine Diskussion des Abschnitts-Themas, sowie eine Darstellung negativer und positiver Patterns.
Stability
Sehr zutreffen stellt der Autor fest "Stability is a necessary prerequisite to any other concerns. If your system falls over and dies every day, nobody is going to care about any aspects of the far future. Short-term fixes—and short-term thinking—will dominate in that environment."
Mancher konkrete Technik-Tipp ist mittlerweile antiquiert ("If you are using Java 5 and you are not using the primitives in java.util.concurrent, then shame on you. If you are not using Java 5, then download the util.concurrent library from ..."). Dies gilt aber vor allem für die vorgeschlagenen Lösungen. Die ursächlichen Probleme existieren heutzutage unverändert.
Zum Teil haben die Zeit und die Möglichkeiten den Autor eindeutig überholt: Mit aktuellen XaaS Angeboten ist dynamische Skalierung problemlos möglich. Das ändert nichts daran, dass "unbalanced capacities" (beispielsweise großzügig dimensionierte Webserver mit einer zu schwachen Datenbank) auch heute noch ein Problem darstellen können - es gibt lediglich mehr Lösungsoptionen.
Die Sprache spiegelt den pragmatisch, lösungsorientierten Stil klar wider:
“Count of patterns applied” is never a good quality metric.
oder
Hope is not a design method.
sind Beispiele dafür.
Capacity
In diesem Abschnitt werden (rudimentäre) Grundlagen der Kapazitätsplanung vermittelt.
Kapazitätsplanung befasst sich damit, zu bestimmen, welche Ressourcen (CPU, Speicher, I/O, Netzwerk, ...) für die Bewältigung eines gegebenen Problems benötigt werden.
Nygard geht es hier allerdings weniger um die üblichen Verfahren der Kapazitätsplanung, als vielmehr um typische Fehler beim Softwaredesign, die dazu führen, dass unnötig viel Verarbeitungskapazität erforderlich ist.
Manche Beispiele bei den Antipatterns sind ziemlich angestaubt.
In der Zusammenfassung stellt der Autor fest, dass die allermeisten Software-Entwickler in kleinen Projekten mit geringen Kapazitätsanforderungen arbeiten. Dementsprechend verfügt kaum jemand über Erfahrung im Umgang mit Kapazitätsgrenzen:
Without that experience, programmers are likely to re-create many of the capacity killers discussed in this section, either through ignorance or misguided intentions. These issues certainly aren’t covered in colleges and universities, where optimization refers to tweaking up some search algorithm.
Nobody deliberately selects a design with the purpose of harming the system’s capacity; instead, they select a functional design without regard to its effect on capacity.
Er stellt fest, dass Kapazitätsplanung im Softwaredesign meist keine oder nur eine untergeordnete Rolle spielt.
Insbesondere im Webserver-Bereich findet hier aktuell ein Umdenken hin zu asynchronen und damit ressourcenschonenden Ansätzen statt.
Beispiele auf der Java-VM dafür sind Vert.x, Play! oder Ratpack. Außerhalb der Java-VM gibt es (neben vielen anderen) mit Node.js und erlang weitere Vertreter dieses Ansatzes.
Operations
In Anlehnung an ein Stanford & Berkley Forschungsprojekt fordert der Autor "Recovery-Oriented Computing". Hierunter versteht er, dass während des gesamten Softwareentwicklungs-Prozesses Maßnahmen mit berücksichtigt werden sollen, die helfen, Probleme zu vermeiden, einzugrenzen, oder wenigstens die Fehlerdiagnose beschleunigen.
Bei manchen modernen Paradigmen (z.B. Actor Model, Microservices) ist dies inhärenter Bestandteil des Designs.
Aber auch Monitoring wird angesprochen. In den meisten anderen Medien geht es in diesem Zusammenhang um Tools und deren Zusammenspiel.
Michael Nygard betont hingegen die Wichtigkeit des Monitorings auf Business-Ebene und dass man zunächst lernen muss, wie sich das System in Normalbetrieb darstellt, damit man Abweichungen davon erkennen kann.
Außerdem gibt er Tipps für die effektive Grundausstattung von Messwerten, sowie folgenden Hinweis:
Visibility inside one application or server is not enough. Strictly local visibility leads to strictly local optimization.
Fazit
Es ist auffällig, das das Buch in vor-Cloud-Zeiten geschrieben wurde. Für Cloud-Deployments gibt es sicherlich weitere typische Problemquellen und -lösungen, die eine Erwähnung wert wären. Außerdem beschränkt sich das Buch auf Szenarien mit "klassischen" Architekturen. Die meisten angesprochenen Punkte sind aber so generell, dass sie auch auch bei Anwendung anderer Paradigmen zutreffend sind.
Für mich ist das Buch eine Fundgrube von Wissen über die Tücken des Betriebs von Software-Systemen. Ausgestattet mit diesem Wissen, lassen sich viele Probleme im Betrieb vermeiden.
Gerade in DevOps-Zeiten ("You build it - you run it") kann dies der eigenen Gesundheit zugutekommen . . .
Mit seinem flüssigen Schreibstil und den lebhaften "Case-Studies" liest sich das Buch in weiten Teilen fast wie eine Geschichte und nicht wie eine einschläfernde Aufzählung von Fakten.
Zu Recht wurde das Buch 2008 mit dem Jolt Award ausgezeichnet.
Mir ist kein weiteres Buch bekannt, dass sich mit dieser Thematik auseinandersetzt.
Für mich ist das Buch eine klare Lese-Empfehlung.
Das Buch
Sprache: Englisch
Taschenbuch, 326 Seiten
Michael T. Nygard
The Pragmatic Bookshelf
ISBN-10: 0-9787392-1-3
Version: 2007-3-28