Strategiewetten in Phase 1

Wette 1: Das MVP-Produkt wird anfangs nur für wenige Kunden entwickelt. Beim Untersuchen der anfänglichen Eignung des Produkts für einen Markt wird man leicht abgelenkt. Wir beschlossen, einigen wenigen internen Kunden mit hoher Priorität und großem Umfang zu helfen und uns später um die Skalierung der Kundenbasis zu kümmern.

Stellenmarkt
  1. Betreuungsingenieur (w/m/d) OT-Sicherheit
    Wacker Chemie AG, Burghausen
  2. Mitarbeiter (m/w/d) IT-Support
    Otto Krahn Group GmbH, Hamburg
Detailsuche

Durch diese Entscheidung waren wir zum einen in der Lage, uns auf den Kern des Produkts zu konzentrieren. Zum anderen waren wir uns bewusst, worin wir nicht investieren mussten. Beispielsweise nutzten wir eine einfache Tabelle anstelle einer vollwertigen Plattform für die Pflege von Kundennamen, E-Mail-Adressen und Metadaten pro Pipeline, um die Bereitstellung beim Kunden in der MVP-Phase zu vereinfachen.

Wette 2: Gemeinsame Entwicklung mit Technologiepartnern, auch wenn noch kein idealer Reifegrad erreicht ist, anstatt das Rad nochmal neu zu erfinden. Auf diese Weise konnten wir die Umgebungen gemeinsam entwickeln. Wir haben uns früh für Partnerschaften entschieden.

  • Streamingpartner: Extern haben wir mit Partnern zusammengearbeitet, die branchenweit bei der Streamverarbeitung führend sind. Dazu gehören Linkedin (Kafka- und Samza-Team), Confluent, Data Artisan (Entwickler hinter Apache Flink, später umbenannt in Veverica). So konnten entsprechend unserer Bedürfnisse zum Betriebsunterstützungssystem (OSS) beitragen und gleichzeitig die gemeinschaftliche Arbeit nutzen.
  • Partner bei der Containerisierung: 2015 befand sich die Virtualisierungstechnologie mit Containern noch in einer frühen Phase. Wir brauchten schnell eine Strategie für die Bereitstellung. Intern gingen wir eine Partnerschaft mit der neu geschaffenen Containerinfrastruktur, dem Titus-Team, ein. Titus baute auf Apache Mesos auf und stellte Funktionen für die Verwaltung, Planung und isolierte Bereitstellung von Rechenressourcen über eine abstrahierte API bereit. Titus wurde später so weiterentwickelt, dass es Anfang der 2020er Jahre K8S nutzte. Das zugehörige Team schaffte es, alle Workloads transparent zu migrieren. Dank dieser Partnerschaft mussten wir uns keine Gedanken über die zugrundeliegende Recheninfrastruktur machen, während wir die Datenplattform aufbauten.

Golem Karrierewelt
  1. IT-Grundschutz-Praktiker mit Zertifikat: Drei-Tage-Workshop
    21.-23.11.2022, Virtuell
  2. Einführung in Unity: virtueller Ein-Tages-Workshop
    13.10.2022, Virtuell
Weitere IT-Trainings

Im Verlauf dieser Zusammenarbeit blieben wir in ständigem Kontakt, um Erfahrungen auszutauschen und Feedback zu geben. Alle zwei Wochen fanden Meetings mit engen Partnern statt, um Zielsetzungen abzustimmen und Probleme und Lösungen zu besprechen. Wenn Hindernisse auftraten, kümmerten sich sofort die richtigen Menschen darum.

Wette 3: Bedenken trennen, anstatt sie zu ignorieren. Wir haben die Bedenken in Bezug auf operative und analytische Anwendungsfälle voneinander getrennt. Wir haben Mantis (mit Fokus auf operativem Geschäft) und Keystone (mit Fokus auf Analysen) separat entwickelt, dabei allerdings Raum für eine Schnittstelle zwischen beiden Systemen geschaffen.

  • Verschieben der Daten vom Rand zum Data Warehouse (Bild: Zhenzhong Xu)
  • Fehleranfällige Architektur mit Batch-Pipeline vor der Migration (Bild: Zhenzhong Xu)
  • Keystone-Streamingarchitektur nach der Migration (Bild: Zhenzhong Xu)
  • So unterstützt die Streamverarbeitung den Umgang mit operativen und analytischen Daten. (Bild: Zhenzhong Xu)
  • Trennung der Bedenken für unterschiedliche Szenarien bei der Streamverarbeitung (Bild: Zhenzhong Xu)
  • Diagramm zur sich entwickelnden Keystone-Architektur, circa 2016. Keystone enthält Kafka- und Flink-Engines als Kernkomponenten. Weitere Details zum technischen Design finden sich in Blogposts mit dem Schwerpunkt Kafka und Flink. (Bild: Zhenzhong Xu)
  • 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)
  • A/B-Test zur Auswahl der besten künstlerischen Darstellung für die Personalisierung (Bild: Netflix)
  • Architektur mit Abtrennung der Flink-Plattform als separatem Produkteinstiegspunkt (Bild: Zhenzhong Xu)
  • Abstimmung der Streamverarbeitung in Netflix - 2021 (Bild: Zhenzhong Xu)
  • Optimalpunkt zwischen Einfachheit und Flexibilität (Bild: Zhenzhong Xu)
Trennung der Bedenken für unterschiedliche Szenarien bei der Streamverarbeitung (Bild: Zhenzhong Xu)

Die Bedenken zwischen Herstellern und Verbrauchern haben wir voneinander getrennt. Wir haben Hersteller- und Verbraucher-Clients eingeführt, die mit standardisierten Netzwerkprotokollen und einer einfachen Schemaverwaltung ausgestattet wurden, um den Entwicklungsworkflow zwischen Herstellern und Verbrauchern leichter zu entkoppeln. Das stellte sich später als grundlegender Aspekt bei der Data Governance und der Datenqualitätskontrolle heraus.

Auch die Zuständigkeiten für Komponenten haben wir voneinander getrennt. Anfangs nutzten wir ein an Mikroservices ausgerichtetes Prinzip mit Einzelverantwortung, bei dem die gesamte Infrastruktur aufgeteilt wurde in die Bereiche Messaging (Streamingtransport), Verarbeitung (Streamverarbeitung) und Steuerungsplattform (in dieser Phase war die Plattform nur ein Skript, das später zu einem kompletten System ausgebaut wurde).

Die Trennung der Zuständigkeit für die Komponenten ermöglichte es dem Team, frühzeitig Schnittstellen aufeinander abzustimmen und gleichzeitig die Produktivität des Teams durch den parallelen Schwerpunkt auf verschiedene Bestandteile zu steigern.

Wette 4: Investition in den Aufbau eines Systems, bei dem Ausfälle erwartet und alle Abläufe überwacht werden, anstelle von verzögerten Investitionen. Aufgrund der elastischen, sich konstant ändernden Merkmale der Cloud mit höherer Ausfallwahrscheinlichkeit müssen wir das System so aufbauen, dass alle Arten von Ausfällen überwacht, erkannt und verkraftet werden können.

Die Ausfälle können beispielsweise von Netzwerkaussetzern über den Ausfall von Instanzen, Zonen und Clustern bis hin zu Überlastung und Gegendruck zwischen Services sowie Ausfällen bei örtlichen Katastrophen reichen.

Wir haben in den Ausbau der Systeme in der Annahme investiert, dass konstant Ausfälle auftreten. Wir haben uns ganz früh Devops-Praktiken verschrieben: Szenarien, die für Ausfälle entwickelt wurden, rigorose Automatisierung, kontinuierliches Deployment, Schattentests, automatisierte Überwachung und Warnungen und vieles mehr. Dank dieser Devops-Grundlage gelang uns eine herausragende technische Agilität mit mehreren Bereitstellungen pro Tag.

Veränderungen sind nur möglich, wenn Fehler gemacht werden dürfen

Wir haben viele Fehler gemacht. Am Tag des Produktstarts ist eigentlich alles schief gegangen und wir hatten einen unternehmensweiten Vorfall mit massiven Datenverlusten. Nach der Untersuchung des Vorfalls stellte sich heraus, dass trotz einer korrekten Schätzung des Wachstums beim Datenverkehr der monströse Kafka-Cluster (mit mehr als 200 Brokern), den wir aufgebaut hatten, zu groß war und schließlich an seine Skalierungsgrenze kam.

Als ein Broker ausfiel, konnte der Cluster die Wiederherstellung aufgrund der (damaligen) Beschränkungen in Kafka in Bezug auf die Anzahl an Brokern und Partitionen nicht selbst durchführen. Das gesamte System verschlechterte sich so lange, bis keine Wiederherstellung mehr möglich war.

Ein Ausfall in diesem Maßstab war eine schreckliche Erfahrung. Aber dank unserer psychologisch sicheren Teamumgebung haben wir mit allen Beteiligten transparent kommuniziert und die Erfahrungen schnell in dauerhafte Lösungen umgesetzt. Für diesen besonderen Fall entwickelten wir Möglichkeiten mit einer feingranulareren Cluster-Isolierung (kleinere Kafka-Cluster und isolierter Zookeeper), um den Auswirkungsradius einzudämmen.

Aber es gab noch viele weitere Ausfälle. Als wir durch die Ursachen pflügten, mussten wir feststellen, dass wir auf keinen Fall alle noch so abseitigen Szenarien durchspielen konnten, besonders bei unserem Aufbau auf einer verwalteten Cloud, bei der Änderungen häufig außerhalb unserer Kontrolle passieren, wie die Beendigung von Instanzen oder die Mandanten-Colocation.

Gleichzeitig wird unser Produkt von sehr vielen Menschen genutzt und ist eigentlich zu wichtig, um auszufallen. Es wurde zu unserem Arbeitsprinzip, unsere Abläufe immer auf das Worst-Case-Szenario vorzubereiten.

Nach dem Vorfall führten wir eine wöchentliche Ausfallübung für den Kafka-Cluster ein. Jede Woche musste die zuständige Person einen Ausfall des Kafka-Clusters simulieren. Das Team musste sicherstellen, dass die automatisierte Ausfallsicherung funktionierte und den gesamten Datenverkehr mit minimalen Auswirkungen auf die Nutzer auf einen stabilen Cluster migrieren. Mehr über dieses Vorgehen bietet dieses ausführliche Video zu diesem Thema.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed
 Herausforderungen in Phase 1Phase 2: Skalierung für Hunderte von Anwendungsfällen 
  1.  
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8. 7
  9. 8
  10. 9
  11. 10
  12. 11
  13.  


Aktuell auf der Startseite von Golem.de
Garmin Edge Explore 2 im Test
Fahrradnavigation als verkehrsberuhigtes Abenteuer

Tour mit wenig Autos gesucht? Das Fahrrad-Navigationsgerät Garmin Edge Explore 2 kann uns das verschaffen - mit teils unerwarteten Folgen.
Ein Test von Peter Steinlechner

Garmin Edge Explore 2 im Test: Fahrradnavigation als verkehrsberuhigtes Abenteuer
Artikel
  1. Eichrechtsverstoß: Tesla betreibt gut 1.800 Supercharger in Deutschland illegal
    Eichrechtsverstoß
    Tesla betreibt gut 1.800 Supercharger in Deutschland illegal

    Teslas Supercharger in Deutschland sind wie viele andere Ladesäulen nicht gesetzeskonform. Der Staat lässt die Anbieter gewähren.

  2. Strompreise: Hetzner muss die Preise für fast alle Produkte anheben
    Strompreise
    Hetzner muss die Preise für fast alle Produkte anheben

    Der Cloudbetreiber Hetzner hat wie viele Unternehmen mit steigenden Strompreisen zu kämpfen. Das bekommen Kunden nun auch zu spüren.

  3. Simulationsspiele: Mit Bahn, Bahn und Schwerlasttransporter durch Deutschland
    Simulationsspiele
    Mit Bahn, Bahn und Schwerlasttransporter durch Deutschland

    Aerosoft hat auf seiner Hausmesse Nextsim neue Simulationsspiele vorgestellt. Es geht ums Transportwesen in vertrauten Umgebungen.
    Von Thomas Stuchlik

Du willst dich mit Golem.de beruflich verändern oder weiterbilden?
Zum Stellenmarkt
Zur Akademie
Zum Coaching
  • Schnäppchen, Rabatte und Top-Angebote
    Die besten Deals des Tages
    Daily Deals • BenQ Mobiuz EX3410R 499€ • HyperX Cloud Flight heute für 44€ • MindStar (u. a. AMD Ryzen 5 5600X 169€, Intel Core i5-12400F 179€ und GIGABYTE RTX 3070 Ti Master 8G 699€ + 20€ Cashback) • Weekend Sale bei Alternate (u. a. AKRacing Master PRO für 353,99€) [Werbung]
    •  /