Strategiewetten und Erkenntnisse in Phase 2

Wette 1: Schwerpunkt auf Einfachheit anstelle von komplexer Infrastruktur für die Nutzer. Wir beschlossen, uns zunächst aus zwei Gründen auf einen extrem abstrahierten, komplett verwalteten Service für allgemeine Anwendungsfälle für das Streaming zu konzentrieren.

Dadurch könnten wir die meisten Anwendungsfälle in Bezug auf Datenbewegung und einfaches Streaming-ELT (also Projektion, Filtern und ähnliches) ansprechen. Wenn wir eine so einfache, hochrangige Abstraktion für die Datenweiterleitung bereitstellten, könnten die Techniker in allen Netflix-Bereichen das Datenrouting als Baustein in Verbindung mit anderen Plattformservices nutzen.

Das würde unseren Benutzern den Fokus auf die Geschäftslogik ermöglichen. Fortschrittlichere Anwendungsfälle würden wir später in Angriff nehmen.

Wette 2: Investition in einen komplett verwalteten Self-Service mit mehreren Mandanten anstelle einer fortgesetzten manuellen umfassenden Unterstützung. Wir mussten den Schwerpunkt auf die Automatisierung der Steuerungsplattform und der Workload-Bereitstellung legen. Die Kunden-Workloads müssen völlig isoliert ablaufen. Wir beschlossen, dass der Workload des einen Kunden nicht mit dem eines anderen Kunden in Berührung kommen sollte.

• 

Keystone-UI zeigt eine Drag-and-Drop-Erfahrung im Self-Service, die von einer voll verwalteten Streamingarchitektur mit mehreren Mandanten gestützt wird. (Bild: Zhenzhong Xu)

Wette 3: Fortgesetzte Investitionen in Devops anstatt verzögerter Investitionen. Wir wollten Plattformänderungen bei Bedarf mehrmals am Tag bereitstellen. Wir sind der Überzeugung, dass es unerlässlich ist, unsere Kunden in die Lage zu versetzen, jederzeit Änderungen bereitzustellen. Das Deployment sollte automatisch erfolgen und binnen weniger Minuten nach dem Start durch den Kunden sicher in Produktion gehen.

Erkenntnisse aus Phase 2

Erkenntnis 1: Die Entscheidung, woran wir NICHT arbeiten, ist schwer, aber notwendig. Auch wenn es wichtig ist, auf Kundenanfragen zu reagieren, kann dies manchmal auch ablenken. Eine Priorisierung ist der erste Schritt. Kontinuierlich zu entscheiden und zu vermitteln, was wegfällt, ist aber noch wichtiger. Nein sagen ist hart. Doch es gilt: Nein sagen ist nur vorübergehend, Ja sagen ist für immer.

Erkenntnis 2: Die Skalierungsgeschwindigkeit muss beachtet werden. Nach der ersten Bewertung der Eignung des Produkts für einen Markt beginnt eine aufregende Zeit. Eine zu schnelle Skalierung birgt jedoch das Risiko, dass das Team aus verschiedenen Richtungen Ablenkung erfährt.

Im Ergebnis bleiben viele technische Schulden, und das Kundenvertrauen ist gestört. Bei einer zu langsamen Skalierung bleibt das Team unmotiviert zurück, die Kundenanforderungen werden zu lange nicht erfüllt, was ebenfalls das Kundenvertrauen stört. Es geht um eine fragile Balance. Hier sind einige Signale, nach denen Ausschau zu halten ist:

• Softwarequalität: Ändert sich die Rollback-Häufigkeit beim Deployment? Wie häufig wird das Team durch Partnerteams blockiert? Schlagen Tests jetzt häufiger fehl? Wie oft treten Vorfälle aufgrund eines Engpasses im System auf?
• Kundenstimmung: Erfolgt der Anstieg bei den Kundensupportanfragen nicht linear zur Anzahl der Anwendungsfälle? Gibt es Trends bei SLO-Verletzungen? Freuen sich die Kunden über die Ankündigung neuer Features? Welche Alternativen haben Kunden bei einer dringenden Anfrage schon in Betracht gezogen?
• Operativer Overhead: Ändert sich das zeitliche Verhältnis von Entwicklung bis Betrieb beim Team? Ändert sich das Verhältnis zwischen Ursachenanalyse und Vorfällen? Hat das Team einen Burnout von der operativen Belastung? Ändert sich die Innovationsfrequenz des Teams (beispielsweise Blogposts, Konferenzvorträge)?

Erkenntnis 3: Informieren der Benutzer und geduldiges Korrigieren falscher Vorstellungen. Es gab viele falsche Vorstellungen bei der Streamverarbeitung in Bezug auf die Datenqualität, zum Beispiel zu Ereignisausfällen oder Duplikaten, oder in Bezug auf die Verarbeitungssemantik, zum Beispiel zu Garantien für die Richtigkeit in Ausfallszenarien. Viele dieser falschen Vorstellungen stammten noch aus Zeiten, als die Streamverarbeitung unreif war. Die Entwicklung hier war jedoch immens. Hier heißt es, geduldig mit den Benutzern zu bleiben und sie mit Daten und Geschichten zu informieren.