Heise meets hatte auf dem WWC25 in Berlin die einmalige Gelegenheit zum Interview mit Werner Vogels. Er beginnt mit einem Blick zurück.
Dr. Werner Vogels ist Vice President und Chief Technology Officer bei Amazon.com. Er kam 2004 von der Cornell University, wo er an verteilten Systemen geforscht hat. Vogels hat an der Vrije Universiteit in Amsterdam promoviert und zahlreiche Artikel über verteilte Systemtechnologien für die Unternehmensdatenverarbeitung verfasst.
Vogels: Lassen Sie mich die Geschichte erzählen, wie ich zu Amazon gekommen bin. Bevor ich dahin kam, war ich Akademiker und habe verschiedene Unternehmen in den USA beraten. Ich wurde also von Amazon eingeladen, dort einen Vortrag zu halten. Und ich dachte: Amazon? Das ist eine Buchhandlung. Wie schwer kann das schon sein, ein Webserver und eine Datenbank?
Ich bin hingegangen, habe einen Blick in die Technologieküche geworfen, und ich war völlig überwältigt. Diese Leute hatten Systeme in einer Größenordnung aufgebaut, an die ich nie zuvor gedacht hatte. Denken Sie daran, dass wir als Akademiker den Anspruch haben, hochgradig skalierbare Systeme und solche Dinge zu bauen. Diese Leute haben das wirklich getan. Aber mir wurde auch klar, dass alles in der Architektur von Amazon hausgemacht war. Und ich fragte mich, warum wir nicht einfach kommerzielle Technologie verwenden? Aber, es gab keine kommerzielle Technologie, die in der Größenordnung von Amazon funktionieren konnte. Definitiv nicht in jenen Tagen.
Eine große Herausforderung waren Datenbanken. Ende der 90er und Anfang der 2000er Jahre war die relationale Datenbank immer noch das Standardwerkzeug zum Speichern von Daten. Und alles wurde in diese gezwungen. Im Grunde wurden die Zuverlässigkeit und der Umfang von Amazon durch den Umfang ihrer Datenbanken bestimmt. Und Datenbanken waren dieser Aufgabe nicht gewachsen, um ehrlich zu sein. Die Ingenieure mussten also eine Menge tun, um sicherzustellen, dass alles richtig funktionierte. Außerdem: 1994 gab es das Wort E-Commerce noch gar nicht.
„Es gab kein Buch, in dem stand, so implementiert man einen Online-Buchladen“
Amazon war eine Buchhandlung ;-)
Vogels: Es war eine Buchhandlung. Aber es gab kein Buch, in dem stand, so implementiert man einen Online-Buchladen, denn das hatte es noch nie gegeben. Es gibt so viele Dinge, die im Laufe der Zeit bei Amazon entstanden sind, wie Empfehlungen und Vergleiche, Kundenrezensionen – all diese Dinge wurden von Amazon entwickelt. Auch auf technologischer Ebene.
Man darf nicht vergessen, dass auch die darunter liegende Technologie bahnbrechend sein musste. Amazon war also ein großer architektonischer Treiber der Technologie. Aber die Architektur, die wir in den 90er Jahren hatten, war im Grunde eine zustandslose Webschicht im Vordergrund mit einer ganzen Reihe von Datenbanken im Backend. Die Zuverlässigkeit der gesamten Website wurde von der Zuverlässigkeit dieser Datenbanken bestimmt.
Die Jungs, die für diese Datenbanken verantwortlich waren, die DBAs, wurden extrem konservativ, weil sie zur Verantwortung gezogen wurden, wenn etwas schief ging, und nicht die Frontend-Entwickler. Jeder, der eine schnelle Innovation durchführen wollte und Schemaänderungen benötigte, wurde also blockiert.
1998 haben einige Amazon-Ingenieure ein Manifest über verteiltes Rechnen geschrieben. In dem Manifest wurden zwei Arten von Architekturen vorgeschlagen.
Werner Vogels: Sie schlugen zwei Architekturen vor – eine serviceorientierte und eine Workflow-Architektur. Das Problem bestand darin, dass diese Datenbanken eine gemeinsam genutzte Ressource waren und somit zu einem Engpass wurden. Ihr Ziel war es also, das Pendel in die andere Richtung auszuschlagen: Man nehme die Daten, nehme den Code, der sie verarbeitet, und füge ihn zusammen. Außerhalb dieser speziellen Funktionalität ist kein direkter Datenbankzugriff mehr erlaubt. Es wurde eine API darauf gelegt. Damit war die Datenbank nicht mehr eine gemeinsam genutzte Ressource.
Wir haben allerdings Fehler gemacht. Es gab kein Buch über Serviceorientierung. Das Wort gab es nicht. Wir hatten eine datengesteuerte Dekomposition mit drei großen Datensätzen: Kunden, Artikel als Katalog und Bestellungen. Im Grunde wurde der gesamte Code, der mit dem Kundendatensatz arbeitete, in einem Dienst zusammengefasst. Schon bald war dieser Dienst genauso groß und hatte die gleichen Probleme wie der Monolith.
Wir stellten fest, dass es in diesem Dienst Komponenten gab, die hohe Anforderungen an die Skalierung stellten, während dies bei anderen nicht der Fall war. Zum Beispiel gab es einen Anmeldedienst, der auf fast jeder Seite aufgerufen wird, aber im selben Code befand sich auch ein Einkaufswagen. Der Einkaufswagen musste also genauso skaliert werden wie der Anmeldedienst. Das ist nicht nur höchst ineffizient, sondern auch ein absoluter Verstoß gegen die Sicherheitsprinzipien, denn plötzlich hatte der Einkaufswagen Zugriff auf den Anmeldespeicher. Das war nicht nötig. Also begannen wir mit der funktionalen Zerlegung, nahmen diese funktionalen Teile heraus, und das ist es, was wir heute Microservices nennen.
„Es gab kein Buch über Serviceorientierung“
Nach den Microservices kam die Produktivität der Entwickler auf den Prüfstand. Was genau ist passiert?
Vogels: Wir sahen, dass die Produktivität der Entwickler abnahm, weil jeder immer komplexere Rechenumgebungen zu verwalten hatte. Wir begannen mit dem Aufbau einer Shared-Services-Umgebung, die Datenbank, Computing und Storage umfasste. Diese Ingenieure mussten sich also nicht mehr um die Verwaltung kümmern. Das war schließlich der Ausgangspunkt für AWS, wie wir es heute kennen. Das hat vorher niemand gemacht. Bereits in den ersten Tagen von AWS dachte ich, dass dies ein Geschäft ist, in dem man gut aufgehoben wäre. Jeder würde das wollen.
Eine der Triebfedern für den Aufbau von AWS war eine ähnliche Sache, die wir in der Außenwelt gesehen haben. In den frühen 2000er Jahren war es populär, eine API auf einige Produkte zu legen, um zu sehen, welche Art von Innovation passiert. Bei Amazon haben wir eine API für den Katalog, den Einkaufswagen und die Suche eingerichtet. So konnte jeder Anwendungen in der Domäne von Amazon erstellen. Es wurden wirklich tolle Sachen entwickelt. Vergleichseinkäufe, neue Schnittstellen, einige dieser Unternehmen wurden populär. In dem Moment, in dem sie populär wurden, gerieten sie alle in der Ausführung ins Stottern. Denn jetzt mussten sie 5 Millionen Dollar an Investitionen aufbringen. Und warum? Weil sie Hardware kaufen und Mitarbeiter für IT-Aufgaben einstellen mussten, die nichts mit der Funktionalität zu tun hatten, die sie entwickeln wollten. All diese Unternehmen sind gescheitert, weil sie diese Art von Geld nicht aufbringen konnten.
Dieses Interview entstand im Rahmen des WeAreDevelopers World Congress, auf dem Dr. Werner Vogels eine Keynote zum Thema „Building Systems that Last“ hielt. Darin ging es unter anderem um zellbasierte Architekturen und was die Website „The Frugal Architect“ damit zu tun hat.
Compute, Storage, Datenbanken und Sicherheit waren die ersten Dienste, die zur Verfügung gestellt wurden. Daraus ist ein neues Universum entstanden, das sich ständig weiterentwickelt. Ist das der Grund für „Evolve or die“?
Vogels: Oh, glauben Sie mir, ich würde das nicht seit 20 Jahren machen, wenn ich nicht die Zeit meines Lebens hätte. Jedes Jahr ist anders. Jedes Jahr ist neu. Und ich habe auch ein wenig Freiheit, wenn es darum geht, wo ich meinen Schwerpunkt setzen kann.
Ich habe in den letzten Jahren viel Zeit mit Unternehmen verbracht, die einige der schwierigsten Probleme der Welt lösen. Sie sind nicht darauf aus, ein Einhorn zu werden oder einen neuen Spamfilter zu entwickeln. Es geht ihnen um die Lösung von Hunger-, Bildungs- oder Gesundheitsproblemen. Ich habe gerade Anfang dieser Woche in Genf an der UN-Konferenz „AI for Good“ teilgenommen. Wie können wir diesen Organisationen helfen? Ich konzentriere mich dort hauptsächlich auf das Mapping. Was können wir als großes Unternehmen tun, um diesen jüngeren Unternehmen zu helfen, egal ob es sich um eine NGO oder etwas anderes handelt? Wir können ihnen mit Ressourcen helfen. Es gibt einen Unterschied zwischen Unternehmen, die aus kommerziellen Gründen Gutes tun, weil sie damit ein gutes Geschäft machen, und den NGOs.
Vor einigen Jahren fiel mir auf, dass es vor allem in Südostasien, Afrika und Südamerika – dem globalen Süden – viele junge Unternehmen gab, die sich mit schwierigen menschlichen Problemen befassten, aber aus kommerziellen Gründen. Sie mussten tatsächlich herausfinden, wie sie Geld verdienen können. Man kann also Gutes tun und gleichzeitig ein gutes Geschäft machen.
Das brachte mich dazu, diese Fernsehserie „Now Go Build“ zu entwickeln. Sie finden sie auf Amazon Prime, auf YouTube und auch auf meinem Blog. Es gibt drei Staffeln mit jeweils vier oder fünf Episoden, die sich mit verschiedenen Unternehmen beschäftigen, die versuchen, schwierige Probleme zu lösen.
„Wir müssen unsere Ängste, etwas zu verpassen, abbauen“
Kommen wir zu Ihren Prognosen. Für 2025 haben Sie unter anderem Technologie als Schlüssel zur Wahrheitsfindung vorausgesehen. Was kommt als Nächstes?
Vogels: Nun, ich denke, jeder wird mich wahrscheinlich fragen, ob ich über Dinge wie Agenten sprechen will. Das werde ich anderen überlassen. Ich glaube, ich habe die Auswirkungen von Agenten auf die Softwareentwicklung schon seit einiger Zeit vorhergesagt. Eine meiner Vorhersagen vom letzten Jahr hat sich bewahrheitet: kulturbewusste LLMs.
Ich habe gesehen, wie viele neue große Sprachmodelle überall entwickelt wurden. Ein Beispiel dafür ist dieses junge Unternehmen in Kenia, Jacaranda Health. Sie nahmen eines der Modelle, fügten Suaheli und allgemein gesprochenes Suaheli hinzu und verfeinerten das LLM mit Daten über die Gesundheit von Müttern. Und jetzt können Frauen überall in Kenia einfach per SMS mitteilen, was sie erleben oder welche Fragen sie haben, eine SMS in Suaheli an den Dienst schicken und eine Antwort zurückbekommen.
Ich finde, das ist genau das, was gebraucht wird, denn die Art und Weise, wie man mit einer schwangeren Frau in Kenia spricht, unterscheidet sich grundlegend von der Art und Weise, wie man mit einer schwangeren Niederländerin spricht. Für eine niederländische Frau, vielleicht auch in Deutschland, sind es Fakten. Aber Sie müssen bedenken, dass das Durchschnittsalter einer schwangeren Frau hier in Westeuropa wahrscheinlich irgendwo Mitte 20 liegt, vielleicht auch ein bisschen später. In Kenia sind es 14, 15, 16 Jahre. Eine andere Kultur. Und ob wir das für angemessen halten oder nicht, ist eine ganz andere Geschichte. Es ist einfach ihre Kultur. Und dementsprechend spricht man mit ihnen auch anders.
Wenn es eine Vorhersage gibt, dann ist es die, dass wir unsere Ängste, etwas zu verpassen, viel besser abbauen müssen. Wir brauchen realistische Erwartungen, was Technologie kann und was sie nicht kann. Die meisten Aufsichtsbehörden sind keine Technologen, sondern Juristen und Politiker, die man aufklären muss.
Dieses Interview ist eine komprimierte Fassung des Audio-Podcasts „heise meets – Der Entscheidertalk“. Die originale Audioversion finden Sie auf www.heise-meets.de. Das Gespräch führte der Radiojournalist Matthias Tüxen im Auftrag von Heise Business Services für heise online und IT Spektrum. Ein vollständiges Transkript der originalen Podcast-Episode mit Dr. Werner Vogels gibt es unter den Shownotes von heise meets bei Podigee zu lesen.
