Scale-to-Zero kann nicht bis eins zählen
Der Rat hatte immer die gleiche Form. Ihr Auth-Traffic kommt in Spitzen. Ihr Kubernetes-Cluster sitzt meistens still. Azure Container Apps skaliert auf null herunter und berechnet Ihnen nur das, was Sie nutzen. Sie bezahlen rund um die Uhr für einen Cluster, der den Großteil seiner Lebenszeit mit Warten verbringt.
Wir nahmen es ernst genug, um die Migration richtig durchzukalkulieren. Dann haben wir sie verworfen. Nicht wegen der Kosten des Umstiegs und nicht wegen der Cold Starts, obwohl die Cold Starts allein hätten reichen müssen. Wir haben sie verworfen, weil dem Vokabular der Plattform eine Zahl fehlt, und es ist die einzige Zahl, die unseren Auth-Kern wirklich interessiert.
Serverless zählt bis null und bis N
Scale-to-Zero-Laufzeiten kennen zwei Zahlen. Null, wenn keine Aufrufe kommen. N, wenn welche kommen, wobei N mit der Last schwankt. Für zustandslose Anfragebearbeitung ist dieses Vokabular perfekt, weshalb der Rat so richtig klingt. Die meisten Web-Backends haben wirklich diese Form: jede Anfrage unabhängig, jede Instanz wegwerfbar, null Traffic verdient eine Rechnung über null.
Die öffentliche Seite eines Auth-Systems sieht auch so aus. Token-Endpunkte, Login-Seiten, JWKS. Zustandslos, spitzenlastig, cache-freundlich.
Darunter liegt eine Schicht, die nichts von alledem ist.
Die Zahl ist eins
Unterhalb der Endpunkte betreibt unsere Backplane eine Koordinationsschicht. Zu jedem Zeitpunkt hält genau ein Replica die Cluster-Leadership-Lease (heutzutage ein Blob-Lease, nicht Gossip, aber das ist eine Geschichte für einen anderen Beitrag) und führt die Singleton-Jobs aus: den Retention-Sweep, den Webhook-Zustellungslauf, die Arbeit, bei der zwei gleichzeitige Runner doppelt ausgelöste Nebenwirkungen bedeuten und null Runner bedeuten, dass Dinge stillschweigend nie passieren.
Die Zahl, die diese Schicht braucht, ist eins. Nicht null, wenn es ruhig ist. Nicht N unter Last. Eins, kontinuierlich gehalten, mit einer überprüfbaren Übergabe, wenn der Halter stirbt. Scale-to-Zero kann nicht "eins, immer" sagen. Es kann "mindestens eins, solange Traffic da ist" sagen, was ein anderes Versprechen ist, und der Unterschied zwischen diesen beiden Versprechen ist genau der Fehlermodus, den eine Leader Election verhindern soll.
Deshalb hat uns der Auslastungsgraph angelogen. Ein ruhiger Auth-Cluster tut nicht nichts. Er hält eine Lease, hält die Signierschlüssel warm und steht bereit, die nächste Token-Validierung im einstelligen Millisekundenbereich zu beantworten. Ruhig und untätig sind unterschiedliche Zustände, und Abrechnungs-Dashboards zeigen Ihnen nur einen davon.
Man kann es vortäuschen, und das ist schlimmer
Man kann "genau eins" einer Serverless-Laufzeit aufzwingen. Setzen Sie die minimale Replica-Anzahl auf eins, und Sie haben einen Always-On-Server auf einer Plattform gekauft, deren ganzer Instinkt darin besteht, Ihnen stille Instanzen wegzunehmen. Jedes Skalierungsereignis, jeder von der Plattform ausgelöste Neustart, jeder Revisionswechsel wird zu einer Leadership-Frage, deren Zeitpunkt Sie nicht kontrollieren. Wir würden das Kernverhalten der Laufzeit bekämpfen, um unseres zu bewahren, für immer, und dafür auch noch bezahlen.
Und der Fehler landet bei der schlechtestmöglichen Person. Die Anfrage, die den Cold Start bezahlt, ist ein Mensch, der sich anmelden will. "Ihre Anmeldung war langsam, weil unser Auth-Service geschlafen hat" ist kein Satz, den irgendjemand ausliefern sollte.
Die Rechnung hatte eine langweilige Lösung
Und das Geld, mit dem alles anfing? Das erledigten ein Scheduler und eine SKU. Der Dev-Cluster deallokiert jetzt, wenn ihn niemand benutzt, und der Node-Pool wurde auf eine günstigere SKU umgestellt. Mehr als einen Absatz verdient das nicht, und genau das ist der Punkt: "Nicht mehr für Leerlauf bezahlen" ist ein Ziel, keine Architektur, und der Großteil des Ziels war mit einer Konfigurationsänderung statt einer Re-Plattformierung erreichbar.
Der Formtest
Die Regel, die wir mitgenommen haben: Passen Sie die Laufzeit an die tatsächliche Form der Arbeitslast an, nicht an ihren Traffic-Graphen. Serverless belohnt zustandslos und stoßweise. Es bestraft alles, was eine kontinuierliche, exklusive Rolle innehaben muss, und ein Auth-Kern, der Signierschlüssel schützt und wählt, wer die destruktiven Jobs ausführt, ist das reinste Beispiel für diese zweite Art, das wir kennen.
Wir sind nicht gegen Serverless. Ein Großteil unserer zustandslosen Oberfläche könnte dort problemlos leben. Aber die Schicht, die bis genau eins zählen muss, bleibt auf langweiliger, dauerhaft laufender, inspizierbarer Infrastruktur.
Diese Schicht ist auch genau das, was Sie nicht mehr selbst betreiben, wenn Sie Auth über Authagonal laufen lassen, statt die Backplane selbst zu betreiben.