Vortrag: Wie Monzo hunderte Deployments pro Tag sicher ausliefert

InfoQ Homepage Präsentationen Move Fast, Don't Break Trust: Shipping Constantly with Humans and Beyond

Suhail Patel erläutert, wie Monzo seine Software-Engineering-Organisation und seinen technischen Stack strukturiert, um sicher hunderte Male pro Tag auszuliefern. Er teilt Einblicke in meinungsbildende Microservice-Abstraktionen, tenancy-basiertes Staging, statische Analyse-Prüfungen und Continuous Profiling und zeigt, wie eine starke interne Plattform es Ingenieuren und LLMs ermöglicht, schnell zu iterieren, ohne Zuverlässigkeit zu opfern.

Suhail Patel ist Staff Engineer bei Monzo mit Fokus auf den Aufbau der Core Platform. Seine Aufgabe umfasst den Aufbau und die Wartung von Monzos Infrastruktur, die tausende Microservices umfasst und auf Kubernetes, Cassandra und Etcd basiert. Er beschäftigt sich mit der Untersuchung abweichenden Verhaltens und stellt sicher, dass Dienste in einer sich ständig wandelnden Cloud-Umgebung zuverlässig funktionieren.

Software verändert die Welt. QCon London stärkt die Softwareentwicklung, indem es die Verbreitung von Wissen und Innovation in der Entwickler-Community fördert. QCon ist eine praxisgetriebene Konferenz für technische Teamleiter, Architekten, Engineering-Direktoren und Projektmanager, die Innovation in ihren Teams vorantreiben.

Präsentiert von: Martin Reynolds - Field CTO bei Harness, und Barani Mohandoss - Director, Cloud Governance, FinOps & E-Tools bei Trimble

Präsentiert von: David Iparraguirre - Senior Product Marketing Manager bei Datadog, und Jessica Yang - Product Manager bei Datadog

Suhail Patel: Dieser Vortrag dreht sich darum, wie wir unsere Software-Engineering-Organisation bei Monzo gestalten und wie wir technisch denken, wie wir über unseren technischen Stack nachdenken, um kontinuierlich auszuliefern, mit Menschen und darüber hinaus, mit autonomen Agenten, mit LLMs, mit allem, was als Nächstes kommen mag. Viele Organisationen, mit denen ich bis heute spreche, sehen ihre Entwicklungs- und Deployment-Umgebungen und Abläufe ungefähr so aus. Wenn Sie in der Lage sind, Ihre eigene Organisation zu gründen, vollständig AI-nativ, können Sie möglicherweise all das umgehen.

Die meisten von uns in regulierten Branchen und an Orten, die schon seit einiger Zeit existieren, ich war auf Panels und in zahlreichen Vorträgen, wo Engineering-Teams in anderen Organisationen einfach akzeptiert haben, dass dies Teil ihres Prozesses ist. Man muss eine Art Bewertung durchführen, bevor man etwas Neues beginnen möchte. Dann muss man eine ganze Reihe von Schritten durchlaufen, bevor überhaupt an Code gedacht oder dieser geschrieben wird.

Ehe man sich versieht, dauert es Tage, Wochen, Monate, um irgendetwas zu veröffentlichen. Ein großer Teil dieser Zeit war die Implementierungsphase. Systeme brauchen nun einmal Zeit zum Aufbau.

Egal, wie viel Planung man im Vorfeld betreibt, das Niederschreiben des Codes in seinem Editor kostet Zeit. Es kostet Personen. Es erfordert Tests.

Diese Gleichung hat sich inzwischen vollständig verändert. Jeder, der anders denkt, sollte meiner Meinung nach einige der Vorträge sehen, wie schnell sich Code generieren lässt. Ja, man gibt möglicherweise ein paar Cent, ein paar hundert Dollar aus, um diesen Code zu generieren.

Code lässt sich wirklich schnell generieren. Eine der zentralen Fähigkeiten, die in dieser Gleichung vielen Menschen fehlt, ist, dass man auch schnell an mehreren Varianten iterieren kann, und zwar parallel. Was früher Tage, Wochen und Monate dauerte und hohe Iterationskosten hatte, wobei man normalerweise nur Zeit für ein oder zwei Iterationen seiner jeweiligen Implementierung hatte,

kann heute in 10, 20 Iterationen der jeweiligen Implementierung münden und dabei herausfinden, welche die beste ist. Das lässt sich in Minuten und Stunden erreichen.

Es gibt im Internet sehr viel zum Thema Messung der Entwicklerproduktivität und wie man dabei wirklich objektiv vorgeht. Es gibt alle möglichen Developer-Experience-Umfragen. Man kann DORA-Frameworks verwenden.

Man kann erhebliche Mengen an Telemetrie einsetzen und wirklich datenbasiert entscheiden, wo man diese Investition platziert. Letztlich ist dies die Art von Erfahrungsbericht, die den Wert der Investition in Technologie im Hintergrund beweist, um einige der langweiligen Prozesse zu automatisieren. Wenn Ihre Ingenieure diese Werkzeuge nutzen und sich darauf verlassen und sie mit großem Nutzen einsetzen können, ist das das beste Testimonial für Ihre Organisation, denn dann merken es auch andere Führungskräfte, Leute aus dem Nicht-Tech-Bereich.

Ingenieure sehen erst, was ihnen fehlt, wenn sie die Organisation wechseln und keinen Zugriff mehr auf dieses gleiche kohärente Ökosystem von Werkzeugen haben, und umgekehrt. Bei uns kommen ständig Ingenieure an, die sagen, in meiner anderen Organisation hatten wir ein anderes System, wir konnten deutlich schneller arbeiten.

Das ist eine wirklich gute Gelegenheit zu lernen. Wenn die Developer Experience sehr viel Reibung aufweist, ist dies ein Grund, warum Ingenieure sich entscheiden könnten, das Unternehmen zu verlassen. Darüber sollten wir uns keinen Illusionen hingeben.

Das Tempo der Veränderung nimmt ebenfalls deutlich zu. Viele Unternehmen investieren stark in AI, um ihre bestehenden Ingenieure zu ergänzen. Letztlich gibt es ein Geschäftsziel.

Wir wollen die Produktivität pro Ingenieur steigern. Ingenieure sind nicht billig. Aus finanzieller Sicht besteht ein starkes Bestreben, die Produktivität pro Ingenieur zu erhöhen.

Als Ingenieure sind wir bereit, in dieser Gleichung complacent zu sein. Wir gewinnen keine zusätzliche Zeit in unserem Kalender. Wir übernehmen mehr Arbeit.

Daher entsteht ein höherer Druck, diese Änderungen auszuliefern. Ein Teil dieser Ermächtigung soll auch außerhalb des Engineering-Bereichs ausgeweitet werden. Werkzeuge wie Claude und Cursor geben Disziplinen im Umfeld des Engineering wie Designern und Produktmanagern Zugang und Erlaubnis, mit Code zu prototypisieren und Änderungen direkt in Ihren primären Codebasen vorzunehmen.

Ich habe an das erste Mal gedacht, als ich Photoshop heruntergeladen habe und dachte, ich könnte ein Designer sein. Was war das für eine Illusion. Oder das erste Mal, als ich FrontPage öffnete und dachte, ich könnte etwas für das Web gestalten, all den generierten Code sehend. Heutzutage, wenn ein Produktmanager oder Designer einen kleinen Bug hat, eine technische Implementierungsfrage oder eine Frage zu Daten hat, zum Beispiel: Was sind unsere aktuellen Geschäfts-KPIs und wie entwickeln sie sich? Warum Zeit damit verbringen, ein Ticket zu erstellen, um eine Datenperson oder eine Engineering-Person zu fragen, ob sie diese bestimmte Sache behebt oder dieses bestimmte Problem untersucht, wenn man einen Versuch über ein LLM starten kann, das es für einen löst?

Auf der anderen Seite sind selbst einige der größten Unternehmen mit zehntausenden Ingenieuren und zahlreichen Teams für Change Management, Softwaretest und Softwarequalität nicht immun gegen das Tempo der Veränderung und die Auswirkungen auf Zuverlässigkeit und Verfügbarkeit. Es gab vor Kurzem einen Artikel im Financial Times. Er ging extrem viral, auf allen Social Media und Hacker News und allen möglichen Orten, und behauptete, AI sei schuld an einer Reihe von Zuverlässigkeitsausfällen bei Amazon.

Amazon musste eine Entgegnung auf seinem Blog veröffentlichen, weil der Artikel besagte, Senior-Ingenieure müssten AI-unterstützte Änderungen abzeichnen. Amazon stellte die Fakten richtig, dass es sich hierbei nicht um AI-spezifische Änderungen handelte. Es ist sehr deutlich, wie die Branche die Rolle von AI in der Softwareentwicklung betrachtet.

Sie mussten sich rechtfertigen, sie mussten eine öffentliche Entgegnung herausgeben, warum dies nicht der Fall war. Abgesehen davon, ob die Entgegnung auf eine menschliche oder AI-getriebene Änderung zurückzuführen war, gab es ein gemeinsames Ziel: Dinge nicht kaputtzumachen.

Niemand wacht morgens auf und weist seinen Agenten an, schlechten Code zu schreiben, so wie ein Mensch nicht eines Tages aufsteht, um schlechten Code zu schreiben. Niemand möchte wegen Ausfällen in den Nachrichten sein. Auf der anderen Seite finde ich es faszinierend zu sehen, welche Prozesse Unternehmen nach einem Vorfall oder einer schiefgelaufenen Bereitstellung einführen.

So entstehen Regeln in unserer Branche, etwa dass wir nicht freitags deployen. Eine wirklich gängige Praxis ist die Einführung von Change Approval Boards, insbesondere in großen Finanzinstituten. Eine Gruppe von Personen, meistens ziemlich missmutig dreinschauend, wie auf dem Foto, typischerweise aus einer Reihe von Bereichen wie Risk und Compliance, Platform, Security und einigen weiteren Bereichen, hat die Befugnis, eine Veröffentlichung notfalls zu stoppen und zu verzögern.

Dann landet man in wirklich miserablen und unproduktiven Meetings wie diesen, um jede kleine Änderung auszuliefern.

In der Praxis werden diese Gremien notwendig, weil Umfang und Art dieser Änderungen einen großen Blast Radius haben oder Änderungen betreffen, die viel Vertrauensbildung erfordern. Sie können sich Ihr Vertrauen nicht einfach per Vibe Coding erarbeiten. Man gelangt an einen Punkt, an dem man bei bestimmter Software das Vertrauen verliert, Änderungen vorzunehmen. Dann herrscht große Trägheit bei den Ingenieuren, selbst einen einfachen Konfigurationswert zu ändern. Dieses Risikoprofil wird selbst mental exponentiell höher. Selbst technisch gesehen mag dieses Risikoexposure recht gering sein.

Mein Name ist Suhail. Ich bin einer der Principal Engineers bei einem Unternehmen namens Monzo mit Sitz in London. Ich arbeite in der Platform-Gruppe.

Ich helfe dabei, die Plattformgruppe zu leiten, in der wir die gesamte zugrunde liegende Infrastruktur, Bibliotheken und Tools von Monzo bereitstellen, damit sich Ingenieure auf den Aufbau einer Bank konzentrieren können und sich nicht um Infrastruktur kümmern müssen. Ich verbringe den Großteil meiner Wachzeit mit Gedanken an die Developer Experience. Wenn ich ganz zynisch sein soll: Was können Entwickler falsch machen?

Wie können sie Fehler in die Produktion bringen? Und wie kann ich verhindern, dass sie diese Fehler in die Produktion bringen? Ich weiß aus eigener Erfahrung, wie eine zersplitterte Erfahrung zu Frustration führt und dann zu mehr Fehlern und mehr Zwischenfällen.

Monzo ist eine auf Verbraucher ausgerichtete Retailbank in Großbritannien. Wir haben auch eine kleine Präsenz in den USA. Zudem erweitern wir in diesem Jahr unsere Aktivitäten auf europäische Märkte.

Wir haben 14 Millionen Kunden und wachsen schnell, sowohl bei unserem Privatkundenangebot als auch im Geschäftskundengeschäft.

Wir haben keine physischen Filialen. Alle unsere Banking-Funktionen werden über eine App bereitgestellt. Es gibt keine Öffnungszeiten, um die man sich kümmern müsste.

Sie erledigen all Ihre Banking-Bedürfnisse zu einer Zeit und an einem Ort, der Ihnen passt. Das bedeutet auf der anderen Seite, dass wir keine Ausfallzeiten haben. Die Menschen erwarten, dass unsere Systeme rund um die Uhr funktionieren.

Ich bekomme immer noch Benachrichtigungen von Banken, besonders von vielen mit Sitz in den USA. Falls jemand aus dem US-Fintech-Bereich hier ist, würde ich gerne mit Ihnen darüber sprechen, wie diese ihre Systeme für ein paar Stunden herunterfahren, um die Sommerzeitumstellung zu bewältigen. Kundinnen und Kunden erwarten heutzutage ein einwandfreies Online-Erlebnis, besonders wenn man sie nicht in einer physischen Bankfiliale betreuen kann.

Das bedeutet, dass wir ein vielfältiges Angebot brauchen, das zuverlässig und zugänglich ist. Ausfallzeiten und Fehler bedeuten, dass Kunden keinen Zugang zu ihrem Geld haben.

Das ist ein ziemlich altes Bild, aber es ist ein verbundener Call-Graph vieler unserer Microservices, die unsere Zahlungsinfrastruktur und auch unsere Produktangebote antreiben. Jeder Punkt repräsentiert einen Microservice, den wir auf unserer Plattform erstellen, betreiben und programmieren. Die verbindenden Linien stehen für RPC-Flüsse zwischen diesen Diensten.

Stellen Sie sich vor, wir müssten jedes Mal, wenn wir eine Änderung vornehmen, einen neuen Dienst hinzufügen oder ein neues System bauen wollen, also einen neuen Punkt oder eine neue Kante hinzufügen, einen komplexen Change-Governance-Prozess durchlaufen. Wir würden im Grunde gar nichts ausliefern. Dieser Vortrag handelt von einigen der wichtigsten Investitionen, die wir getätigt haben, um diese stetig steigende Änderungsrate zu ermöglichen.

Zum Einstieg wollen wir uns die Anatomie eines Microservices ansehen. Das ist unser Developer-Experience-Vertrag mit den Ingenieuren, die bei Monzo arbeiten. Ein Grundprinzip, das wir seit unseren Anfängen verfolgen, ist die Einheitlichkeit darin, wie wir unsere Dienste schreiben.

Für die allermeisten Microservices bauen wir nach derselben Vorlage und verwenden dieselben zugrunde liegenden Abstraktionen. Unsere Plattform- und Sicherheitsteams kümmern sich um die Infrastruktur und verankern zusätzlich die Best Practices in unserer Service-Ebene innerhalb dieser Bibliotheken. Innerhalb eines Microservices füllen die Ingenieure den oberen Teil aus und fügen ihren Code in diesen dünnen Umschlag ein, hier fügen sie ihre Geschäftslogik hinzu.

Ingenieure schreiben Kernabstraktionen wie HTTP-Handler nicht neu und müssen sich nicht um das Konsumieren aus einer Kafka-Queue, um Metriken oder das Marshalling von Daten kümmern. Sie können sich auf einen gut definierten, stark typisierten und gut getesteten Satz von Bibliotheken und Tooling verlassen. All diese gemeinsamen Bibliotheksebenen bieten von Haus aus Telemetrie im Lieferumfang.

Gerade in einer Microservices-Architektur ist eine der zentralen Fragen, den Kriminalfall aufzuklären. Wenn Kommunikationsflüsse zwischen Diensten stattfinden, wie findet man heraus, was schiefgelaufen ist und wo die Daten geflossen sind? Dazu braucht man wirklich gute Telemetrie.

Wir verankern das direkt in unserer Bibliotheksebene, damit es über alle unsere Dienste hinweg verfügbar ist, egal ob Ihr Dienst eine Anfrage oder 1 Million Anfragen pro Sekunde bedient.

Wir hatten viel Glück. Unser Plattform-Stack ist vergleichsweise modern. Wir haben unsere frühen Innovations-Chips 2016 auf Technologien wie Go, Kubernetes und Microservices gesetzt, als Teil unserer Grundlagen.

Seitdem haben wir diesen Stack sehr bewusst erweitert und neue Technologien und Integrationen eingeführt. Ein zentrales Prinzip für uns ist, dass wir diese Komponenten auf Plattformebene den Ingenieuren nicht direkt bereitstellen. Stattdessen bauen wir monzospezifische Bibliotheksabstraktionen darauf auf, die eine leicht zu bedienende Abstraktion bieten, die gut getestet und gepflegt ist und vor allem die Telemetrie eingebaut hat.

Diese Fundament-Entscheidungen haben sich enorm ausgezahlt. Wir haben über 3.000 Microservices gebaut und auf diese skaliert, die in Produktion laufen, und liefern Änderungen hunderte Male pro Tag aus. Wir haben nur ein paar hundert Ingenieure und liefern viele hundert Male am Tag aus.

Ingenieure müssen die Semantik von Kubernetes oder YAML oder komplexe Kafka-Bibliothekslogik nicht verstehen, um Dienste zu schreiben und Dinge auszuliefern.

Sie wollen zentrale Primitive und zentrale Abstraktionen haben, die zuverlässig und dauerhaft funktionieren. Wir pflegen ein Monorepo mit allen unseren Diensten, und in diesem Monorepo gibt es einen Bootstrap-Generator, der eine konsistente Ordnerstruktur für jeden Dienst ausgibt. Wie erwähnt sind die allermeisten unserer Microservices in Go geschrieben.

Das reduziert den kognitiven Aufwand für Ingenieure. Egal, ob Sie schon lange dabei sind oder neu dazugekommen sind, man lernt das Muskelgedächtnis, sich in einem Dienst zurechtzufinden. Alle Dienste sehen im Wesentlichen gleich aus.

Sie folgen derselben Ordnerstruktur, und man erwartet, dass die Datenbanklogik im dao-Ordner liegt. Man erwartet, dass die Queue-Consumer-Logik im consumer-Ordner liegt. Man erwartet, dass die RPC-Ebene im handler-Ordner liegt.

Man weiß, wo sich diese Logikteile befinden. Wir verwenden exakt denselben Software-Stack durchgängig.

Ein zentrales Ziel für uns seit den frühen Tagen ist es, diese Iterationszeit wirklich schnell zu halten. Wenn man einen Microservice generiert, füllt man als Erstes eine API-Spezifikation in einer proto-Datei aus. Wir haben Generatoren auf diesen proto-Dateien geschrieben, um den Code hinter den Kulissen in RPCs zu kompilieren, die in unsere Service-HTTP-Bibliotheken eingebettet sind und die Telemetrie im Lieferumfang enthalten.

Diese Definition kann Dinge wie Validierung umfassen, die über die Standard-Datentypen hinaus automatisch generiert wird, die man in protobuf bekommt. Das erzeugt hinter den Kulissen eine ganze Menge Golang-Code, sodass Ingenieure keine HTTP-Anfragen von Hand schreiben und kein Unmarshalling und keine Konvertierung von Daten in Go-Typen vornehmen müssen. Testen und Mocking werden deutlich einfacher, weil man mit statischen Typen arbeitet.

Wir verwenden proto-Dateien, um deutlich mehr als RPC-Code zu generieren. Zum Beispiel generieren wir auch Queue-Handling-Logik. Queue-Handling folgt demselben Grundprinzip.

Man transportiert Daten über irgendeinen Transport-Bus, also kann man das als Typ definieren. Wir generieren alle Kommunikations-Primitive hinter den Kulissen. Ingenieure können eine Event-Payload-Definition sowie alle Validierungskriterien angeben, ähnlich wie bei RPCs.

Auch hier haben wir ein proto-Plugin, das die Kafka-Consumer- und Producer-Logik generiert, die in unsere Bibliotheken einbindet. Ingenieure können mit diesen stark typisierten Objekten und automatisch generierten Funktionssignaturen arbeiten und müssen sich um den zugrunde liegenden Transport nicht kümmern. Ein großer Vorteil, den wir als Infrastrukturteam und für unsere Sicherheitsteams bekommen, ist, dass sich Bugfixes, neue Funktionen oder Performance-Verbesserungen durchgängig anwenden lassen.

Wir generieren einfach Ihren Service-Stub neu, und Sie erhalten diese Vorteile umsonst.

Das wird sich als ein wiederkehrendes Muster zeigen. Wir haben viel Zeit damit verbracht, unsere eigenen Tools von Grund auf zu bauen und zu betreiben, und auch Open-Source-Tools genutzt, und dabei mit einer tiefen Integration im Sinn, um in unsere Ökosysteme zu passen. Viele dieser Tools sind mit Blick auf Modularität gebaut.

Wir wollen die Funktionen, die diese Tools und Pakete zu bieten haben, verfügbar machen, aber auf eine recht meinungsstarke Weise und mit allem, was dazugehört, statt einfach Tools über die Wand zu werfen und zu sehen, was hängen bleibt. Unser Ziel ist es, unsere Zeit und Energie darauf zu verwenden, Ingenieuren zu helfen und es ihnen zu erleichtern, das Richtige zu tun, sie auf den gepflasterten Weg zu bringen. Es so überzeugend, einfach, schnell und sicher per Voreinstellung zu machen, dass sie sich entscheiden, Software auf der gepflasterten Straße zu bauen.

Dann machen wir es wirklich einfach, diese Software mit Zuversicht zu veröffentlichen.

So glaube ich, baut man eine wirklich gute Developer Experience: wenn man sich hyperfokussiert darauf konzentriert, Ingenieuren zu helfen, das Richtige gut zu bauen, und dann diesen Code schnell, sicher und iterativ in Produktion zu bringen und freizugeben. Wenn ein Ingenieur eintritt und, um die Berechtigung zu erhalten, an unserem Backend zu arbeiten und Code in Produktion zu deployen, durchlaufen wir einen sehr strukturierten Backend-101-Leitfaden, der einen durch alle unsere Tools und all diese Primitive führt. Einmal gelernt, bleibt das während der gesamten Karriere bei Monzo präsent.

Wir zeigen euch alle unsere Tools, wie wir Systeme schreiben, unsere Ansichten zum Schreiben von Go, unsere Logik, wie wir Code strukturieren, unsere Microservices-Architektur und vieles mehr. Einer der groessten Vorteile besteht darin, dass wir diese Dokumentation, all die Standardisierung, die wir im Kopf haben, als Skills kodifizieren und in LLM-Tools hinterlegen koennen.

Diese LLM-Tools halluzinieren keine Service-Pakete und Service-Strukturen. Sie koennen den Code auf aehnliche Weise durchsuchen wie ein Ingenieur. Wir koennen diese Dokumentation direkt zugaenglich machen, weil wir die Zeit und Energie investiert haben, alle unsere Tools und Prozesse zu standardisieren. Wir haben sie fuer Menschen dokumentiert, und jetzt koennen wir sie auch dazu nutzen, Ingenieure zu unterstuetzen.

Zurueck zu dieser Service-Anatomie: Automatisierte Tools wie Claude und Cursor lernen unsere Prozesse zum Schreiben von Code genau wie Menschen und halten sich an die Service-Struktur. Ein weiterer grosser Vorteil ist, dass wir in einem Monorepo ueber 3.000 Beispiele haben, auf die man verweisen kann. Diese KI-Tools lernen staendig unsere konsistenten Muster kennen und koennen im Hintergrund auf implementierte Beispiele zugreifen.

Sie halluzinieren nicht einfach irgendwelche Dinge aus dem Nichts. Am Ende besteht jeder Service aus ein paar Tausend Zeilen tatsaechlicher Geschaeftslogik. Diese Groesse ist fuer eine Gruppe von Ingenieuren wirklich gut verstaendlich.

Man kann einen Pull Request einreichen, und es ist etwas, das sehr leicht zu verstehen ist. Es laesst sich auch innerhalb eines Kontextfensters sehr einfach referenzieren. Ziemlich viele unterschiedliche Services sind in Echtzeit beteiligt, wenn man eine Transaktion auf unserer Plattforma durchfuehrt.

Wenn man beispielsweise seine Monzo-Karte oder eine beliebige Zahlungskarte durch den Terminal zieht, sind viele Services an diesem Ablauf beteiligt, um eine Entscheidung zu treffen.

Wir haben ein sehr kleines Zeitbudget, um darauf zu antworten, ob wir diese bestimmte Zahlung akzeptieren oder ablehnen. Dinge wie die Pruefung, ob genug Geld auf dem Konto ist und ob es sich um Betrug handelt, um sicherzustellen, dass wir uns gegen Finanzkriminalitaet schuetzen, und eine ganze Reihe weiterer Bereiche, die wir kategorisieren muessen, damit eine bestimmte Zahlung akzeptiert wird. Eine zentrale Herausforderung besteht darin, dass Ingenieure staendig Aenderungen am System vornehmen, um sich an das sich schnell veraendernde Umfeld anzupassen.

Ingenieure moechten diese Ablaeufe Ende-zu-Ende testen koennen. Wir haben einen starken Anreiz, sie dazu zu ermutigen. Im Kern sind wir eine Bank.

Ein Grundprinzip einer Bank ist die Annahme und Abwicklung von Zahlungen. Genau das moechten wir kontinuierlich Ende-zu-Ende testen. Wir wollen, dass Ingenieure Vertrauen in die Aenderungen haben, die sie ausliefern.

Historisch gesehen hatten wir keine besonders gute lokale Entwicklungserfahrung, wenn es darum ging, den kompletten Stack zum Laufen zu bringen.

Stellt euch vor, um etwas in diesem Ablauf zu aendern, muesstet ihr 250 Microservices hochfahren, jeder mit seinen eigenen Abhaengigkeiten, Konfigurationen und vielem mehr. Darueber hinaus laufen auch noch Machine-Learning-Modelle als Teil dieser Pipeline. Machine-Learning-Modelle bedeuten, dass man eine Python-Umgebung einrichtet und zu den Python-Goettern betet, dass dies das pyenv sein moege, das fuer mich funktioniert, mit dieser Version von pip und dass alle Abhaengigkeiten in Ordnung kommen.

Das ist ein kleiner Albtraum. Wenn das ueber ein breites Spektrum von Ingenieuren hinweg geschieht, ist das etwas, das wirklich komplex zu verwalten ist. Stellt euch vor, wir wollten das auch auf eine Gruppe von Nicht-Ingenieuren ausweiten.

Stellt euch vor, man bittet einen Produktmanager, Python zu installieren, zu den Python-Goettern zu beten und ein Opfer darzubringen, und hoffentlich kann er dann das Machine-Learning-Modell zum Laufen bringen. Er haette enorme Reibung, und genau das wollen wir loesen.

Es gab vor ein paar Jahren eine wirklich gute Praesentation von Soam, der Stripe vertrat, in der sie darueber sprachen, wie sie dieses Problem geloest haben. Stripe stellte entfernte Instanzen bereit, die pro Ingenieur zugewiesen wurden. Ein Ingenieur konnte eine oder mehrere Instanzen haben.

Sie bauten Tooling, um Code automatisch von ihrem lokalen Rechner in diese Dev-Box zu synchronisieren. Im Wesentlichen war dies eine Instanz, die in der Cloud lief, eine Menge Code auscheckte, und man konnte den gesamten Stripe-Stack oder einen Teil des Stripe-Stacks auf dieser Maschine hochfahren. Sie arbeiteten stark an der Benutzererfahrung, damit es sich anfuehlte, als entwickle man auf seinem lokalen Rechner.

Es fuehlte sich an, als wuerde man die Aenderung lokal ausfuehren und testen. Genau diese Erfahrung wollten wir nachbilden. Wir wollten Ingenieuren ermoeglichen, lokal schnell zu entwickeln und zu iterieren, aber die tatsaechliche Logik dann auszufuehren, wenn es um den vollstaendigen Ende-zu-Ende-Test in einer entfernten Umgebung ging.

Wir begannen mit einer sehr grundlegenden Praemisse. Wenn man eine Aenderung in einer Teilmenge von Services vornehmen moechte, sollte man nicht die gesamte Kette von Services ausfuehren muessen, um die Aenderung Ende-zu-Ende zu testen. Viele der von mir erwaehnten Services haben ihr eigenes Datenmodell, Abhaengigkeiten von Drittanbietern und viele andere Dinge.

Wir wollten diese Reibung unseren Ingenieuren nicht aufbuergern. Wir hatten einige Optionen auf dem Tisch. Wenn man es aus einer First-Principles-Perspektive betrachtet, ist eine Idee, sich stark auf Mocking und Testvertraege sowie aufgezeichnete Ausgaben und Mocking ueber Service-Grenzen hinweg zu stuetzen.

Diese Emulation bringt einen nur begrenzt weit. Wir fanden, dass der sicherste Ansatz darin besteht, den Code tatsaechlich selbst auszufuehren, statt zu versuchen, seine Nebeneffekte zu emulieren oder zu verschleiern. Wir haben eine voll funktionsfaehige Staging-Umgebung, die eine Kopie all unserer Services ausfuehrt und bei der die gesamte Integration fuer einen uebernommen wird.

Wir betreiben unseren gesamten Plattform-Stack auf dieser Staging-Umgebung. Sie ist vollstaendig konfiguriert und voll betriebsbereit. Wir haben sie zum Beispiel in einen Test-Rack integriert, der direkt mit MasterCard und vielen anderen Bereichen kommuniziert.

Natuerlich konzentrierten sich unsere Ingenieure darauf, ihre Aenderungen hauptsaechlich in der Staging-Umgebung zu testen und ihre Aenderungen Ende-zu-Ende zu pruefen. Die Ingenieure deployten im Wesentlichen aus einem Branch heraus und brachten das auf die Staging-Umgebung. Als wir mehr Ingenieure hinzunamen, stiessen wir auf zahlreiche Services unter Konkurrenz.

Wenn man zum Beispiel etwas im Account-Service aendert, haben wir nur einen einzigen laufenden Account-Service. Die Ingenieure standen in Konkurrenz, um Aenderungen an diesem Account-Service vorzunehmen. Mehrere Ingenieure wollten ihren Code ausfuehren.

Wir mussten einen Weg finden, damit zahlreiche Ingenieure denselben Service ausfuehren koennen, ohne die gesamte Plattform laufen zu lassen und ohne den gesamten gemeinsamen globalen Namespace zu stoeren.

Ein kurzer Ueberblick dazu, wie unsere Staging-Umgebung funktioniert. Wenn eine Anfrage in unserer Staging-Umgebung eingeht, routen wir die Anfrage einfach ueber Standard-HTTP an den Service, der im selben Staging-Namespace laeuft. Angenommen, ihr habt den Pink-Service auf der linken Seite.

Er moechte mit dem Aqua-Service am Boden kommunizieren. Er kann in diesem Aufrufpfad von einer Reihe anderer Services abhaengig sein. Er tauscht einige Anfragen im Ping-Pong-Verfahren aus und sendet die Antwort direkt zurueck.

Was wir getan haben, ist, eine Ebene zu bauen, in der Ingenieure ihren eigenen individuellen Namespace innerhalb der Staging-Umgebung erstellen und nur die Services deployen koennen, die sie geaendert haben. Wir nennen dieses System Tenancies. Das bedeutet, dass ein Ingenieur nicht alle Services ausfuehren muss, die Teil der Ende-zu-Ende-Anfragekette sind, die er testet.

Er muss nicht alle 250 Services kennen und in einer voellig separaten Umgebung zum Laufen bringen.

Das bedeutet, dass er seine geaenderten Bereiche Ende-zu-Ende testen kann. Wenn zum Beispiel ein Service Teil dieses Pfades ist und auf ihn zugegriffen wird, ruft er in den gemeinsamen Namespace auf. Ausserdem vermeiden wir, dass pro Ingenieur dedizierte Infrastruktur hochgefahren wird.

Ein Ingenieur kann eine oder mehrere Tenancies gleichzeitig laufen haben. Diese Tenancies sind Namespaces in unserer Staging-Umgebung und lassen sich daher sehr schnell bereitstellen. Wenn ihr beispielsweise mit Kubernetes gearbeitet habt, haben wir einen Kubernetes-Namespace.

Dies erweitern wir auch um andere Infrastruktur-Abstraktionen. Ein Kubernetes-Namespace ist sehr einfach zu erstellen und sehr einfach zu zerstoeren. Dies sind Namespaces in Kubernetes, in Cassandra und in Kafka.

Wir haben ein intelligentes Handling davon auf unserer Bibliotheksebene. Wenn eine Anfrage eingeht und ueber eine Tenancy geroutet wird, routen wir diese Services, die nicht in der Tenancy laufen, intelligent zurueck in denselben gemeinsamen Staging-Namespace.

Das funktioniert bidirektional. Ein Service im gemeinsamen Namespace kann in die Tenancy aufrufen, wenn er nach aussen routen muss. Die Methode dazu ist nicht besonders ausgefeilt. Was wir im Wesentlichen tun, ist einen Header hinzuzufuegen. Wir fuegen jeder Anfrage einen Header hinzu, aehnlich wie man einen Header fuer OpenTelemetry oder jede andere Art von Information ueber Anfragegrenzen hinweg mitgibt. Wir fuegen einen Header hinzu, der sagt, dies laeuft als Teil einer Tenancy, daher musst du vielleicht etwas Besonderes bei deinem Anfrage-Routing tun. Wir greifen in das gesamte Routing dieser Anfragen an unserem Service Mesh ein und machen dieses intelligente Routing.

Das funktioniert sehr gut für zustandslose Anfragen. Außerdem wollen wir eine gegenseitige Kontamination von Daten vermeiden. Nehmen wir zum Beispiel an, dass ein Service in diesem gemeinsamen Namespace deployt ist, aber Sie irgendwelche fehlerhaften Daten erzeugen.

Diese Daten mögen für die Services, die sie annehmen, gültig aussehen und alle Validierungsprüfungen bestehen. Zum Beispiel sind sie aus logischer Sicht betrachtet trotzdem fehlerhaft. Sie sollten die Queue und die Datenspeicher des gemeinsamen Service nicht dauerhaft kontaminieren.

Wir haben dafür eine Handhabung auf der Ebene unserer Shared Library implementiert. Jede unserer gemeinsamen Komponenten unterstützt Tenancies. Sie verstehen, was es bedeutet, eine Anfrage zu verarbeiten, die aus einer Tenancy stammt.

Zum Beispiel bedeutet das auf unserer Cassandra-Ebene, dass diese Daten in einen eigenen Container segmentiert werden. Auf unserer Kafka-Ebene bedeutet es, dass die Kafka-Nachricht in ein eigenes Topic und eine eigene Queue geroutet wird und nicht das Haupt-Topic verschmutzt.

Das bedeutet, dass man nicht mit einer Queue-Nachricht endet, die in einer Tenancy erzeugt wurde und zwar gültig, aber unlogisch sein kann, und die eine Queue blockiert, weil der Code zu ihrer Verarbeitung nicht im globalen Namespace vorhanden ist. Wie ich bereits erwähnt habe, sind diese Tenancies sehr leichtgewichtig und können in wenigen Minuten provisioniert werden, sodass wir Hunderte und Tausende von ihnen gleichzeitig laufen lassen können. Wenn eine Tenancy nicht mehr benötigt wird, können wir sie genauso schnell wieder herunterfahren.

Dieses Paradigma hat sich hervorragend bewährt, um das Problem der Konkurrenz zwischen Ingenieuren zu lösen, weil wir nun all diese Tenancies für alle unsere Ingenieure provisionieren können und einzelne Ingenieure zahlreiche Tenancies gleichzeitig nutzen können. Dieses Paradigma konnten wir auch erweitern, um es für Akzeptanztests zu nutzen. Früher liefen unsere Akzeptanztests auf unserer Staging-Umgebung.

Diese Akzeptanztests mussten nacheinander geplant werden und waren fehleranfällig, wenn ein Ingenieur während des Tests eine Änderung an einem Service deployte, der Teil des Akzeptanztests war, möglicherweise mit fehlerhaftem Code. Wir haben das Vertrauen in diese Tests erhöht, und jetzt führen wir diese Akzeptanztests als Teil eines Pull Requests durch, weil wir in der Lage sind, diese Testlogik selbst in einer Tenancy zu deployen.

Sobald alle Ihre Änderungen vorbereitet sind, können Sie einen Pull Request einreichen und um eine Überprüfung durch die Code-Owner des jeweiligen Service bitten. Im Hintergrund, während Sie eine menschliche Überprüfung einholen, führen wir bereits eine Reihe von CI-Prüfungen durch und validieren die Struktur und die Logik Ihres Codes. Bevor wir diese Prüfungen verpflichtend machen, fügen wir kontinuierlich weitere Prüfungen hinzu.

Wir entwickeln kontinuierlich neue Prüfungen auf der Grundlage der Erkenntnisse, die wir gewonnen haben. Wir stellen sicher, dass wir unsere bestehende Codebasis bereinigen, damit Ingenieure nicht durch fehlgeschlagene Prüfungen aus dem Konzept kommen, die durch Code entstehen könnten, der nichts mit ihrer Änderung zu tun hat. Das bedeutet, dass diese Prüfungen ein wirklich hochwertiges Signal für unsere Ingenieure darstellen und Ingenieure nicht dazu übergehen, diese Prüfungen zu ignorieren.

Was wir erreicht haben, ist, dass wir eine erhebliche Hürde für die Umgehung dieser Prüfungen eingebaut haben.

Zum Beispiel müssen Sie an mehrere Personen eskalieren und praktisch ein Notfallverfahren durchlaufen und begründen, warum Sie diese Prüfungen umgehen. Wir wollen, dass der gepflasterte Weg das korrekte Verhalten ist, der Weg des geringsten Widerstands, indem wir all diese Prüfungen vorschreiben und ein wirklich hohes Signal sicherstellen. Ich bin fest davon überzeugt, dass es der größte Bereich technischer Hebelwirkung ist, seine Prüfungen robust, schnell und leicht verständlich zu machen.

Das ist nichts, was man einfach mit einem fertigen Produkt kaufen könnte. Es gibt einige Anbieter, die darauf hinweisen, dass man sein CI so viel besser machen kann. Ich denke, im Grunde muss man dies als technische Disziplin in die eigene Organisation einbetten.

Es erfordert viel Aufwand, CI-Prüfungen zu einem hohen Signal zu machen, und ich halte das nicht für optional. Wenn ein Vorfall durch einen Codefehler auftritt, sollte man sich konkret die Frage stellen: Wie kann ich das in eine Prüfung umwandeln, damit dieser Fehler in Zukunft nicht mehr auftritt?

Wenn Ihre CI-Prüfungen langsam oder fehleranfällig sind, ist das ein wirklich hervorragender Bereich, um gemeinsam mit LLM-Tools die Engpässe zu finden und zu beseitigen. Jeder PR, der in Produktion geht, erfordert eine menschliche Überprüfung, sodass alle Services einen menschlichen Code-Owner haben, der als verpflichtender Prüfer sicherstellt, dass eine Änderung den Ownern der Services gut kommuniziert wird. Unsere Services ändern sich ständig.

Wir haben Ingenieure, die überall im gesamten System beitragen. Es ist nicht so, dass Ingenieure nur zu Services innerhalb ihres Teams beitragen. Ingenieure tragen zum gesamten Microservice-Ökosystem innerhalb von Monzo bei, weil alles in einem Monorepo liegt und alle Service-Strukturen gleich aussehen, sodass man dieses Element der Vertrautheit hat.

CI gibt Ihnen die Sicherheit, dass Sie die Sache korrekt gebaut haben. Wir können die Logik des Codes prüfen und sicherstellen, dass Sie Ihr Error-Handling und Ähnliches korrekt umsetzen, was Zeit und Energie für unsere menschlichen Reviewer und Teams freisetzt, damit diese prüfen können, ob wir das Richtige gebaut haben.

Das sind die beiden grundlegenden Dinge. Sie wollen sicherstellen, dass Sie das Richtige gebaut haben und die Produktanforderung lösen, die Sie lösen wollten, und dann, dass Sie die Sache korrekt gebaut haben. Stellen Sie sicher, dass Ihre gesamte Logik stimmt. Wir investieren einen erheblichen Teil unserer Zeit und Energie in deterministische Tests, ob wir etwas korrekt gebaut haben, damit wir unsere menschlichen Kapazitäten darauf verwenden können sicherzustellen, dass wir das Richtige gebaut haben.

Ein Bereich, der kontinuierlich weiterentwickelt wird und viel Aufmerksamkeit erhält, ist die Fähigkeit, Code zu analysieren und zu reviewen. Das kann durchaus ein Vorteil sein, aber falsch implementiert erhält man einfach eine Menge Nits, also Dinge, die völlig irrelevant sind, keine großen logischen Mängel finden, sondern nur auf Tippfehler hinweisen. Aus meiner Sicht braucht man keinen ausgefallenen KI-Code-Reviewer, um all Ihre Probleme zu lösen.

Stattdessen sollten Sie die Zeit und Energie darauf verwenden, wirklich hochwertige CI-Prüfungen zu schreiben, die sich selbst bezahlt machen. Sie sind deterministisch. Wenn Sie KI-basierte Reviews einsetzen, stellen Sie sicher, dass sie ein hohes Signal liefern und tatsächlich auf Probleme in der Geschäftslogik prüfen, also darauf, dass Sie für das richtige Produkt gebaut haben, statt auf triviale semantische Nits.

Bei uns introspektieren diese CI-Prüfungen, die wir gebaut haben, den Code eingehend, um fehlerhafte Logik oder Verhaltensweisen zu kennzeichnen, die wir missbilligen.

Wir setzen sehr stark auf den Go AST Parser und neue Pakete wie analysis, um diese Prüfungen zu erstellen. Wir haben eine Reihe kleiner, unabhängiger Prüfungen, die sehr schnell laufen. Man kann sie lokal auf seinem Rechner ausführen, um nach Mustern zu suchen, die wir stark missbilligen.

Man kann sie als Teil eines Git-Push als Pre-Push-Hook ausführen. Zum Beispiel haben wir eine Prüfung, die feststellt, ob Sie Cross-Service-Pakete importieren, was wir missbilligen. Beispielsweise wollen wir sicherstellen, dass Sie nur dann mit Code aus einem anderen Paket kommunizieren und ihn importieren, wenn die Kommunikation über Servicegrenzen hinweg erfolgt, statt einfach direkt seinen Code zu importieren.

Wir wollen sicherstellen, dass Services entkoppelt sind und nicht von internen Implementierungsdetails abhängen. Dies kann auch für den Aufbau sicherer Services gelten. Für jeden unserer Services wollen wir Egress- und Ingress-Firewall-Fähigkeiten sicherstellen.

Zum Beispiel haben wir einen API-Service. Es ist ein relativ einfacher API-Service, der alle unsere Bankfilialen ausgibt. Ich glaube, es ist Teil einer britischen Verordnung, dass man eine API haben muss, die auf programmatische Weise alle physischen Bankfilialen liefert. Bei uns ist es eine sehr stabile API, die die leere Liste zurückgibt. Dieser Service muss keinerlei Kommunikation mit irgendeinem anderen Service aufnehmen, um eine leere Liste auszuliefern. Er sollte nicht nötig haben, mit dem Ledger oder irgendeinem anderen Drittanbieter-Service zu kommunizieren, um diese bestimmte API-Anfrage zu bearbeiten.

Denken Sie erneut an unseren Microservice-Graphen. Wir haben viele laufende Services und wollen nicht, dass Ingenieure all diese Verbindungen von Hand verwalten. Dabei macht man sehr leicht Fehler und öffnet eine Schwachstelle.

Stellen Sie sich in dieser Branches-API vor, dass eine Drittanbieter-Abhängigkeit als Teil des Software-Stacks eingeführt wurde, die mit einem Command-and-Control-Zentrum kommuniziert. Dank all dieser statischen Analyse können wir diese Firewall-Fähigkeiten auf eine wirklich schöne Weise aufbauen, die für Ingenieure leicht nachvollziehbar ist: Man fügt explizit eine Regel für die Kommunikation mit einem Drittanbieter hinzu und blockiert sofort alles andere. Wir erzeugen eine Reihe solcher Regeldateien, die neben Ihrem Code liegen und alle gültigen Egress-Möglichkeiten auflisten, die Sie von Ihrem Service aus nutzen dürfen, und checken diese zusammen mit Ihrem Service-Code und Ihren Pull Requests ein.

Diese_checks sind peer-reviewed und liegen neben dem Service-Code. Das bedeutet, dass wir eine Prüfung in die CI einbauen können, um sicherzustellen, dass diese Daten bei jeder Änderung konsistent bleiben, unsere Sicherheitslage straff bleibt und alle zufrieden sind. Beim Schreiben solcher Prüfungen war ich meist ein großer Verfechter von Tools wie Semgrep, weil sich damit statische Analyseprüfungen wirklich einfach schreiben lassen. Semgrep funktioniert außerdem über eine Vielzahl von Programmiersprachen hinweg. Man kann Prüfungen für SQL schreiben, Prüfungen für Python und für viele weitere Programmiersprachen. Man muss sich dabei nicht in die Details oder abstrakte Syntaxbäume all dieser verschiedenen Sprachen einarbeiten.

Was ich vor relativ kurzer Zeit entdeckt habe, ist, dass die Arbeit an solchen Prüfungen mit Claude ein echter Türöffner dafür war, nativere Syntaxprüfwerkzeuge zu schreiben. Es war ein absoluter Game Changer für das Testen komplexer Logik. Man möchte zum Beispiel beispielsweise die Lebensdauer einer Variable über Funktionen hinweg verfolgen, um sicherzustellen, dass sie nicht gleichzeitig verändert wird.

Ich empfehle Ihnen wärmstens, das einmal auszuprobieren. Gerade wenn man einen Korpus von Testfällen und Beispielen generiert, kann man sich einen Analyzer von Claude erstellen lassen, ohne eine Menge AST-Parsing-Code von Hand zu schreiben. Es kann eine wirklich starke Inspirationsquelle sein.

Statische Analyse ist auch ein sehr guter Weg, eine Codebasis auf einen Pfad der Konsistenz und der Konventionen zu bringen. Die Einführung einer neuen statischen Analyseregel verhindert, dass weiterer schlechter Code zusammengeführt wird, und unterstützt Bereiche, die man ablösen möchte. Anschließend kann man sich darauf konzentrieren, bestehende Verwendungsfälle zu entfernen.

Auch das ist eine wirklich wirkungsvolle Möglichkeit, LLM-Tools einzusetzen. Wenn sie in der Lage sind, diese Prüfungen über die gesamte Codebasis laufen zu lassen, können sie alle Verwendungsfälle identifizieren und dann effektiv einen Teil der Fleißarbeit übernehmen, Pull Requests stellen und einige dieser Probleme im Hintergrund beheben, und sicherstellen, dass diese Probleme behoben werden, weil man Zeit in die Erstellung einer deterministischen Prüfung investiert hat. Anstatt heutzutage eine Menge Zeit damit zu verbringen, Ausnahmen fest zu codieren, besteht eine der wichtigsten Aufgaben, wenn man einen grünen Build sicherstellen will, darin, viel Zeit damit zu verbringen, alle Ausnahmen zu bewerten und zu sagen: wird nicht behoben, oder ignorieren wir das für diese bestimmte Prüfung.

Stattdessen kann man es einfach in ein LLM einspeisen und fragen: Kannst du das beheben? Wenn nicht, füge ein Ignore-Tag hinzu.

Sobald ein Service im Einsatz ist, benötigt man Einblick darin, wie er funktioniert. Gerade in der Ära der LLMs und autonomer Systeme, die Code ausgeben, ist es sehr leicht, fehlerhaften oder schlecht funktionierenden Code zu deployen. Wir nutzen viele Open-Source-Tools wie Prometheus, Grafana und OpenTelemetry, um unsere Observability-Infrastruktur zu betreiben.

Wir investieren sehr stark in das Erfassen und Sammeln all dieser Telemetriedaten aus unseren Services und unserer Infrastruktur. Das ist nicht billig. Wir zahlen eine Menge Geld dafür.

Wir sind jedes Mal dankbar, wenn wir einen Vorfall haben und die beitragenden Faktoren identifizieren können, weil wir all diese Telemetriedaten haben. Für jeden Service, der mit unseren Batterien-inklusive-Bibliotheken und Tools in Betrieb geht, erhalten wir Tausende und Zehntausende von Datenpunkten, die wir auf ein generisches Dashboard geplottet haben. Auch hier können wir LLM-Tools Zugriff darauf geben, um bei Vorfällen bei der Fehlersuche in unseren Systemen zu helfen.

Das fließt auch in Alerts ein. Wir haben automatisierte Alerts für alle unsere Services, die auf diesen gängigen Metriken basieren und sich auf einen deployten Change zurückverfolgen lassen. Alerts werden automatisch an das richtige Team weitergeleitet, dem der jeweilige Service gehört.

Bei den meisten Backend-Systemen ist Performance-Profiling aus verschiedenen Gründen meist abgeschottet. Besondere Privilegien, man braucht Root-Zugriff auf die Maschine und Ähnliches. Nur wenige Organisationen sind bereit, Ingenieuren die Möglichkeit zu geben, Profiler in der Produktion auszuführen.

Diese Haltung muss sich wirklich ändern. Man braucht Fähigkeiten, um in seine Systeme hineinschauen zu können. Viele Sprachen bieten mittlerweile integrierte Profiler, die wirklich leistungsfähig sind und praktisch keinen oder nur einen sehr geringen Overhead verursachen.

Wir machen es Ingenieuren sehr leicht, den Go-Profiler in unseren Backend-Systemen aufzurufen, und bieten eine schöne Web-UI an, über die man diese Profile anfordern kann. Java hat wirklich gute Tools mit Flight Recorder. Wenn man Python verwendet, ist auch py-spy wirklich gut.

Sehr geringer Overhead.

Ich habe darüber gesprochen, wie man Entwicklerwerkzeuge wirklich schnell macht. In letzter Zeit habe ich viel im Bereich Data Engineering gearbeitet. Die meisten dieser Tools sind in Python geschrieben.

Es ist sehr leicht, ineffizienten Python-Code zu schreiben. Viele Objekte kopieren, etwas zwischen einer Map und einer Liste umwandeln. Man bekommt die Illusion vermittelt, dass ein einzelner Funktionsaufruf relativ billig ist.

Dann hat man eine Million Operationen, die in einem DataFrame durchgeführt werden. Diese sehr billige Logik ist sehr zeitaufwendig geworden. Eine einfache native Implementierung hätte deutlich weniger Overhead.

Es gibt reichlich Gelegenheiten, Verbesserungen und Optimierungen zu finden. Ein paar Sekunden, ein paar Dutzend Sekunden oder ein paar Minuten aus einem Entwicklerwerkzeug herauszuholen, ist eine spürbare Verbesserung. Es gibt auch Tools wie Pyroscope, mit denen man kontinuierliches Profiling betreiben kann.

Die Software wird laufend profiliert, sodass man erkennen kann, ob eine Änderung eine Verschlechterung der Performance verursacht hat.

In eine Sprache übersetzt, die Wirtschaftlichkeitsverantwortliche verstehen: Je schneller der Code läuft, desto weniger Server braucht man, desto niedriger ist die Cloud-Compute- oder Infrastrukturrechnung. Um Ingenieure dafür zu incentivieren, haben wir einen Slack-Kanal namens Graph Trending Downwards. Dort können Ingenieure mit ihren Optimierungen angeben.

Sie können der Welt davon berichten. Alle unsere Engineering-Leader, unser CTO und unsere Engineering-Direktoren schauen regelmäßig in dem Kanal vorbei und würdigen diese Optimierungen, etwas, mit dem man zur Review-Saison angeben kann. Das ist ein klarer Nutzen für die gesamte Engineering-Disziplin.

Es ist eine Tätigkeit, die in persönlichen Reviews und Feedback belohnt wird. Auch das ist eine wirklich hervorragende Möglichkeit, autonomes Codieren zu nutzen. Anstatt ihm ein großes Programm zu geben und blind zu sagen, finde alle Möglichkeiten zur Optimierung, kann man ihm ein CPU- oder Memory-Heap-Profil sowie Zugriff auf den Code geben.

Es kann Optimierungen gezielt dort ansetzen, wo es Hotspots im Code gefunden hat. Es kann zum Beispiel die Anzahl der Aufrufe einer teuren Funktion reduzieren oder gleich von vornherein die teure Funktion optimieren. Ich kenne Teams, die LLMs für das Bug-Tracking eingesetzt haben. Man hat LLMs beispielsweise in Sentry oder andere genutzte Tools eingebunden. So gibt es etwa einen Button, der sagt: Du hattest eine Exception, geh und versuche, sie zu beheben, indem du Zugriff auf den Code erhältst. Das Gleiche kann man mit Performance-Profiling machen, dann werden Ihre Ingenieure viel zufriedener sein und auch Ihre Finanzverantwortlichen.

Zum Schluss sprechen wir über das Debuggen von Systemen in der Produktion. Es ist wichtig, dass Ingenieure die Geschäftslogik debuggen können. Alles andere können Sie debuggen.

Warum sollten Sie Ihre Geschäftslogik nicht debuggen können? Manchmal bedeutet das, Service-Endpunkte abzufragen und zu sehen, in welchem Zustand sich die Daten befinden, selbst in der Produktion. Das kann man unter Berücksichtigung von Privatsphäre und Datenbereinigung anbieten.

Ich sehe in vielen Organisationen zwei Extreme. Entweder müssen Ingenieure betteln und flehen, um Zugriff auf die Produktionsdatenbank zu bekommen oder Endpunkte direkt in der Produktion aufrufen zu dürfen, unter einer gewissen Illusion von Sicherheit. Oder auf der anderen Seite müssen sie viele Logzeilen hinzufügen und viel Wackelarbeit mit Telemetrie und Deployments betreiben, um herauszufinden: Das war es definitiv nicht.

Definitiv das hier. Ich habe definitiv diese Funktion dort drüben durchlaufen, um ihre Systeme zu debuggen.

Was wir getan haben, ist, eine CLI zu bauen, die es erlaubt, direkt mit der Produktion zu kommunizieren. Diese autorisiert sich sicher auf unserer Plattform und ermöglicht es Ingenieuren, direkt mit unseren Backend-Services zu interagieren, Service-Konfigurationen zu verwalten, Operationen zu planen, mit unserer Infrastruktur zu interagieren und vieles mehr. Es ist unser meinungsbildnerischer Weg, Funktionsbausteine bereitzustellen, die eine Kette von Requests darstellen können.

Zum Beispiel das Konfigurationsmanagement. All das wird über die CLI abgewickelt. Wir haben erst kürzlich eine sehr starke Validierung in unser Konfigurationsmanagement eingebaut, um sicherzustellen, dass Ingenieure keine unlogischen Änderungen in unser Konfigurationssystem einbringen.

Wir haben auch Dinge wie Peer-Reviews eingebettet. Zum Beispiel haben wir unser eigenes Multi-Party-Authorization-System gebaut, das es erlaubt, ein zweites Paar Augen für die Prüfung von Änderungen hinzuzuziehen. Oder wenn man beispielsweise einen sensiblen RPC aufruft, braucht man die Genehmigung des codeverantwortlichen Teams, um sicherzustellen, dass man keine schlechten Änderungen in der Produktion vornimmt.

Ich sehe viele Power-User, die stolz auf ihre Kommandozeilen-History sind, auf anpassungsfähige Shell-Befehle. Vielleicht haben Sie ein wirklich ausgefallenes Postman-Skript oder diesen fantastischen curl-Befehl. Wenn man das jedoch als Tool baut, kann jeder beitragen und jeder profitiert. Einer der größten Netto-Vorteile, die wir sehen, ist, dass wir auch Nicht-Engineering-Kollegen haben, die die Pound CLI täglich nutzen. Das sind Leute, denen ein großes IPython-Notebook oder ein Postman-Skript allein nicht angenehm wäre.

Viele der Tools, die ich gezeigt habe, richten sich an Backend- und Frontend-Entwickler. Man kann auch in Bereichen wie Machine Learning und Mobile Testing Dinge automatisieren. Wir haben zum Beispiel eine ganze Menge Tooling, das ML-Service-Code generiert und ihn für Training und Testing auf Basis von Vertex AI vorbereitet, dann ein Modell nimmt, auf unserer Plattform baut und deployt.

Zum Beispiel das, was ich auf dem Bildschirm zeige: Wir haben ein CLI-Tool, das mit dem Android-Emulator interagiert, um Aufgaben zu automatisieren, die ein Android-Entwickler täglich erledigt. Gerade wenn man Android-Entwickler ist und irgendeine Form von Release-Testing durchführt oder für das QA des Releases dieser Woche verantwortlich ist, sind diese Dinge ein Geschenk des Himmels, um automatisierte Screenshots zu erstellen, Vergleiche anzustellen, automatisierte Tests auszuführen und den Emulator zu starten und Ähnliches.

Wir haben das branchenweit gelöst, und es ist sehr schön zu sehen, dass CLIs ein Comeback feiern. Hoffentlich führt das zu mehr Investitionen in CLIs. Diese Analogie lässt sich auch auf die Ermöglichung von Veränderungen durch eine breitere Gruppe von Menschen jenseits der Entwickler übertragen.

Wir wollen, dass Entwickler und Nicht-Entwickler unseren gepflasterten Weg nutzen. Unsere Tools müssen schnell und zuverlässig und gut verstanden sein. Selbst für LLMs führt der Aufruf deterministischer Tools zu einem deutlich zuverlässigeren Ergebnis.

Denken Sie an all die Provisioning-Schritte, die ein Entwickler möglicherweise durchführen muss, und an das Kompilieren bei der Arbeit an einer Änderung. Wenn Entwickler eine ganze Reihe von Verrenken aufführen müssen, um ihre Entwicklungsumgebung zu entblocken und zu den Python-, Ruby- oder Node-Göttern beten, viele zufällige Pakete installieren und Minuten oder Stunden darauf warten müssen, dass ihre Software kompiliert, geben die Leute auf und versuchen, Ihren gepflasterten Weg zu umgehen. Wenn es viel einfacher ist, sich bei einer Drittanbieter-Plattform anzumelden und zu Vercel oder einem anderen System zu shippen, dann werden sie genau das stattdessen tun.

Sie werden einen Weg finden. Damit haben Sie im Effekt immer mehr Vibe Coding ermöglicht.

Um das alles zusammenzufassen und zu bündeln: Ich habe exemplarisch einige der Tools gezeigt, die wir gebaut haben, und das sind Investitionen über das vergangene Jahrzehnt, um unsere organisatorischen Prozesse in Code zu fassen. Lassen Sie sich von dem, was wir gebaut haben, inspirieren, finden Sie die Stellen, an denen Ihre organisatorischen Prozesse bröckeln, und schaffen Sie Wirkung, indem Sie sie automatisieren und einfacher machen. Viele Unternehmen investieren erheblich in eine breitere Zugänglichkeit von LLMs, und effektiv braucht man dafür das Fundament, um das ermöglichen zu können.

Die Hürden für Investitionen in diese Tools sind deutlich gesunken und werden weiter geringer. Investitionen in diese zentralen Engineering-Fähigkeiten, wie deterministische Code-Generatoren, standardisiertes Paketmanagement, konsistentes Test-Tooling, zuverlässige Telemetrie, wirklich zuverlässige Staging-Umgebungen und Profiling, haben einen enormen Ertrag in einer Welt, in der wir Menschen und LLMs und darüber hinaus ermöglichen, und in der die Kosten der Code-Generierung deutlich billiger geworden sind.

Wir wollen diese schnelle Iteration ermöglichen, und LLMs können Entwickler verstärken, wenn all diese anderen Dinge so geregelt sind, dass die Hypothese schneller und sicherer validiert wird, statt blind zu fliegen. Indem wir auf eine kleine Auswahl von Technologie-Entscheidungen standardisieren und diese Abstraktionen kontinuierlich verbessern, ermöglichen wir Entwicklern und LLMs, sich auf das jeweilige Geschäftsproblem zu konzentrieren, statt jedes einzelne Mal die zugrunde liegende Infrastruktur neu zu erschaffen. Natürlich bauen wir nicht alles von Grund auf neu.

Wir stützen uns auf das Fundament des gesamten Engineering-Ökosystems um uns herum, mit Open Source. Wir verlassen uns auf viel Open Source und auch auf viele Drittanbieter-Dienste, aber wir projizieren die Open-Source-Technologie nicht direkt in unsere Microservices und Systeme. Wir haben einen sehr meinungsstarken Ansatz.

Wir sind dabei sehr bewusst vorgegangen. Seien Sie sich bewusst über die Erfahrung, die Entwickler machen sollen, und projizieren Sie dann die Schnittstelle, die dieser Erfahrung entspricht.

Teilnehmer 1: Frage eins: Tötet ein so meinungsstarker Stack mit all den gebauten Bibliotheken nicht das Engagement der Entwickler, weil diese nur noch die Geschäftslogik lösen, was nicht immer der spannendste Teil für einen Entwickler ist? Und damit zusammenhängend: Wenn es um Low-Level-Probleme mit hoher Performance und hohem Durchsatz geht, die gelöst werden müssen, wie können sie diese Dinge debuggen, untersuchen und tunen, wenn sie die Bibliotheken darunter nicht verstehen?

Suhail Patel: Sprechen wir über die Motivation der meisten Entwickler. Ich denke, das ist eine Illusion, die wir uns branchenweit aufgebaut haben. Entwickler wollen komplexe ingenieurstechnische Probleme lösen, und es gibt jede Menge komplexer Probleme in den Domänen, auf die sie sich fokussieren. Wenn man zum Beispiel im Bereich Zahlungen oder Finanzkriminalität tätig ist, gibt es genug interessante Arbeit darin, ML-Modelle zu tunen und immer ausgefeiltere Regeln zu entwickeln oder sicherzustellen, dass wir Zahlungen zuverlässiger verarbeiten, um diese Entwickler zu engagieren und ihre Köpfe herauszufordern. Das muss nicht unbedingt auf der Infrastrukturebene geschehen.

Die zweite Frage betrifft hohen Durchsatz und tiefes Verständnis. Wir verbringen eine erhebliche Menge Zeit damit, die Einschränkungen unserer Systeme zu dokumentieren und zu erklären. Unsere Systeme sind nicht perfekt.

Zum Beispiel kommuniziert unser RPC-Stack über HTTP. HTTP hat natürlich seine Grenzen. Möglicherweise verlässt man sich auf eine bestimmte Implementierung von HTTP.

Sie könnten fragen, warum nicht gRPC, oder irgend ein anderes Protokoll? Wir haben uns auf einen sehr starken Satz gut getesteter und meinungsstarker Frameworks verlassen, bei denen wir nachgewiesen haben, dass wir sie deutlich auf eine große Anzahl skalieren und deployen können. Wir haben nur sehr wenige Anwendungsfälle gefunden, in denen Entwickler diese Durchsatzgrenzen durchbrechen müssten.

Im Grunde lautet die Frage, die wir Entwickler stellen: Warum glauben Sie, dass Sie den gepflasterten Weg verlassen müssen? Denn wir konnten es bei dieser Größenordnung nachweisen, was meist weit über der Größenordnung liegt, die sie erreichen wollen. So wird aus einer hypothetischen Gedankenübung eine tatsächliche Realitätsübung, denn bei uns am Boden laufen Systeme, die Millionen von Anfragen pro Sekunde verarbeiten, mit den Einschränkungen, die wir gebaut haben.

Warum können Sie Ihr System nicht innerhalb dieses Rahmens bauen?