Einstieg: Wie Software funktioniert

Willkommen bei Be Software Architecture Wise und bei Kapitel null: Einstieg, wie Software funktioniert. Dieses Kapitel ist der Einstieg in den gesamten Kurs. Es setzt voraus, dass Sie Apps und Websites genutzt, aber nie ein Programm geschrieben haben. Am Ende haben Sie das Vokabular, auf dem jedes spätere Kapitel aufbaut.

Bei Softwarearchitektur geht es um die großen Entscheidungen in einem Softwaresystem: was seine Hauptteile sind, wie sie miteinander kommunizieren, wo Daten liegen und welche Qualitäten, etwa Geschwindigkeit, Zuverlässigkeit und Sicherheit, der Entwurf erreichen muss. Diese Entscheidungen werden in einem bestimmten Vokabular getroffen: Prozesse und Threads, Indizes und Caches, Schnittstellen und Abhängigkeiten, Transaktionen, APIs und Container. Architekten verwenden diese Wörter präzise, deshalb müssen Sie wissen, was jedes davon wirklich bedeutet und was es kostet. Dieses Kapitel ist für Menschen geschrieben, die nie programmiert haben. Jeder Abschnitt beginnt mit einer Analogie aus dem Alltag, bevor er den tatsächlichen Mechanismus erklärt. Wenn Sie bereits in der Softwareentwicklung arbeiten, können Sie es als gemeinsames Vokabular überfliegen.

Dieses Kapitel baut auf gar nichts auf. Es setzt kein technisches Vorwissen voraus und ist deshalb der richtige Ort, um anzufangen. Es führt direkt zu Kapitel 1, das mit diesen Bausteinen erklärt, was Softwarearchitektur ist und warum die großen Entscheidungen so wichtig sind. Wo ein Thema mehr Tiefe verdient, verweist das Kapitel auf den späteren Abschnitt, der es gründlich behandelt.

Das Kapitel hat acht Abschnitte in drei Gruppen. Die ersten drei bleiben innerhalb eines einzelnen Rechners. Abschnitt null Punkt eins erklärt, wie von Menschen geschriebener Code zu Anweisungen wird, die ein Prozessor ausführen kann, und warum Daten im Arbeitsspeicher bei einem Neustart verschwinden. Abschnitt null Punkt zwei stellt die alltäglichen Datenstrukturen vor, etwa Listen, Dictionaries und Queues. Mit der O-Notation erklärt er, warum eine Art, einen Kunden zu finden, bei einer Million Kunden schnell bleibt, während eine andere zusammenbricht. Abschnitt null Punkt drei steigt von Funktionen zu Modulen, Objekten und Schnittstellen auf. Er erklärt den Unterschied zwischen einer Bibliothek und einem Framework, warnt vor den versteckten Kosten von Abhängigkeiten und gibt einen ersten Blick auf Kopplung und Kohäsion.

Die nächsten drei Abschnitte verlassen den einzelnen Rechner. Abschnitt null Punkt vier erklärt, wie DNS Namen in Adressen übersetzt und wie HTTP-Anfragen und -Antworten funktionieren. Er zeigt außerdem, dass die Netzwerkverzögerung eine Untergrenze hat, die durch die Lichtgeschwindigkeit gesetzt ist. Abschnitt null Punkt fünf behandelt Dateien und Datenbanken: Tabellen, SQL-Abfragen, Indizes und Transaktionen, veranschaulicht an einer Banküberweisung, die nie nur halb stattfinden darf. Er stellt außerdem die wichtigsten nichtrelationalen Datenbanken vor und wann welche passt. Abschnitt null Punkt sechs erklärt, wie getrennte Systeme über APIs zusammenarbeiten. Eine API ist ein Vertrag. Sie sehen den Unterschied zwischen dem Warten auf eine Antwort und dem Senden einer Nachricht über eine Queue und warum eine gebrochene API allen schadet, die von ihr abhängen.

Die letzten beiden Abschnitte behandeln, wo Software läuft und wie sie entsteht. Abschnitt null Punkt sieben zeigt, was ein Server wirklich ist, wie sich dank virtueller Maschinen und Container viele Workloads einen physischen Rechner teilen und was Cloud-Anbieter verkaufen. Abschnitt null Punkt acht wendet sich von der Technik der Praxis zu: Anforderungen, Versionskontrolle, Tests, Continuous Integration und Delivery sowie Arbeitsweisen. Zum Schluss verfolgt er ein einziges Tippen auf „Bestellen“ in einer Essensliefer-App durch alle Teile des Kapitels.

Diese Reise lohnt schon jetzt einen ersten Blick, weil sie zeigt, wohin das ganze Kapitel führt. Eine Kundin hat ihren Warenkorb gefüllt und tippt auf „Bestellen“. Folgen Sie den Nummern. Zuerst fragt das Smartphone beim DNS nach der Adresse des Unternehmens. Dann sendet es die Bestellung über HTTPS an einen Load Balancer in der Cloud-Region des Unternehmens, wo die sichere Verbindung endet. Der Load Balancer gibt die Anfrage an den Bestellservice weiter. Dieser Service ruft über dessen API einen externen Zahlungsanbieter auf und schreibt die Bestellung dann in einer Transaktion in seine Datenbank. Als Nächstes legt er eine Nachricht „Order Placed“ in eine Queue. Ein Benachrichtigungsservice holt sie ab und bittet den Push-Dienst von Apple oder Google, eine Benachrichtigung an das Smartphone der Kundin zu senden. Beachten Sie die gestrichelten Pfeile: Dieser letzte Teil ist asynchron. Fällt der Benachrichtigungsservice aus, werden trotzdem Bestellungen angenommen, und die Nachrichten warten einfach in der Queue. Das musste jemand entscheiden, und solche Entscheidungen zu treffen, ist Architektur.

Hier ist die Idee, die Sie aus dem ganzen Kapitel mitnehmen sollten. Jedes System darin besteht aus Teilen, die ihre Details hinter einer vereinbarten Grenze verbergen: ein Modul hinter seiner Schnittstelle, eine Datenbank hinter SQL, ein Zahlungsanbieter hinter seiner API. An den Grenzen liegen die wichtigen Abwägungen. Ein Funktionsaufruf ist schnell und zuverlässig, ein Aufruf über ein Netzwerk dagegen langsamer und kann fehlschlagen. Eine Abhängigkeit spart Aufwand, bringt aber Risiken mit sich. Ein Cache spart Zeit, kann aber veraltete Daten liefern. Zu entscheiden, wo diese Grenzen verlaufen, was sie überquert und welche Abwägungen man in Kauf nimmt, das ist Softwarearchitektur. Jeder Abschnitt endet mit einem kurzen Hinweis darauf, warum sein Thema für die Architektur wichtig ist, achten Sie also darauf.

Wie sollten Sie es durcharbeiten? Wenn das Thema neu für Sie ist, lesen Sie die Abschnitte der Reihe nach, denn jeder baut auf dem vorigen auf. Wenn Sie schon manches kennen, greifen Sie die Abschnitte heraus, die Sie brauchen. Das ganze Kapitel zu lesen dauert etwa drei Stunden. Jeder Abschnitt endet mit einigen Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie sich die Antworten ansehen. Sie zeigen Ihnen schnell, was hängen geblieben ist und was sich erneut zu lesen lohnt. Wenn Sie so weit sind, können Sie den freiwilligen Kapiteltest ablegen: zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten. Planen Sie etwa fünfundvierzig Minuten ein. Die Bestehensgrenze liegt bei achtzig Prozent. Prüfen Sie vor dem Test, ob Sie die Fragen zur Selbstkontrolle für jeden Abschnitt beantworten können, und lesen Sie die Zusammenfassung jedes Abschnitts erneut, der Ihnen noch unklar ist.

Das ist die Landkarte von Kapitel null. Beginnen Sie mit Abschnitt null Punkt eins, in dem wir uns ansehen, was Software ist und was wirklich geschieht, wenn ein Computer ein Programm ausführt. Bis gleich.