Alle sagten: Geh serverless. Wir behielten den Kubernetes-Cluster, der meistens nur leerläuft

Der Rat ist überall zu hören und klingt offensichtlich richtig. Du betreibst Authentifizierung für Tenants, deren Traffic sprunghaft ist. Du zahlst rund um die Uhr für einen Kubernetes-Cluster. Azure Container Apps skaliert dich auf null herunter und stellt dir nur das in Rechnung, was du tatsächlich nutzt. Hör auf, für Leerlauf zu zahlen.

Wir haben das ernst genommen. Wir haben die Migration zu Azure Container Apps durchgerechnet, genau geprüft, was sie uns bringen würde, und sind bei AKS geblieben. Hier ist die Begründung, denn sie ist nicht die, die man aus dem Auslastungsdiagramm des Clusters erraten würde.

Der Rat ist richtig, nur für eine Arbeitslast, die wir nicht haben

Serverless-Container passen hervorragend zu zustandsloser, schubweiser Anfragebearbeitung: Jede Anfrage ist unabhängig, Instanzen sind Vieh und kein Traffic sollte keine Rechnung bedeuten. Das beschreibt eine Menge Web-Backends.

Es beschreibt kein Auth-Backplane. Unseres ist nicht auf die Art im Leerlauf, wie es eine zustandslose App ist. Es hält die Cluster-Führung und betreibt die Koordinationsschicht, die entscheidet, welches Replikat Singleton-Arbeit erledigt, etwa den Retention-Sweep und den Webhook-Durchlauf. (Diesen Leader wählen wir inzwischen über einen Blob-Lease, nicht mehr über Gossip, was eine eigene Geschichte ist.) Dass der Cluster ruhig ist, heißt nicht, dass er nichts zu tun hat; es heißt, dass er bereitsteht, den nächsten Token zu validieren und weiterhin der Leader zu bleiben. Ruhig und leerlaufend sind nicht derselbe Zustand.

Wir haben die Leerlaufkosten beseitigt, ohne umzuziehen

Hier ist der Teil, der den Ausschlag gab: Die Kosten, denen wir entkommen wollten, ließen sich viel günstiger beheben als durch Re-Platforming.

Was das Geld verbrannte, waren Nodes, die rund um die Uhr liefen, während der Traffic sich auf die Arbeitszeit konzentrierte. Also haben wir den Dev-Cluster so eingerichtet, dass er sich deallokiert, wenn ihn niemand nutzt (nachts und am Wochenende aus, bei Bedarf wieder hoch), und den Node-Pool auf eine günstigere SKU umgestellt. Das hat den Großteil der Leerlaufausgaben beseitigt, die Serverless zu entfernen versprach, und es hat uns eine Konfigurationsänderung gekostet statt einer Migration. Wenn die gewünschten Einsparungen an Ort und Stelle erreichbar sind, bedeutet ein Re-Platforming, um dieselbe Zahl zu jagen, viel Risiko für eine Differenz, die man bereits eingefahren hat.

Die Lehre lässt sich verallgemeinern: Rechne die Behebung durch, bevor du das Re-Platforming durchrechnest. „Hör auf, für Leerlauf zu zahlen" ist ein Ziel, keine Architektur, und der billigste Weg dorthin ist oft ein Scheduler und eine SKU, nicht eine neue Laufzeitumgebung.

Scale-to-Zero kämpft gegen ein Backplane, das einen Lease halten muss

Selbst wenn man die Kosten beiseitelässt, ist Scale-to-Zero für diese Arbeitslast in zweierlei Hinsicht schlicht falsch.

Erstens treffen Cold Starts den denkbar schlechtesten Pfad. Die Anfrage, die die Cold-Start-Steuer zahlt, kommt von jemandem, der sich anmelden will, und „deine Anmeldung war langsam, weil unser Auth-Dienst geschlafen hat" ist kein Satz, den man ausliefern möchte.

Zweitens stehen Führung und Scale-to-Zero in direktem Konflikt. Du kannst keinen Lease von einer Instanz halten, die weggeskaliert wurde. Ein Backplane, dessen ganze Aufgabe darin besteht, immer genau einen lebenden Leader zu haben, will keine Laufzeitumgebung, deren ganze Aufgabe darin besteht, Instanzen zu entfernen, wenn sie ruhig wirken. Wir würden gegen das Kernverhalten der Plattform ankämpfen, um unseres zu bewahren.

Die Laufzeitumgebung hätte uns drei Dinge genommen, die wir nutzen

Migrieren ist selbst dort nicht kostenlos, wo es funktioniert; du erbst die Sandbox der verwalteten Laufzeitumgebung, und unsere blockiert Dinge, auf die wir angewiesen sind:

• Twingate. Wir erreichen private Ressourcen über einen Twingate-Connector. Die verwaltete Container-Sandbox lässt ihn nicht laufen, also müssten wir den privaten Netzwerkzugang, den wir bereits haben, neu erfinden.
• Unser Build-Pfad. Teile unserer Pipeline stützen sich auf Docker-in-Docker und az acr build gegen eine private Registry, beides verbietet die Sandbox. Das ist ein Build-System, das neu aufgebaut werden muss, nicht bloß ein Deploy-Ziel, das man ändert.
• Cross-Cloud-Steuerung. Wir betreiben ein AWS-Standby, das Token validiert, die das Azure-Primärsystem ausgestellt hat, über föderierte JWKS, mit Cloudflare als Failover-Schiedsrichter. Das braucht Netzwerk- und Placement-Kontrolle, die eine verwaltete Laufzeitumgebung absichtlich verbirgt.

Jedes davon ist ein Workaround, den wir schreiben müssten, nur um dorthin zurückzukommen, wo wir bereits stehen. Die wahren Kosten der Migration sind nicht der Umstieg; es ist das Neuverdienen jeder Fähigkeit, die die Sandbox wegnimmt.

Kostensparen hat einen Rattenschwanz, und wir haben ihn bezahlt

Bleiben ist auch nicht ohne Konsequenzen, und es ist nur ehrlich, das zu sagen. Das Deallokieren von Nodes in der Nacht bescherte uns einen Fehler, den wir auf einem dauerhaft laufenden Cluster nie gesehen hätten: ein First-Image-Pull-Token-Race auf kalten Nodes (der mit dem AKS-Issue 4052), das gelegentlich einen Pod beim Hochfahren ins Stocken brachte, nachdem der Cluster wieder eingeschaltet war. Wir haben es mit einem längeren Rollout-Timeout behoben und in der Produktion damit, nicht so zu deallokieren, wie Dev es tut.

Das ist die wahre Form des Kompromisses. Jeder Weg hat einen Rattenschwanz an Fehlermodi; die Frage ist, ob du sie sehen und beheben kannst. Auf AKS war das Cold-Node-Race inspizierbar und behebbar. Die Sorten von Merkwürdigkeiten, die man aus dem Innenleben einer verwalteten Laufzeitumgebung erbt, sind die, zu denen man ein Support-Ticket aufmacht und wartet.

Die Regel, die wir mitgenommen haben

Zwei Dinge, über uns hinaus wiederverwendbar. Migriere nicht, um Kosten zu entkommen, die du an Ort und Stelle töten kannst; rechne zuerst die Behebung vor Ort durch, denn ein Scheduler und eine günstigere SKU schlagen ein Re-Platforming meistens. Und passe die Laufzeitumgebung an die Form der Arbeitslast an: Serverless belohnt zustandslos und schubweise und bestraft zustandsbehaftet und dauerhaft laufend, und ein Auth-Kern, der deine Signaturschlüssel und die Führung deines Clusters hält, ist eindeutig die zweite Sorte.

Wir sind nicht gegen Serverless. Ein Großteil unserer zustandslosen Oberfläche wäre damit gut bedient. Aber der Teil, der deine Schlüssel hält und entscheidet, wer die zerstörerischen Jobs ausführt, wird weiterhin auf langweiliger, dauerhaft laufender, inspizierbarer Infrastruktur laufen. Manchmal ist der scheinbar leerlaufende Cluster die billige Option, sobald man alles mitzählt, was man neu aufbauen müsste, um ihn zu verlassen.

Die stets aktive, inspizierbare Infrastruktur unter Ihren Logins ist ein Feature, kein Versäumnis. Genau das geben Sie ab, wenn Sie Ihre Authentifizierung mit Authagonal betreiben, statt das Backplane selbst zu verwalten.