Matthew Liste, Executive Vice President und globaler Leiter der Infrastruktur bei American Express, ist der Ansicht, dass eine erfolgreiche technische Plattform nicht an der Anzahl ihrer Komponenten gemessen wird, sondern an ihrer Fähigkeit, Komplexität zu verbergen und Entwicklern eine stabile und klare Erfahrung zu bieten. Liste stützte seinen Vortrag auf der QCon San Francisco auf mehr als 20 Jahre Erfahrung beim Aufbau von Plattformen und Infrastrukturen für kritische Systeme bei Goldman Sachs, JPMorgan Chase und American Express.
Die von Liste beschriebenen Plattformen bedienen eine große Zahl interner Entwickler: etwa 20.000 Nutzer bei American Express und etwa 60.000 bei JPMorgan Chase. Trotz des Größenunterschieds zu Cloud-Service-Providern ist er der Ansicht, dass dieselben grundlegenden Prinzipien für jedes Team gelten, das eine Schicht entwickelt, auf die andere angewiesen sind.
Eine gute Plattform verbirgt Komplexität, ohne zu verbergen, was geschieht
Liste definiert eine Plattform zunächst als eine Gruppe integrierter Technologien, die die Grundlage für den Aufbau von Anwendungen bildet. Er vergleicht sie mit der Wasser- und Abwasserversorgung: Solange sie funktioniert, denkt der Nutzer nicht über die dahinterliegende Infrastruktur nach, bemerkt sie aber sofort, wenn sie ausfällt.
Deshalb sollte die Erfahrung mit der Plattform intuitiv sein und gemeinsame, austauschbare Komponenten verwenden, etwa einheitliche Grundlagen für Überwachung, Identität und Namensräume. Diese Kombinierbarkeit macht die Plattform eher zu Lego-Steinen als zu einer Gruppe voneinander getrennter Dienste, die nur mit zusätzlichem Aufwand zusammenarbeiten.
Stabilität, Sicherheit und Skalierbarkeit sind keine optionalen Eigenschaften
Liste benennt das, was er die „drei Säulen“ nennt: Stabilität, Sicherheit und Skalierbarkeit. Das erforderliche Verfügbarkeitsniveau hängt vom Wert des Systems ab. Die Systeme zur Autorisierung von Kreditkarten bei American Express laufen seiner Darstellung zufolge mit einer Verfügbarkeit von bis zu sechs Neunen, während andere Systeme ein höheres Maß an Ausfallzeit verkraften können.
Er betont außerdem, dass anfänglicher Erfolg Skalierungsprobleme verbergen kann. Eine Plattform, die zu Beginn gut funktioniert, kann bei zunehmender Nutzung auf Engpässe stoßen, was sich unmittelbar auf die Stabilität auswirkt. Deshalb müssen Service-Level-Ziele (SLOs) gemeinsam mit den Verbrauchern festgelegt und im Laufe der Zeit eingehalten werden, nicht nur am Tag der Einführung.
Kontinuierliche Aktualisierung und die Reduzierung undifferenzierter Arbeit
Liste betrachtet es als eine der schwierigsten und am ehesten aufzuschiebenden Aufgaben, die Plattform aktuell zu halten. Aufgeschobene Aktualisierungen können sich anhäufen, den Wechsel auf eine neuere Version verteuern und Kunden beeinträchtigen. Er schlägt einen internen Maßstab namens 0114 vor: null Personen für die regelmäßige Wartung dank Automatisierung, die Möglichkeit, alle Komponenten der Flotte zu aktualisieren, der Abschluss des Upgrades innerhalb von weniger als einem Tag sowie ein Aktualisierungszyklus alle 14 Tage oder weniger.
Außerdem plädiert er dafür, nichts neu zu entwickeln, was bereits in ausreichender Qualität verfügbar ist. Statt eine neue PostgreSQL-Engine zu schreiben, nennt er als Beispiel den Aufbau einer Steuerungsschicht, die tägliche Backups in einem Objektspeicher ausführt – genau der Teil, der zur Erfüllung regulatorischer Anforderungen benötigt wird. Die Idee besteht darin, sich auf den Wert zu konzentrieren, den das Unternehmen benötigt, und nicht auf die technisch interessanteste Aufgabe.
Klare Entscheidungen und eine vertragliche Beziehung zu den Verbrauchern
Plattformverantwortliche sollten ihren Kunden zuhören, aber nicht jede Anfrage umsetzen. Die Ressourcen sind begrenzt, und wenn alte Funktionen nicht außer Betrieb genommen werden, häufen sich technische Schulden an und verhindern die Entwicklung wichtigerer Dinge. Daher sollte die Plattform eine klare „Haltung“ einnehmen: Sie legt fest, was sie unterstützt, wovon sie Abstand nimmt und was der Mehrheit der Nutzer dient.
Dazu gehört, die Verantwortlichkeiten formell über Programmierschnittstellen, Service-Level-Vereinbarungen und Prozesse abzugrenzen. Es reicht nicht aus, dass das Team weiß, was es anbietet. Auch der Verbraucher muss wissen, was in seinen Verantwortungsbereich fällt und welche Grenzen die Plattform nicht überschreitet. Liste vergleicht Plattformen mit Komponenten mit festen Formen: Ein begrenztes Team kann kein maßgeschneidertes Produkt für jeden Kunden bauen.
Praktische Erfahrung: Früh ausprobieren und Abstraktion nutzen, ohne Details zu verbergen
Liste empfiehlt, nach der Entscheidung für einen Aufbau schnell und wiederholt zu scheitern und dabei die Kunden während des Übergangs zu schützen. Er verweist auf frühe Versuche mit Linux-Containern und verschiedenen Orchestrierungswerkzeugen, die schließlich zum Wechsel auf Kubernetes führten. Das frühe Experimentieren ermöglichte es dem Team, zu lernen, bevor es auf die Reife einer einzigen Lösung wartete.
Gleichzeitig sollten Abstraktionsschichten nicht verbergen, was darunter geschieht. Eine Benutzeroberfläche, APIs und Infrastructure as Code wie Terraform können bereitgestellt werden, doch es muss ausreichend Einblick und Detailtiefe geben, um Fehler zu verstehen und das Verhalten bei Bedarf anzupassen. Liste schließt mit der Betonung, auf Open-Source-Quellen und offenen Standards aufzubauen, damit sich das Plattformteam auf Integration und zusätzlichen Nutzen konzentrieren kann, anstatt jede Schicht von Grund auf neu zu erstellen.
Warum sind diese Prinzipien wichtig?
Der zentrale Wert von Listes Ansatz besteht darin, den Plattformaufbau von einem Projekt zur Einführung einer Werkzeuggruppe zu einer langfristigen betrieblichen Verpflichtung zu machen. Nach ihrer Einführung beeinflusst die Plattform viele Teams. Daher werden Aktualisierbarkeit, klare Verantwortlichkeiten und das Management der Außerbetriebnahme wichtiger als das schnelle Hinzufügen einer neuen Funktion. Diese Prinzipien bleiben Leitlinien aus der praktischen Erfahrung und sind kein einheitlicher Standard, der Erfolg garantiert. Denn das erforderliche Verfügbarkeitsniveau, der Umfang der Automatisierung und die Wahl der Abstraktionen hängen weiterhin von der Art des Systems und den Bedürfnissen seiner Nutzer ab.