Pokémon Go-Starterinnerung: Warum „Build to Scale“ genauso wichtig ist wie „Build to Fail“
Einer der Slogans von DevOps und Cloud der letzten, oh, vielen Jahre war „Build to Fail“. Die Prämisse dabei ist, dass zu viele Unternehmen aufgrund von kapazitätsbezogenen Leistungsproblemen kostspielige Ausfallzeiten und Umsatz- (und Produktivitäts-)Einbußen erleiden. Sie sollten Ihre App und Infrastruktur daher so aufbauen, dass sie „ausfallsicher“ sind, um sicherzustellen, dass Sie von derartigen schrecklichen Ereignissen nicht noch einmal heimgesucht werden. Heh. Sehen Sie, was ich da gemacht habe? Ja, ich arbeite alleine in einem Büro. Manchmal muss ich mich amüsieren.
Schlechte Wortspiele beiseite, der jüngste phänomenale Erfolg von Pokémon Go (Sie haben davon gehört, oder?) führte für viele auch zu einer phänomenal frustrierenden Erfahrung. Insbesondere Eltern mit aufgeregten Kindern, die JETZT hinwollten, es aber nicht konnten, weil die Kontoerstellung vorübergehend ausgesetzt und dann aufgrund der überwältigenden Nachfrage streng dosiert wurde.
Manche könnten nun das Angebot von Werner Vogels, CTO von Amazon, dem Unternehmen bei der Bewältigung seiner Kapazitätsprobleme zu helfen, als Hinweis darauf interpretieren, dass das Unternehmen gar nicht erst auf die Cloud umgestiegen sei und dies das zugrunde liegende Problem sei. Dabei wird jedoch vorausgesetzt, dass dies nicht der Fall ist, was mir an diesem Punkt nicht ganz klar ist. Im Ernst: Laut Wikipedia-Updates zum Augmented-Reality-Entwickler verarbeitet dieser „mehr als 200 Millionen Spielaktionen pro Tag, bei denen Menschen mit realen und virtuellen Objekten in der physischen Welt interagieren.“ Ich denke, wir können ihnen in diesem Punkt eine kleine Pause gönnen, oder zumindest diejenigen von uns, die verstehen, was das im Hinblick auf Systeminteraktionen und das Pushen von Paketen bedeutet. In den Updates wurde auf „Serverprobleme“ hingewiesen, aber seien wir ehrlich, wir wissen alle, dass „Server“ im technischen Code „15 verschiedene Komponenten, die über die App- und Netzwerkinfrastruktur verteilt sind“ bedeutet.
Die grundlegende Lehre liegt hier jedenfalls nicht darin, dass die Cloud zwangsläufig besser mit unerwartetem Erfolg umgehen kann. Das kann durchaus sein, aber nicht, weil es die Cloud ist. Dies liegt daran, dass die Cloud nicht nur für Ausfälle , sondern auch für Skalierbarkeit konzipiert ist.
Ich bin nicht in der Lage zu sagen, warum Niantic Labs mit der Nachfrage nicht Schritt halten konnte. Vielleicht lag es an mangelnder Kapazität – in diesem Fall wäre die Cloud eine gute Wahl gewesen –, vielleicht waren die Apps und/oder die Infrastruktur aber nicht skalierbar – in diesem Fall hätte die Cloud möglicherweise überhaupt nicht geholfen. Es geht wirklich nicht darum, sie für das, was sie getan/nicht getan haben, zu ärgern (heh). Der Punkt ist, dass sie ein perfektes Beispiel für die Realität sind, dass Unternehmen in einer Anwendungswelt ebenso darauf bedacht sein sollten, für den Erfolg wie für das Scheitern zu rüsten. Und zwar nicht nur allmählicher Erfolg, sondern sofortiger Erfolg über Nacht, wie bei Pokémon Go.
Denn wenn das passiert, möchten Sie nicht, dass dieser erfolgreiche Misserfolg überall im Internet zu sehen ist.
Eine häufige Ursache für Skalierbarkeitsprobleme sind Datenquellen. Erfahrene Twitter-Benutzer werden sich daran erinnern, dass die Anfangszeit des sozialen Mediums von Problemen mit der Skalierbarkeit der Datenbanken geprägt war. PayPal war einer der ersten und lautstärksten Befürworter von Sharding als Skalierungsstrategie, um die Herausforderung der enormen Benutzeranzahl zu bewältigen. Seitdem wurde die Technik allgemein übernommen und ist auf Datenbanken, Performancedienste und Anwendungen gleichermaßen anwendbar. Als einer der Vorteile des Aufstiegs von NoSQL-Datenquellen wird die größere Skalierbarkeit im Vergleich zu herkömmlichen relationalen Datenbanken angepriesen.
Eine weitere Quelle von Skalierbarkeitsproblemen liegt ausschließlich auf den Schultern der Infrastruktur. Die automatische Skalierung in der Cloud basiert auf der Fähigkeit, nicht nur automatisch mehr Rechenleistung hinzuzufügen, sondern auch die Kapazität des „App-Endpunkts“ zu erhöhen. In jeder Architektur, die zur Erzielung einer Kapazitätssteigerung auf Skalierung angewiesen ist, ist hierfür eine Art Lastausgleichsdienst erforderlich. Wenn die Rechenleistung erhöht wird, muss dies beim Lastenausgleichsdienst registriert werden. Dies bedeutet die Verwendung von APIs und Skripten, Automatisierung und Orchestrierung. Diese Komponenten müssen vorhanden sein, bevor sie benötigt werden. Andernfalls kommt es zu Verzögerungen, wenn die Nachfrage eine Kapazitätssteigerung erfordert.
Die Einbindung eines Lastausgleichsdienstes in jede App-Architektur sollte eine Voraussetzung sein. Ein Lastausgleichsdienst trägt nicht nur der Notwendigkeit des „Build to Failover“ Rechnung, da er ein Failover zwischen zwei Anwendungsinstanzen unterstützt, sondern unterstützt auch die für den Erfolg notwendige „Build to Scale“. Aber denken Sie nicht, dass es dabei lediglich darum geht, einer App (oder einem Mikroservice, wenn Sie das bevorzugen) einen Lastausgleichsdienst vorzuhängen. Für den Betrieb ist es wichtig, die Automatisierung (Skripte) und Orchestrierung (Prozesse) einzurichten, die eine automatische Skalierung ermöglichen, um dieser Nachfrage gerecht zu werden, wenn sie eintritt. Heutzutage geht es bei der Skalierung um die Architektur, nicht um Algorithmen , und es ist wichtig, diese Architektur von Anfang an zu berücksichtigen, bevor die Architekturschulden so restriktiv werden, dass Sie mit dem, was Sie haben, feststecken.
Ehrlich gesagt hat Niantic Labs gute Arbeit geleistet und für den Misserfolg gesorgt. Auf Kapazitätsausfälle reagierte man mit freundlichen Nachrichten und nicht mit den standardmäßigen HTTP-Statuscodeseiten, die ich oft antreffe. Sie waren humorvoll und für Kinder leicht zu lesen und zu verstehen (ich weiß das, weil mein 8-Jähriger sie uns alle 20 Minuten vorgelesen hat). Womit sie jedoch nicht gerechnet hatten, war der vielleicht unerwartete Erfolg, der ihnen zuteil wurde. Das ist für alle eine gute Erinnerung daran, dass maßstabsgetreues Bauen genauso wichtig ist wie das Bauen auf ein Scheitern.
Denn wenn Sie das nicht tun, gewinnt Team Rocket.