Strategiewetten und Erkenntnisse aus Phase 3

Wette 1: Aufbau eines neuen Produkteinstiegspunktes mit Refaktorierung bestehender Architektur oder Aufbau eines völlig neuen, isolierten Produkts. In Bezug auf die analytische Verarbeitung beschlossen wir, eine neue Plattform auf der ursprünglichen Architektur aufzubauen, um die komplette Leistung der Streamverarbeitung mit Apache Flink zu nutzen.

Wir würden ein völlig neues internes Kundensegment aufbauen, sahen aber den richtigen Zeitpunkt gekommen, die Architektur zu refaktorieren, um redundante Investitionen (zwischen den Plattformen Keystone und Flink) zu minimieren. Die niedrigere Flink-Plattform unterstützt sowohl Keystone- als auch benutzerdefinierte Anwendungsfälle in dieser neuen Architektur.

• 

Architektur mit Abtrennung der Flink-Plattform als separatem Produkteinstiegspunkt (Bild: Zhenzhong Xu)

Wette 2: Erstes Streaming mit Anwendungsfällen für ETL und Beobachtbarkeit oder gleichzeitige Behandlung aller benutzerdefinierten Anwendungsfälle. Es gab viele Möglichkeiten, doch wir beschlossen, uns auf der analytischen Seite auf das Streaming von ETL-Anwendungsfällen und auf der operativen Seite auf Anwendungsfälle mit Beobachtbarkeit in Echtzeit zu konzentrieren.

Diese Anwendungsfälle stellen uns durch ihre Komplexität und ihren Umfang vor die größten Herausforderungen. Da wir die Leistung der Streamverarbeitung komplett abrufen wollten, hielten wir es für sinnvoll, zuerst die schwierigsten Fälle anzugehen und daraus zu lernen.

Wette 3: Anfängliches Teilen der operativen Verantwortung mit den Kunden und gemeinsame Innovationsschritte, um die langfristige Belastung zu verringern. Wir hatten das große Glück, dass unsere Early Adopters relativ anspruchslos waren. Außerdem boten wir den Kunden, die Schwierigkeiten hatten, umfassende Unterstützung an. Schrittweise erweiterten wir die operativen Investitionen, beispielsweise die automatische Skalierung, verwaltete Deployments, intelligente Warnungen, Hinterfüllmöglichkeiten und vieles mehr.

Erkenntnisse aus Phase 3

Erkenntnis 1: Ein neuer Produkteinstiegspunkt zur Unterstützung neuer benutzerdefinierter Anwendungsfälle ist ein wichtiger Entwicklungsschritt. Er bietet zudem die Möglichkeit einer Neugestaltung oder Refaktorierung der Architektur und der Anpassung an die bestehende Produktlandschaft. Man sollte sich nicht dazu verleiten lassen, ein komplett neues System aufzubauen. Ein zweites System muss vermieden werden.

Erkenntnis 2: Einfachheit ist in 80 Prozent der Anwendungsfälle attraktiv. Flexibilität ist für die größeren Anwendungsfälle hilfreich. Im Rückblick sind das Beobachtungen aus den tatsächlichen Kundensegmenten der vergangenen Jahre. Was ich damit sagen will, ist, dass die Priorisierung zwischen der Unterstützung der Mehrheit oder den Anwendungsfällen mit größerer Auswirkung von der jeweiligen Situation abhängt. Für beide Seiten gibt es gute Argumente, aber die Begründung sollte zum jeweiligen Geschäftsszenario passen.

Einfachheit und Flexibilität sind NICHT die beiden entgegengesetzten Enden des Spektrums, sondern eher eine in sich geschlossene Feedbackschleife für Innovationen. Flexibilität sorgt für neue, gemeinsame Innovationen mit einer kleinen Kundengruppe. Anfangs sind diese Innovationen vielleicht etwas teurer, aber wenn sie sich erstmal bewährt haben, kann dieser Mehrwert auch monetarisiert werden und die vereinfachte Erfahrung als Standard genutzt werden. Da die Innovationen auch zu höheren Kundenzahlen führen, fragt vielleicht erneut eine Gruppe neuer Nutzer nach der Flexibilität.

Erkenntnis 3: Gute Behandlung von Early Adoptern. Sie sind die treuesten Kunden und übernehmen kostenlos das Marketing. Dank der Unterstützung seitens unserer Early Adopter sind unsere Anwendungsfälle in dieser Phase in die Tausende gegangen.

Erkenntnis 4: Wenn etwas kaputt geht: keine Panik. Man sollte den Menschen in seinem Umfeld vertrauen. Ein Bonuspunkt ist eine bereits bestehende Community, die das Produkt unterstützt. Ich erinnere mich an eine Zeit, in der sich die gesamte Plattform nach und nach verschlechterte.

Jeden Tag kamen Unmengen von Seiten dazu, und wir schafften es zwei Wochen lang nicht, die Ursache zu finden. Das war erschreckend, dem Team ging es schlecht und die Kunden hatten zu leiden. Aber dem Team gelang es, über die Teamgrenzen hinweg zusammenzuarbeiten, Menschen mit den richtigen Fachkenntnissen einzubeziehen und anhand von Daten die Symptome logisch zu untersuchen.

Schließlich fanden wir einen Fehler im Linux-Kernel, der zu einem allmählichen Speicherleck beim Streaming-Workload führte. Wir mussten allen beteiligten Mitarbeitern vertrauen, auch wenn wir nicht alle über die entsprechenden Kompetenzen verfügten.