Nach 11-wöchiger Kubernetes-Migration vergisst ein Unternehmen seinen Daseinszweck (2020)

 (theolognion.com)
1 Punkte von GN⁺ 2024-03-02 | 1 Kommentare | Auf WhatsApp teilen
  • Das Silicon-Valley-Startup Xenobroom Inc. beschloss im Mai 2020, während der Pandemie nach einem starken Anstieg der täglichen Nutzung seine bestehende Serverinfrastruktur auf Kubernetes zu migrieren
  • Die Migration wuchs über eine einfache Deployment-Verbesserung hinaus zu einer langfristigen Aufgabe, bei der die auf bash-Skripten und VPS basierende Konfiguration neu geprüft und neu entworfen wurde
  • Mit Dependency- und Library-Upgrades, der Umstellung von Teilen von PostgreSQL auf einen verteilten KV-Store sowie der Nutzung der Flexibilität von AWS weitete sich der Umfang weiter aus
  • Der bisherige Staging-Server mit täglichen Deployments auf Basis des develop-Branches wurde durch einen production-only CI-Workflow, dynamisches Routing, A/B-Tests und Unterstützung regionaler Abhängigkeiten ersetzt
  • Als die Migration scheinbar abgeschlossen war, konnte sich niemand im Unternehmen mehr an den Zweck des Produkts erinnern; auch Nutzer und Investoren räumten ein, das ursprüngliche Produkt nie verstanden zu haben, sodass eine Wiederherstellung praktisch unmöglich wurde

Durch die Kubernetes-Migration gewachsener Arbeitsumfang

  • Xenobroom Inc. begann im Mai 2020 mit dem Upgrade seiner Serverinfrastruktur
    • Laut Fragmenten aus dem Tagebuch des CEO und Engineering-Notizen des CTO stieg die tägliche Nutzung während der Pandemie sprunghaft an
    • Danach fiel die Entscheidung, die bestehende Infrastruktur auf Kubernetes zu migrieren
  • Die Arbeiten dauerten länger als erwartet
    • Einfache bash-Skripte und VPS-Maschinen mussten neu erstellt, überprüft und re-engineered werden
    • Intern sah man darin auch die Gelegenheit, Software-Dependencies und Libraries zu aktualisieren
  • Die Infrastrukturänderung führte zu einer größeren strukturellen Umgestaltung
    • Man kam zu dem Schluss, dass große Teile der auf einer einzelnen Maschine laufenden PostgreSQL-Datenbank durch einen verteilten KV-Store ersetzt werden könnten
    • Auch die Flexibilität von AWS wurde als Begründung angeführt
    • Der einfache Staging-Server, von dem täglich aus dem develop-Branch deployed wurde, verschwand
    • Stattdessen wurde ein production-only CI-Workflow mit dynamischem Routing eingeführt, mit einer Konfiguration, die A/B-Tests und regionale Abhängigkeiten nahtlos unterstützt

Verlust des Produktzwecks und Hilfe von außen

  • Als der Migrationsprozess scheinbar abgeschlossen war, konnte sich im Unternehmen niemand mehr an den Zweck des Produkts erinnern
  • Nutzer und Investoren konnten die Situation ebenfalls nicht lösen
    • Beide Gruppen räumten öffentlich ein, das Produkt von Anfang an nie richtig verstanden zu haben
    • Nach mehreren Wochen Downtime wurde es praktisch unmöglich, die Bedeutung des Produkts wiederherzustellen
  • Der CEO suchte Hilfe bei Phutar Afrayughum, einem Medium und Experten für außersinnliche Wahrnehmung
    • Er wird als jemand vorgestellt, der Google dabei half, den Marktanteil seiner Messaging-Apps zu steigern, und der auch an der Entwicklung des Material-Design-Frameworks beteiligt war
    • Diese Hilfe wird jedoch mit „allegedly“ versehen und damit nicht als Tatsache behauptet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-02
Hacker-News-Kommentare

  • Dieser Artikel ist noch lustiger: Es geht darum, dass die Entlassung von 20 % des mittleren Managements die Entwicklerproduktivität zufällig verdreifacht habe
    https://www.theolognion.com/p/company-accidentally-increased...

    • Das ist kaum noch als Satire zu bezeichnen

  • Bei unserem $dayjob läuft gerade auch so eine Migration. Sie wurde vor zwei Jahren gestartet, ist aber noch nicht einmal zu 30 % abgeschlossen
    Die Leute, die früher am lautesten riefen: „Wir müssen zu Kubernetes, wir müssen den Monolithen töten“, spielen jetzt mit LLMs herum und haben Kubernetes vergessen
    Manche Leute lieben Proofs of Concept und glänzende neue Dinge wirklich, und diese Rolle scheint auf ihre Weise auch nützlich zu sein

    • Es ist eine Struktur, in der man durch neue, glänzende Technologien Arbeitszufriedenheit gewinnt
      Deshalb wirken kluge Leute offenbar auch bei unethischen Big-Tech-Konzernen, Werbefirmen und Überwachungsunternehmen ziemlich zufrieden
      Warum das Unternehmen existiert und was es außerhalb des eigenen Computers tatsächlich tut, ist nicht besonders wichtig; wichtig sind die Technologie und die Freiheit, Neuem nachzugehen
      Unternehmen mögen die Produktivität und Leidenschaft, die diese Leute hervorbringen, und bezahlen sie auch gut
      In der Regel haben auch solche Entwickler ein Gewissen, aber dieses Gewissen wird oft in Form unternehmensfreundlicher, wohlmeinender sozialer Bewegungen vereinnahmt und zur Schau gestellt
    • Das ist weniger Scope Creep als vielmehr bewusstes lebenslaufgetriebenes Entwickeln
      Jemand arbeitet Checkliste für Checkliste ab, um sagen zu können: „Ich habe X gemacht“
      In kleinen Teams kann diese Vorgehensweise die Produktivität wirklich sehr schnell zum Stillstand bringen, und sie wird oft als Wunsch verpackt, alle Probleme lösen zu wollen
      Am Ende wird jedoch kein Problem gelöst; stattdessen entstehen noch mehr neue Probleme
    • In FAANG-nahen Unternehmen ist eine Beförderung sehr schwierig, und wegen der Level-Systeme ist eine Beförderung oft auch der einzige Weg zu mehr Gehalt
      Für eine Beförderung braucht man ein Promotion Package, und für ein Promotion Package braucht man ein großes, schwergewichtiges Projekt
      Am Ende ist das zentrale Problem, das gelöst werden soll, nicht mehr ein geschäftlicher Bedarf, sondern die Beförderung, und so entstehen riesige Projekte auf der Suche nach einem Problem
    • Vielleicht ist es nützlich, um Firmengeld zu verbrennen
      Das Beschriebene klingt nicht einmal nach einem Proof of Concept. Die Grundvoraussetzung für einen Proof of Concept ist schließlich, dass er erst einmal funktioniert; das hier ist eher das Erzeugen eines Setups, um der Herde zu folgen und beschäftigt auszusehen
      Auch aus Mitarbeitersicht scheint das kein Umfeld zu sein, in dem man lange bleiben möchte
    • Ich habe das Gefühl, dass genau solche Leute am häufigsten befördert werden. Eine wirklich verdrehte Struktur

  • In diesem Blog gibt es noch mehr lustige Beiträge. Besonders dieser hat mir gefallen:
    https://www.theolognion.com/p/dev-builds-perfect-note-taking...
    Und diesen gibt es auch:
    https://www.theolognion.com/p/ai-solves-all-political-econom...

  • Ich weiß, dass es ein Witz ist, aber wenn man eine Postmortem-Analyse machen würde, wäre die Ausfallursache vermutlich: „Viele Leute im Unternehmen dachten, man solle diese Gelegenheit nutzen, um auch gleich Softwareabhängigkeiten und Bibliotheken zu aktualisieren. Außerdem meinte man, große Teile der PostgreSQL-Datenbank, die auf einer einzelnen Maschine lief, könnten dank der enormen Flexibilität von AWS in einen verteilten Key-Value-Store umgewandelt werden“
    Man muss den Scope schützen

    • Das ist ziemlich genau der Kern dieses Witzes
      Es gibt viele Leute auf der Welt, die sich stärker auf die Technologien konzentrieren, die sie verwenden, als auf das Produkt, das sie bauen
      Sich auf das Produkt zu konzentrieren bedeutet, den Scope zu kennen und nicht zu früh zu überentwickeln
      Der Witz konzentriert sich auf Kubernetes, aber man könnte ihn genauso mit serverseitigem Rendering, AI, $modernFrontendLib oder $modernLanguage machen
    • Auch der Scope des Unternehmens muss geschützt werden
      Wenn das Geschäft nicht der Verkauf von Cloud-Infrastruktur ist, sollte man einen fertigen Cloud-Anbieter nutzen
      Wenn man bereits für einen Cloud-Anbieter bezahlt, ist es insbesondere besser, Kubernetes nicht zu verwenden

  • In der Realität wäre eine 11-wöchige Kubernetes-Migration als großer Erfolg gewertet worden

    • Tatsächlich hätte es 11 Monate gedauert, und jetzt wäre man in so einem Zustand wie „cloud-native“
      Natürlich wäre der Datenbankbetrieb etwas schwierig gewesen. Man hätte nämlich vergessen, den Kubernetes-Storage richtig einzurichten, sodass nach einem plötzlichen Verschieben eines Pods die Daten verschwunden wären
    • Wenn man bereits Docker verwendet, gibt es kaum einen Grund, warum es so lange dauern sollte
      Wenn man nicht einmal Docker verwendet hat, liegt das Problem bei einer ähnlichen Migration wahrscheinlich nicht an Kubernetes selbst

  • Es war noch nie so einfach und günstig wie heute, Systeme zu betreiben
    Trotzdem bevorzugen Ingenieure es, zur Lieferung einer einzigen Pizza eine Expedition zusammenzustellen, den Everest zu besteigen, oben ein Foto der Pizza zu machen, sie dann wieder per Flugzeug nach Hause zu bringen, einen Lamborghini zu mieten, bei der Mongol Rally mitzufahren und die Pizza erst 18 Monate später auszuliefern
    Währenddessen gewinnt man einfach, wenn man mit einem billigen Roller die Straße hinunterfährt

    • Ich habe noch nie an einem Ort gearbeitet, an dem die von Ingenieuren eingebrachte Komplexität mit der vom Management eingebrachten Komplexität mithalten konnte

  • Wenn es sich um eine komplexe Technologie handelt, muss man sie zuerst lernen. Man sollte sie zuerst an kleinen, unwichtigen Services ausprobieren
    Immer nur eine Sache auf einmal, und einfach anfangen
    Ich habe unsere Services ohne Probleme nach Kubernetes migriert, aber es hat zwei Jahre gedauert, in denen ich beim Umzug kleiner Services gelernt und experimentiert habe
    Nachdem ich mehrere Ansätze ausprobiert hatte, kam ich bei der am besten passenden Methode an, und die war nicht etwas, das man direkt im Internet findet
    Wir verwenden GitOps, automatisieren aber nicht, sondern führen für das, was nötig ist, einfach kubectl apply -k aus. Damals hielten wir flux für unnötig komplex für den Einstieg
    Jetzt gibt es Dutzende Services und ein gewisses Verständnis, daher denken wir über die Einführung von flux nach

  • 1977 arbeitete ich als junger Prozessanwalt in einer Kanzlei, die nach Stunden abrechnete.
    Wir notierten auf Papier, welche Arbeit für welchen Fall erledigt wurde, und die Büroangestellten schnitten von den ausgefüllten Blättern abtrennbare Streifen ab und klebten sie innen auf die Kartonmappe des jeweiligen Falls.
    1979 kaufte ich einen RadioShack Tandy I und vertiefte mich bald zu Hause in Foxbase, ein DOS-basiertes Datenbankprogramm. Später wurde daraus FoxPro, das Microsoft Anfang der 1990er übernahm.
    1981 eröffnete ich meine eigene Kanzlei, und die neuesten Innovationen für Büroproduktivität waren damals Faxgeräte und elektrische Schreibmaschinen mit einzeiligem Display, Speicher und kleinen Disketten zum Speichern von Formularen. Unternehmen nutzten noch keine Personal Computer.
    Meine Kanzlei wuchs bald auf etwa 10 Anwälte und 12 Support-Mitarbeiter, und ich kaufte allen Sekretärinnen Compaq-Computer.
    Ich verbrachte viel Zeit damit, ein Zeiterfassungs- und Abrechnungsprogramm zu schreiben, das das manuelle Aufkleben der Streifen ersetzen sollte, und lernte auch, wie man ein Netzwerk installiert, das ich dann selbst einrichtete.
    Keine andere Kanzlei, die ich kannte, hatte überhaupt Computer, aber wir hatten mehr als 10 für die Support-Mitarbeiter und 4 oder 5 „tragbare“ Compaq-Rechner für die Anwälte, um Rechnungen zu prüfen, bevor sie an Kunden gingen.
    Gleichzeitig ruinierte ich mein Geschäft. In einer Zeit, in der andere nicht einmal einen Computer hatten, verfügten wir über Technologie auf Weltklasseniveau, aber statt mich auf juristische Arbeit oder die Akquise von Unternehmenskunden zu konzentrieren, schloss ich die Tür und programmierte nur noch.
    Am Ende schloss ich die Kanzlei 1994.
    Trotzdem war es eine aufregende Zeit. Bald hatten alle Kanzleien Computer für Textverarbeitung, aber kommerzielle Abrechnungsprogramme gab es noch nicht.
    Etwa 24 Monate lang wollten alle Anwälte anderer Kanzleien, mit denen ich zusammenarbeitete, mein Abrechnungsprogramm haben.
    Aber obwohl ich in Fallarbeit unterging, konzentrierte ich mich nur auf das spaßige Programmieren, und meine eigene Rechtspraxis war das perfekte Labor für das Programm. Leider ruinierte diese Programmierung mein Geschäft.

    • Diese Methode mit den abtrennbaren Streifen ist wirklich interessant. Ich frage mich, ob das damals eine gängige Methode der Zeiterfassung war.
      Falls es noch Fotos davon gibt, würde ich sie gern sehen.

  • In meinem Bereich kann man „Kubernetes“ einfach durch GraphQL/React/Next ersetzen, und es passt genauso.
    Natürlich geht es dabei um die Migration einer App, die perfekt funktioniert, noch dazu einer App, die größtenteils CRUD ist.
    Und das, obwohl man die Kompromisse, die GraphQL oder interaktive Frontends mit sich bringen, überhaupt nicht braucht.
    Je länger ich in dieser Branche bin, desto häufiger sehe ich, dass Menschen in verantwortlichen Positionen oft keine Ahnung haben, was sie tun.

    • Menschen werden nicht dafür belohnt, Dinge zuverlässig am Laufen zu halten.
      Sie werden für Veränderung belohnt, solange man zumindest so tun kann, als würde diese Veränderung Ergebnisse bringen oder irgendwann bringen.

  • Ich kämpfe seit vier Monaten Tag und Nacht damit, 500.000 Blobs von selbst gehostetem MinIO in einen gemanagten Blob-Speicher zu verschieben, und die tatsächlich produktive Arbeit, die nicht aus Politik und Bürokratie besteht, macht weniger als eine Woche aus.
    Deshalb klingt eine Kubernetes-Migration in 11 Wochen für mich nach einem Riesenerfolg.