- Figma migrierte seine bereits containerisierten Kerndienste von ECS zu EKS-basiertem Kubernetes und verfolgte dabei das Ziel, die Migration ohne Downtime durchzuführen und langfristige Plattformgrenzen zu reduzieren
- In ECS waren das Fehlen von StatefulSets, die schwierige Nutzung von Helm-chart-basiertem OSS und Einschränkungen bei der Node-Isolierung große Probleme; Kubernetes eröffnete dagegen Optionen im CNCF-Ökosystem wie Keda, Karpenter und Istio
- Die Migration wurde im Umfang begrenzt, indem die Abstraktionen für Service-Ausführung, Deployment und Tools beibehalten und nur die Orchestrierung ausgetauscht wurde; zu Beginn gehörten auch Bazel-basierte Service-Definitionen und der Aufbau von drei EKS-Clustern dazu
- Während der Umstellung wurden Lasttests, schrittweise Traffic-Migration per Weighted DNS, eine frühe Verlagerung realer Dienste, das Verbergen von rohem YAML und die Zusammenarbeit mit Service-Ownern genutzt, um Rollback-Fähigkeit sicherzustellen
- Bis Januar 2024 waren die meisten Dienste mit höchster Priorität auf EKS migriert; danach setzte Figma die Arbeit an geringeren Overprovisioning-Kosten, höherer Zuverlässigkeit und einer besseren Developer Experience mit Logging, Auto-Scaling und der Umstellung auf Graviton fort
Warum von ECS zu Kubernetes wechseln?
- Anfang 2023 führte Figma bereits alle Services in Containern aus und nutzte AWS Elastic Container Service (ECS) als Orchestrierungsplattform
- Bei der Prüfung der nächsten Compute-Plattform kam Figma zu dem Schluss, dass es langfristig schwierig wäre, die gewünschten Funktionen weiter auf ECS aufzubauen
- Da Figma kein Unternehmen mit Tausenden von Microservices ist, ließ sich der Umfang einer Kubernetes-Migration realistisch steuern
- Zwar werden manchmal neue Services wegen Isolation oder Performance benötigt, aber die Kerndienste bieten bereits grundlegende Modularisierung und Traffic-Isolierung
- Auch neue Produkte werden oft unterstützt, indem Logik in bestehende Kerndienste eingebaut wird, statt neue Services zu schaffen
Welche Funktionen in ECS fehlten
- ECS unterstützt die StatefulSets von Kubernetes nicht, was den Betrieb stark konsistenter Konsens-Datenspeicher wie etcd erschwerte
- Figma umging das mit Custom Code, der beim Start des etcd-Containers die Cluster-Mitgliedschaft dynamisch aktualisierte
- Dieser Ansatz war fragil und schwer wartbar; in Kubernetes ist die zustandsbehaftete Netzwerkzuweisung von StatefulSets der übliche Weg
- In ECS war es schwierig, per Helm charts definierte Service-Bundles auszuführen
- Auch das saubere Abschalten einer einzelnen fehlerhaften EC2-Maschine in ECS on EC2 war umständlich
- In EKS können fehlerhafte Nodes per cordon markiert werden, woraufhin der API-Server das Herunterfahren respektiert und Pods auf andere Maschinen verschiebt
CNCF-Ökosystem und Plattformwahl
- Bei einem Verbleib auf ECS wäre es schwierig gewesen, Open-Source-Technologien aus dem Cloud Native Computing Foundation (CNCF)-Ökosystem zu nutzen
- Auto-Scaling war ein wichtiges Thema für die nächste Compute-Plattform
- Damals nutzte Figma für seine containerisierten Services noch kein Auto-Scaling
- Services wurden selbst nachts und am Wochenende so provisioniert, dass sie Peak-Lasten abfangen konnten, was unnötige Kosten verursachte
- Keda aus dem Kubernetes-Ökosystem unterstützt Skalierung nicht nur nach CPU-Auslastung, sondern auch anhand der Länge von AWS SQS-Queues und benutzerdefinierten Datadog-Metriken
- Auch ein Service Mesh könnte langfristig nötig werden
- Bestehender Traffic zwischen Services wurde über AWS Application Load Balancers (ALB) und Network Load Balancers (NLB) geroutet
- Bei NLB dauert das Registrieren neuer Targets und das Entfernen bestehender Targets mehrere Minuten, was Notfall-Deployments verlangsamt und die mittlere Wiederherstellungszeit bei Incidents erhöht
- Envoy bietet mehr Anpassbarkeit und die Möglichkeit, Custom Filter auszuführen
- Figma hatte bereits einen separaten Cluster aus Envoy-Maschinen als Proxy vor wichtigen Services eingesetzt und dabei Custom Filter verwendet, um während Incidents Last zu reduzieren
- In EKS gibt es viele Open-Source-Optionen wie Istio; in ECS hätte Figma ähnliche Funktionen selbst neu bauen müssen
Operative Vorteile einer populären Plattform
- Figma möchte nicht der größte Nutzer eines bestimmten Services oder einer bestimmten Software sein
- Die größten Nutzer stoßen meist zuerst auf raue Kanten und Skalierungsgrenzen
- Kubernetes wird von vielen großen Unternehmen für riesige Compute-Plattformen verwendet, und Figma ist im Vergleich ein deutlich kleinerer Nutzer
- Kubernetes hilft, Vendor Lock-in zu reduzieren
- EKS bietet die Vorteile einer vom Vendor unterstützten Control Plane
- Da die Services so geschrieben werden, dass sie auf generischem Kubernetes laufen, ist der Wechsel auf eine andere vom Vendor unterstützte Kubernetes-Plattform oder eine selbst gehostete Plattform kein großer Aufwand
- Es ist einfacher, Engineers mit Kubernetes-Erfahrung einzustellen
- Engineers mit Vorerfahrung können sich schnell einarbeiten und Kontext in Bereichen liefern, die für Figma neue Entscheidungen erfordern
Prinzipien zur Festlegung des Migrationsumfangs
- Bei großen Migrationen ist es sicherer, nur das Kernsystem auszutauschen, das man ändern will, und die für Plattformnutzer sichtbaren Abstraktionen möglichst beizubehalten
- Figma begrenzte den Umfang darauf, Services statt auf ECS auf EKS laufen zu lassen, ohne zu verändern, wie Services ausgeführt, deployt oder über Tools miteinander verbunden werden
- Selbst Arbeiten, die nicht wie Funktionsänderungen wirken, können Folgewirkungen haben, wodurch der Zeitplan großer Migrationen leicht anwächst
- Es gab zwei Ausnahmen
- Wenn es übermäßig aufwendig gewesen wäre, das neue System exakt wie das alte arbeiten zu lassen, konnte Figma die Folgewirkungen in Kauf nehmen und den neuen Weg wählen
- Bei schwer oder teuer rückgängig zu machenden One-way-door-Entscheidungen konnte der neue Ansatz von Anfang an eingeführt werden
Verbesserungen innerhalb des Umfangs
-
Developer Experience
- Bestehende ECS-Service-Definitionen wurden überwiegend mit Terraform erzeugt und geändert
- Durch Terraform-Anwendung wurde zunächst ein ECS-task-set-Template mit 0 Instanzen erstellt; im Deployment wurde das Template dann kopiert, der Image-Hash ersetzt und anschließend ein Task Set mit nicht null Instanzen in ECS ausgerollt
- Selbst das Hinzufügen einer einzelnen Umgebungsvariable erforderte das Schreiben und Anwenden von Terraform und danach ein Deployment; wurde die Reihenfolge nicht eingehalten, konnte die Variable im Code nicht sicher verwendet werden, was Bugs verursachte
- In EKS wurden Service-Definitionen an einer Stelle zusammengeführt und Änderungen in einem Schritt ausgerollt
- Figma entwickelte dafür einen einfachen internen Ansatz zur Service-Definition über Bazel-Konfigurationsdateien und generiert daraus automatisch Service-YAML sowie Konfigurations-YAML wie Ingress
- Das YAML wird beim Code-Commit im CI-Tool erzeugt und über das interne Deployment-System ausgerollt
-
Zuverlässigkeit
- Für jeden Service wurden drei EKS-Cluster so konfiguriert, dass sie Pods ausführen und Traffic annehmen
- Wenn alle Operationen auf Cluster-Ebene erfolgen, reduziert sich ein vollständiger Ausfall auf Auswirkungen für ein Drittel eines Services
- Bei Services mit Retry-fähigen Requests oder asynchroner Verarbeitung bleibt die Unterbrechung für Nutzer oft minimal
- Diese Architektur erhöhte die operative Komplexität, etwa in der Deployment-Pipeline, deutlich, wurde aber als Änderung bewertet, die man besser direkt während der Migration als später einführt
-
Kosteneffizienz
- Komplexe Kostenoptimierungen wurden kaum in den Migrationsumfang aufgenommen, Node Auto-Scaling jedoch von Anfang an
- In ECS on EC2 wurden Maschinen überprovisioniert, um Lastspitzen während Deployments abzufangen
- In EKS nutzt Figma Karpenter, um Nodes je nach Bedarf dynamisch hoch- und herunterzuskalieren
Aus dem Umfang ausgenommene Arbeiten
- Die bestehende Logging-Pipeline war komplex
- Alle Logs wurden zunächst in CloudWatch geschrieben
- Eine Lambda-Funktion las diese Logs und führte Transformationen wie das Entfernen bestimmter Muster und das Hinzufügen von Tags aus
- Danach wurden sie in Datadog und Snowflake geschrieben
- Die Kosten von CloudWatch als Zwischenspeicher stiegen bereits deutlich an
- Figma plante für den EKS-Stack die Einführung des CNCF-Projekts Vector, um Logs als Sidecar zu verarbeiten und weiterzuleiten
- Das Portieren der Log-Forwarder-Logik in Vector-Konfigurationen wurde jedoch als Folgewirkung nicht als lohnend für den Migrationsumfang angesehen
- Auch Pod-level Auto-Scaling war nicht Teil der Migration
- Die Komplexität wurde als zu hoch eingeschätzt
- Gleichzeitig galt es als etwas, das sich später leicht ergänzen lässt
- Diese ausgeschlossenen Arbeiten wurden danach zu Folgeprojekten und konnten parallel zu weiteren EKS-Migrationen anderer Services verbessert werden
Sichere Umsetzung
- Da der bestehende ECS-Stack relativ stabil war, musste auch der neue EKS-Stack samt Migrationsprozess mindestens ähnlich zuverlässig sein
-
Lasttests
- Figma erstellte einen „Hello, World“-Service und skalierte ihn auf dieselbe Anzahl Pods wie beim größten Service des Unternehmens
- Dadurch wurde sichtbar, dass Größe und Skalierung zentraler Compute-Services für die gesamte Plattform angepasst werden mussten
- Kyverno als Tool zur Cluster-Sicherheitsprüfung konnte den Start neuer Pods verzögern, wenn es nicht ausreichend groß dimensioniert war
-
Schrittweiser Rollout
- Mithilfe von Weighted-DNS-Einträgen wurde der Traffic schrittweise vom bestehenden ECS-Service auf das entsprechende EKS-Pendant verlagert
- Feingranulare Kontrolle über Traffic-Umschaltung und Rücknahme war entscheidend für eine sichere Migration
- Unerwartete Auswirkungen können an unbekannten Kipppunkten auftreten; deshalb musste der Blast Radius klein gehalten und ein schnelles Rollback möglich sein
-
Früher Einsatz echter Services
- Wenn echte Workloads auf einem System laufen, lernt man vieles, was in Staging allein nicht sichtbar wird
- Figma migrierte bereits einen Service, noch bevor die Staging-Umgebung vollständig aufgebaut war
- Diese frühe Migration half, die End-to-End-Fähigkeit des Systems zur Ausführung realer Workloads zu validieren und Engpässe sowie Bugs zu finden
-
YAML-Abstraktion
- Würde man Nutzer Services direkt in rohem Kubernetes-YAML definieren lassen, könnte das verwirrend sein
- Figma bot daher einen golden path an und ließ Anpassungen nur für Sonderfälle zu
- Durch klare Grenzen dafür, was Nutzer anpassen können und sollten, wurde konsistentes Standardverhalten erzwungen, was Wartung und spätere Änderungen vereinfachte
-
Zusammenarbeit mit Service-Ownern und Staffing
- Die Plattform-Teams übernahmen die Konfiguration neuer Services und arbeiteten bei Monitoring- und Alerting-Updates eng mit den Service-Ownern zusammen, die den Zustand ihrer Services am besten kannten
- Schon vor Beginn der Migration wurden Optionen und Trade-offs ausführlich mit den Service-Ownern besprochen
- Migrationen in diesem Umfang können unerwartete Probleme, komplexe Wechselwirkungen und gewöhnliche Bugs erzeugen; daher war ein Team mit tiefer technischer Expertise und starkem Debugging-Know-how nötig
Tatsächlicher Migrationszeitplan und Ergebnisse
- Im ersten Quartal 2023 wurden die Pläne erstellt und Zustimmung für die Durchführung der Migration eingeholt
- Im zweiten Quartal 2023 wurden die Staging-Umgebung aufgebaut und ein einzelner Service migriert
- Im dritten Quartal 2023 lag der Fokus auf Produktionsreife, Lasttests und der Vorbereitung weiterer Service-Migrationen
- Ab dem vierten Quartal 2023 bis zur ersten Januarwoche 2024 wurde der Service-Traffic langsam umgeschaltet
- Bis Januar 2024 waren die meisten Services mit höchster Priorität auf die neuen EKS-Cluster migriert
- der Monolith mit zentraler Geschäftslogik
- ein komplexer Service, der die Multiplayer-Aspekte der Bearbeitung von Figma-Dateien verarbeitet
- die zusammengesetzten Services von Livegraph 100x, die Echtzeit-Updates an alle Clients ausliefern
- Das Ergebnis waren geringere Overprovisioning-Kosten für Deployments, höhere Zuverlässigkeit durch den Betrieb über drei Cluster und eine bessere Nutzbarkeit für Entwickler
- Insgesamt verlief die Arbeit mit kleinen Incidents und geringer Auswirkung auf Kunden
- In einem Incident löschte und erstellte ein Operator versehentlich CoreDNS in einem Produktionscluster neu
- In der früheren Konfiguration hätte das zu einem vollständigen Ausfall geführt
- In der Architektur mit drei Clustern blieb die Auswirkung auf ein Drittel der Requests begrenzt
- Die meisten Downstream-Services wiederholten ihre Requests, sodass sie letztlich erfolgreich waren
Tooling-Verbesserungen nach dem Launch
- Figma entwickelte Tools, mit denen Service-Owner debuggen konnten, was in den Clustern geschah
- Anzahl laufender Instanzen prüfen
- auf die Container-Shell zugreifen
- operative Aufgaben wie Notfall-Skalierung durchführen
- Direkt nach dem Launch kam das Feedback, dass diese Zugriffstools nicht ausreichend nutzerfreundlich waren
- Die Komplexität hatte zwei Ursachen
- Durch die Einführung von drei Clustern mussten Nutzer Befehle clusterübergreifend ausführen und bei jedem Kommando den Clusternamen angeben
- Durch die Nutzung von Kubernetes-RBAC-Rollen für feinere Berechtigungen mussten Nutzer verstehen, welche Rollen sie hatten und welche Rolle für eine bestimmte Aktion erforderlich war
- Figma stoppte daraufhin sofort andere Arbeiten und passte die Tools so an, dass sie den passenden Cluster und die passende Rolle automatisch ableiten
- Nutzer müssen so insbesondere bei nächtlichen Notfällen keine Zeit mehr mit der Suche nach Rollen verschwenden
Nächste Schritte
- Während die Migration der verbleibenden Services weiterläuft, verbessert Figma parallel die neue Compute-Plattform
- Aktuelle Schwerpunktbereiche sind:
- Vereinfachung des Designs der Logging-Pipeline
- Unterstützung für horizontales Pod Auto-Scaling mit Keda
- Migration der teuersten Services bei Figma auf Graviton-Prozessoren, um Kosten zu senken und einen Pfad für weitere Services auf Graviton zu schaffen
- Geplant ist auch die Erkundung von Bereichen, in die bisher noch nicht tief investiert wurde
- Prüfung eines Service-Mesh-Angebots zur Verbesserung von Zuverlässigkeit und Observability des Networking-Stacks
- Verwaltung weiterer Ressourcen mit AWS Controllers for Kubernetes (ACKs), um die Terraform-Abhängigkeit zu reduzieren und den Stack zu vereinfachen und zu konsolidieren
- Zusammenarbeit mit dem Developer-Experience-Team, um zu vereinheitlichen, wie Services in Entwicklungsumgebungen und in anderen Umgebungen ausgeführt werden
1 Kommentare
Hacker-News-Kommentare
Ich persönlich mag Kubernetes. Ich betreibe mehrere kleine, aber komplexe maßgeschneiderte E-Commerce-Shops und kümmere mich gleichzeitig um Marketing, Finanzen und Kundensupport.
Früher lief das auf dedizierten Servern, aber der Stack war ziemlich komplex, sodass Deployments ein Albtraum waren, und die Belastung durch Deployments bremste letztlich die Geschwindigkeit des kleinen Unternehmens aus.
Es hat einen Monat gedauert, Kubernetes zu lernen und umzuziehen, und ich betreibe etwa 25 Services, darunter Frontend, Produktmanager, Logistik-Dashboard, Optimierung von Lieferrouten, OSRM, ERP, Recommendation Engine, Suche usw.
Durch das Zusammenführen der Cluster-Konfiguration an einem Ort wurde die Struktur wiederholbar, und ich kann genau sehen, in welchem Zustand jeder Service ist und welche Version läuft. Auch Rolling Deployments ohne Ausfallzeit wurden möglich. Es ist zwar komplex, aber Programmierer beschäftigen sich nun einmal mit komplexen Dingen. Auch Nginx-Konfigurationsdateien sind komplex.
Je tiefer man einsteigt, desto besser versteht man, warum die Architektur von Kubernetes sinnvoll ist, und es erzwingt eine strikte Einhaltung von 12-Factor. Wenn die Einnahmen direkt mit der Verfügbarkeit und Stabilität des Stacks verbunden sind, ist Hochverfügbarkeit mehr als nur „nice to have“. Die Hosting-Kosten liegen auch nur bei etwa 400 Dollar im Monat, also ist es nicht besonders teuer.
Ich vertraue Kubernetes grundsätzlich, aber es ist wirklich komplex. Es ist ein Werkzeug, das schwierige Probleme löst. Wenn man Multi-Cloud nutzt, muss man nicht lange überlegen, und wenn man eine komplexe Infrastruktur möchte, die lokal 1:1 abbildbar ist, passt es gut.
Aber wenn man weniger als 100 Entwickler hat und nur Container auf AWS deployt, halte ich es 2024 für verrückt, EKS statt ECS + Fargate zu verwenden.
Die Migration an sich, um die Infrastrukturgrundlage zu verbessern, ist gut. Überraschend fand ich allerdings, dass eine der Motivationen darin bestand, Teams dazu zu bringen, Helm Charts zu verwenden, statt nach Terraform zu konvertieren.
In der Praxis habe ich selten gesehen, dass beliebige Helm Charts ohne Änderungen stabil verwendet werden können; wenn man ihre Nutzung fördert, forken und ändern Teams am Ende die Charts. Helm ist ein derart furchtbares Tool, dass ich keine eigenen angepassten Helm Charts pflegen möchte.
Ich denke, es ist einfacher, sie stattdessen in Terraform neu zu schreiben und eine lokale Version zu pflegen. Falls es Gegenbeispiele gibt, würde ich sie gern hören. Vielleicht sind der
indent 4-Wahnsinn von Helm und die Probleme mit mehrstufigen String-Templates inzwischen verschwunden.Man kann Kubernetes-Workloads zwar mit Terraform verwalten, aber ich würde es nicht empfehlen. Kubernetes hat bereits seinen eigenen Zustand; wenn Terraform ebenfalls Zustand hält, wird die Kombination aus Terraform + Kubernetes schmerzhaft. Helm wurde für Kubernetes gebaut, Terraform nicht.
Das heißt nicht, dass ich Helm mag. Templatisiertes YAML gefällt mir nicht, und der
indent 4-Wahnsinn existiert immer noch. Kustomize ist gut, solange es einfach bleibt, aber wenn eine App komplexer wird, finde ich es schlimmer als Helm. Wenn man zum Beispiel eine App mit Ingress, TLS-Zertifikat und external-dns für mehrere Umgebungen deployen will, muss man Ressourcen dreimal patchen, obwohl es reichen würde, eine Variable an drei Stellen zu verwenden.Helm und Terraform sind beide sehr populär und werden deshalb oft erwähnt, aber am Ende wird wohl ein noch nicht weit verbreitetes Tool auftauchen, das beide ersetzt.
Das Problem bei Terraform ist, dass man Workspaces so entwerfen muss, dass man die empfohlene Zahl von etwa 100 bis 200 Ressourcen pro Workspace nicht überschreitet. Andernfalls wird
plandeutlich langsamer, weil auch Datenbanken oder Netzwerke geprüft werden, die man gar nicht angefasst hat und auch nicht anfassen will, wodurch sich die Deployment-Zeit verlängert.In der Praxis baut man ein Raster aus Terraform-Workspaces, die sich gegenseitig triggern, und dafür gibt es derzeit kein gutes Open-Source-Tool mit ordentlicher Unterstützung.
Aus heutiger Sicht ist es am besten, wenn Terraform ein Continuous-Deployment-Tool wie ArgoCD als Teil der Infrastruktur installiert und das CD-Tool die alltäglichen Deployments übernimmt. Und die meisten CD-Tools verlangen, dass Deployments mit etwas wie Helm paketiert werden.
Aber es hat so viele Fallstricke, dass man Zeit damit verbringt, die Arbeit anderer Engineers noch einmal zu machen und zu debuggen.
Ich hoffe, dass ein neues Tool namens
timonian Schwung gewinnt. Es löst fast alle Beschwerden, die ich gegenüber Helm habe. Wenn man nach einer besseren Lösung sucht, lohnt sich ein Blick auf timoni.Wir haben uns dafür entschieden, öffentliche Helm Charts unverändert zu verwenden und die Anpassungen mit
kustomize —enable-helmzu erledigen.In unserem Fall haben wir ein einzelnes anwendungs-/servicebasiertes Helm Chart mit vernünftigen Defaults, und alle Deployments erweitern es. Auf der Nutzerseite sind nur minimale Helm-values-Einstellungen nötig, und Fälle, in denen eigene Templates eingefügt werden mussten, gab es kaum. Das liegt daran, dass das Basis-Chart genügend Stellschrauben bereitstellt.
Viele Third-Party-Charts konnten wir unverändert deployen, und gelegentlich haben wir benötigte Funktionen per PR upstream ergänzt. Selten mussten wir wrappen oder forken, aber es gibt deutlich mehr Third-Party-Charts, die wir unverändert deployt haben.
Beim Pflegen eigener Charts ist helm unittest (https://github.com/helm-unittest/helm-unittest) sehr hilfreich, um Regressionen zu vermeiden.
Wir verwalten zwar einige Kubernetes-Ressourcen, darunter ArgoCD, mit Terraform, aber im Allgemeinen war es deutlich einfacher zu verwalten und produktiver, Helm Charts über ArgoCD zu deployen.
Ich finde es erstaunlich, wie viel Anti-Kubernetes-Stimmung es auf HN gibt. Ich frage mich, ob die meisten Kommentatoren Entwickler sind, die mit Diensten wie Heroku, fly.io oder render.com vertraut sind, oder ob sie ihre Apps auf VMs betreiben.
Das ist kein Problem, das auf einzelne Fälle beschränkt ist, sondern eines, das aus branchenweit stark fehlgeleiteten Anreizen und in gewissem Maß aus dem Goldrausch der Niedrigzinsära entstanden ist.
Ehrlich gesagt würden wir in der heutigen Form in anderen Bereichen wohl wie ziemlich nutzlose Handwerker wirken. Wir sind auf ungesunde Weise von Tools und Meta-Arbeit besessen und werfen eine vernünftige Ressourcennutzung immer wieder aus dem Fenster, nur um ein bestimmtes Tool einzusetzen. Es ist eine Art Situation wie „vorübergehend in Schwierigkeiten geratener FAANG-Ingenieur“.
Es ist schwer zu erklären, wie viel länger es dauert, wie viel mehr Expertise nötig ist, wie viel fragiler es wird und wie viel mehr Geld es kostet, auf Kubernetes zu bauen statt auf ein Bereitstellungsmodell, das man bei AWS wählen kann, etwa VM-Images auf EC2, Elastic Beanstalk, ECS/Fargate oder Lambda.
Ich möchte keinen eigenen ELK-Stack oder Prometheus installieren und warten. Ich möchte mich auch nicht mit CNI-Plugins, Kafka, hochverfügbarem Postgres, Argo, Helm und Control-Plane-Upgrades herumschlagen. Mit den entsprechenden AWS-Diensten kann man fast sofort loslegen, hat kaum Wartungsaufwand, und die Kosten beginnen normalerweise nahe null und steigen linear.
Man kann Geschäftsprobleme viel schneller und effizienter lösen. Das ist der Unterschied zwischen einer Situation, in der man Erwartungen deutlich übertreffen kann, und einer, in der das gesamte Team um mehrere Quartale zurückfällt.
Wenn es allerdings echte Anforderungen an Multi-Cloud oder On-Premises gibt, würde ich nichts anderes als Kubernetes verwenden wollen. In einem großen Unternehmen mit vielen erfahrenen Ingenieuren, die Kubernetes verstehen, ist es vielleicht gar nicht so schlecht. Zumindest war das an den Orten, an denen ich gearbeitet habe, nicht der Fall.
Es ist schön zu sehen, wie Unternehmen hauptsächlich zu Open-Source-Infrastruktur wechseln. Ein großer Teil davon kommt aus der CNCF (https://landscape.cncf.io), der ASF und vielen Projekten auf GitHub.
kata-containers könnte diese Sorge vielleicht ausräumen und dafür sorgen, dass mir Kubernetes Spaß macht.
Insgesamt gibt es an Kubernetes für mich persönlich nichts, das ich cool finde. Container, Load Balancer und megabytegroßes YAML habe ich alles schon gesehen, und es fühlt sich nicht interessant genug an, um es auszuprobieren.
Bei einem Unternehmen dieser Größe mag das normal sein, aber ich finde es schwer, die Entscheidungsfindung hinter solchen riesigen Migrationen oder Technikprojekten nachzuvollziehen. Denn die Entscheidung wirkt nicht so, als käme sie aus einem Bedarf der Nutzer oder des Unternehmens.
Bei einem ähnlichen Beitrag von Figma zu Datenbanken hatte ich früher denselben Eindruck.
Wenn der Grund für den Wechsel zu Kubernetes zum Beispiel ist, dass man auf ECS etcd/Helm nicht nutzen kann, sollte man zuerst fragen, warum man etcd/Helm nutzen möchte. Ist das wirklich so wichtig? Gibt es wirklich nur genau diesen Weg, um die Ziele des Unternehmens zu erreichen?
Wenn eine Entscheidung auf den Bedürfnissen der Nutzer basiert, lässt sich leichter prüfen, ob nachgelagerte Entscheidungen sinnvoll sind. Wenn sie aber auf technischen Wünschen basiert, können die nachgelagerten Entscheidungen im Kontext dieses technischen Wunsches plausibel wirken, während weiter unklar bleibt, ob sie im Nutzerkontext sinnvoll sind.
Entweder verstehe ich Organisationen dieser Größe nicht, oder es ist für Organisationen dieser Größe grundsätzlich schwierig, wertvolle Arbeit zu identifizieren und darüber zu argumentieren.
Wir sind im Kern ein Plattformteam und bauen oft Tools für andere Plattformteams, die wiederum Tools bauen, die Figma-Entwickler unterstützen, welche die eigentliche Produkterfahrung schaffen. Je weiter man vom Endnutzer entfernt ist, desto schwieriger wird es, richtige Entscheidungen herzuleiten, aber gleichzeitig entsteht auch ein großer Hebel.
Wenn man die Plattform richtig baut, wirkt sich das auf die Fähigkeit aller anderen Ingenieure aus, effizient und effektiv zu arbeiten. Viele dieser Auswirkungen sind indirekt.
Es hätte definitiv auch die Option gegeben zu sagen, dass wir etcd und Helm nicht unterstützen können und sie sich andere Umwege suchen sollen. Die beiden waren für uns aber zusätzliche Datenpunkte, die uns zu dem Schluss gedrängt haben, dass wir unsere Compute-Plattform auf den falschen Grundbausteinen betrieben.
Auch wenn die Herleitung schwierig ist, lohnt es sich sehr, sich zu bemühen, sie gut zu machen. Denn als Plattformteam ist das die Art und Weise, wie wir sicherstellen, dass wir die richtigen Dinge tun, um zur bestmöglichen Plattform zu gelangen. Deshalb haben wir viel Zeit in diese Entscheidung investiert und fanden es ein interessantes Thema, darüber zu schreiben.
Viele Kubernetes-Migrationen großer Unternehmen werden wahrscheinlich vom Wunsch nach Multi-Cloud oder hybriden On-Premises-Setups sowie von der Reduzierung von Kosten-, Verfügbarkeits- und Lock-in-Risiken angetrieben.
VM-Upgrades, Authentifizierung, Backups, Log-Rotation und Ähnliches müssen alle aufeinander abgestimmt werden.
In Kubernetes gibt man jedem seinen Namespace, Policies und Volumes, und dank DaemonSets sowie des Kubernetes-/Cloud-native-Stacks ist auch automatische Log-Aggregation möglich.
Dazu kommt Self-Healing und so weiter; es ist schwer zu beschreiben, wie viel besser das wird.
Es gibt zum Beispiel nur wenige hochverfügbare und konsistente Datenspeicher, die man als Entsprechung zu einer
.pid-Datei in einer verteilten Umgebung verwenden kann. Mir fällt nur Zookeeper ein, aber der ist im Betrieb wirklich schmerzhaft, verlangt alte JVM-Versionen und ist trotzdem insgesamt instabil.Wenn Terraform-Code angewendet wurde, wurde ein ECS-Task-Set mit 0 Instanzen erstellt, um ein Service-Template hochzufahren. Danach musste ein Entwickler beim Deployment eines Services dieses Template-Task-Set klonen und mehrere manuelle Schritte ausführen. Das klingt weniger nach einem Problem von ECS als danach, dass die Deployment-Verwaltung mit Terraform + ECS übermäßig komplex gemacht wurde
Ich verstehe, dass man vor dem eigentlichen Deployment ein Template zur Validierung erzeugt. Aber das ist etwas uneindeutig
Deshalb habe ich diesen Punkt bewusst als Aufgabe eingeordnet, die wir in den Migrationsprozess aufnehmen wollten, und nicht als einen der grundlegenden Gründe, warum wir die Migration begonnen haben
Allerdings kann ich mir einige Szenarien vorstellen, in denen dieser Ansatz nötig wird. Zum Beispiel, wenn viele Services auf ECS deployt sind und der Terraform-State dadurch groß wird. Dann werden plan und apply deutlich langsamer, und es kann viel sicherer sein, die Konfiguration templatebasiert unverändert zu klonen und den Terraform-State zu sharden
Im Grunde bestand alles daraus, Umgebungsvariablen in die Terraform-Datei einzutragen, zu mergen und dann CI deployen zu lassen. Die meisten unserer Konfigurationsänderungen liefen über diesen Prozess
„Eine Migration zu Kubernetes kann Jahre dauern“ – was lese ich hier eigentlich?
Für wen soll das gelten? Ich verstehe auch nicht wirklich, warum Unternehmen solche Migrationen überhaupt machen. Wo ist der Business Value, und wo ist der Nutzen für die Kunden? Ist das so ein „Kunst um der Kunst willen“-Projekt, das Figma macht, weil es es eben kann?
Selbst in einem sehr etablierten Unternehmen mit etwa 30 Jahren Altlasten sind wir in deutlich kürzerer Zeit zu Kubernetes gewechselt. Allerdings haben wir nicht versucht, alles nach Kubernetes zu verlagern, sondern nur das, was davon profitieren konnte
Unser Vorschlag war ungefähr so: Wenn ihr zu Kubernetes wechselt, müsst ihr bei dem für Jahresende geplanten Rechenzentrumsumzug außer Checks nichts tun. Andernfalls müsst ihr die Apps auf neue Maschinen oder VMs neu deployen und all die damit verbundenen Kopfschmerzen bewältigen. Wenn ihr noch nicht containerisiert seid, containerisiert jetzt, dann übernehmen wir den Rest
Die meisten sind migriert und waren mit dem Ergebnis sehr zufrieden. Dienste hingegen, die latenzsensitiv waren oder im High-Performance-Computing-Bereich lagen, hatten keinen Grund, zwanghaft umzuziehen, und wir haben auch nicht versucht, sie hineinzupressen
Wie lange wird es dauern, davon wieder wegzukommen?
Wenn die App bereits in Microservices aufgeteilt ist, ist auch der Rückweg nicht einfach
Wenn ich Blogposts lese, in denen sechs CNCF-Projekte mit coolen Namen, von denen ich noch nie gehört habe, ganz beiläufig erwähnt werden, nur um scheinbar einfache Funktionalität zu bekommen, fühle ich mich, als wäre ich nicht mehr auf der Höhe der Zeit
Ich frage mich ernsthaft, ob es Zeit ist, aus der professionellen Softwareentwicklung alt geworden auszusteigen
Es bedeutet nur, dass du mit einem bestimmten Ansatz zur Skalierung von Organisationen nicht vertraut bist, nämlich damit, dass Plattform-Teams Hardware, Logging, Retries usw. abstrahieren
Das ist nicht der einzige Ansatz, also bist du vielleicht mit anderen Vorgehensweisen vertraut
Mir gefällt an diesem Artikel, dass er klar und schlüssig erklärt, welche Vorteile Kubernetes bringen soll und warum
Viele Teams stürzen sich darauf, ohne zu wissen, was sie gewinnen oder ob sie es überhaupt brauchen. Die hier genannten Gründe wirken aber vernünftig
Andere Kommentare haben diesen Punkt bereits angesprochen: https://news.ycombinator.com/item?id=41194506 https://news.ycombinator.com/item?id=41194420
Aus reiner Neugier: Welche anderen modernen Systeme oder Services gäbe es, bei denen jemand bei Verstand damit prahlen würde, innerhalb eines Jahres migriert zu sein?
Ein System wie Kubernetes ist meist Kernbestandteil der Infrastruktur und betrifft alles, was läuft. Nimmt man dazu noch die im Artikel genannten Team-Einschränkungen, klingt ein Jahr gar nicht so schlecht
Was mir spontan einfällt, ist, dass Amazon früher einmal vollständig von Oracle auf relationale Datenbanken von Amazon/Open Source umgestiegen ist. Allerdings dauerte das, soweit ich mich erinnere, mehrere Jahre. Wenn sie es in einem Jahr geschafft hätten, hätten sie sicher damit geprahlt
Häufig geht es dabei weniger um die Technologie selbst als um technische Schulden, Integrationskomplexität und die eingesetzten Mitarbeiter