Die neue AAA: APIs, Authentifizierung und Verfügbarkeit
Sie haben vielleicht schon herausgefunden, dass ich tatsächlich einer dieser Leute bin, die Pokémon Go spielen. Oder, wie es in letzter Zeit oft der Fall ist, nicht Pokémon Go spielen. Das ist schlecht, denn es bedeutet auch, dass unser Jüngster nicht spielt, weil wir beide zum Spielen Pokémon Trainer Club (PTC)-Konten und keine Google-Konten verwenden und uns deshalb nicht anmelden können.
Das ist bedeutsam, denn während wir beide darüber frustriert sind, dass wir uns nicht „authentifizieren“ und zum Spielen anmelden können, hat mein Mann beschlossen, sein Google-Konto zu verwenden und, nun ja, er hat nicht dieselben Probleme.
Das brachte mich dazu, mich mit einigen technischen Problemen zu befassen, die eigentlich jedes Unternehmen beschäftigen sollten, unabhängig von der App, die es auf den Markt bringt. Diese Sorge dreht sich um die neuen AAA – APIs, Authentifizierung und Verfügbarkeit.
Interessanterweise begann diese Suche, als ich in Forbes einen Artikel über das Verfolgen von Pokémon in Pokémon Go las . Ja, Forbes. So groß ist es. Auf jeden Fall führte dies zu einem weiteren Artikel und noch einem weiteren, wobei einer davon spekuliert wurde, dass der Grund für die (zumindest anfängliche) Störung des Trackings ein Spiel-Update war, bei dem versehentlich ein API-Schlüssel aus den Tracking-Aufrufen an die Server von Niantic weggelassen wurde.
Unabhängig davon, ob dies der Fall ist oder nicht, würde ein solcher Fauxpas tatsächlich zum Zusammenbruch der APIs führen. Aber ich kam immer wieder auf die Frage zurück: Wenn ich mich nicht bei meinem PTC-Konto anmelden und spielen konnte, warum konnte ich dann zu meinem Google-Konto wechseln und mich ganz einfach anmelden?
Die API-Authentifizierungsverbindung
Nun, das brachte mich dazu, auf GitHub herumzustöbern und in den Pokémon Go-APIs zu stöbern (ich bevorzuge Java , aber es gibt auch Python , tob dich aus) und da ging mir endlich das Aha-Licht an. Sehen Sie, fast jeder API-Aufruf in diesen Repositories behandelt dieselbe Ausnahme: LoginFailedException .
Mit anderen Worten, selbst ein einfacher Aufruf, in der Nähe befindliche Pokémon zu finden, kann zu einer LoginFailedException führen.
Was wirklich nicht allzu überraschend ist. Sehen Sie, monolithische Webanwendungen verfolgen authentifizierte Benutzer häufig über Sitzungen, was oft ein Cookie bedeutet, das eine Sitzungs-ID oder ein anderes Token enthält, das die Anwendung überprüft, bevor sie tatsächlich etwas anderes tut (das ist eine zustandsbehaftete Architektur, für diejenigen, die es mitverfolgen können). Bei APIs unterscheidet es sich nicht groß. Bei jedem API-Aufruf muss sichergestellt werden, dass die aufrufende Anwendung (der Benutzer) überhaupt berechtigt ist, den Aufruf zu tätigen. Sie müssen „eingeloggt“ sein.
Heutzutage verwenden APIs häufig API-Schlüssel, um dies zu erreichen. Der Schlüssel wird im Allgemeinen anhand eines Benutzerprofils überprüft, um sicherzustellen, dass der Anruf autorisiert ist. Jeder Anruf (in einer zustandslosen Architektur). Es gibt verschiedene Gründe für eine solche Entscheidung, unter anderem die Möglichkeit, die Anrufrate zu begrenzen. Und das ist eine große Sache. Apigees Stand der APIs 2016 Der Bericht stellte fest, dass 68 % der APIs die Kontingentverwaltung (auch bekannt als Ratenbegrenzung, Messung usw.) nutzten. Um diesen technischen Trick anzuwenden, muss man zunächst wissen, wie viele Anrufe in der letzten Minute/Stunde/am letzten Tag getätigt wurden, und diese Zahl muss daher an einem sicheren Ort nachverfolgt werden (damit Benutzer die Zahl nicht manipulieren und die Anwendung dazu bringen können, mehr Anrufe pro Zeitraum zuzulassen).
Mit anderen Worten: APIs können eine große Belastung für die Authentifizierungsinfrastruktur darstellen, da sie Status und Autorisierung überprüfen und möglicherweise eine Ratenbegrenzung anwenden müssen. Das ist eine Menge Arbeit.
Doch unsere oft noch traditionelle Denkweise in der App-Architektur berücksichtigt nicht die Auswirkungen dieser zusätzlichen Aufrufe auf die Kapazität. Diese zusätzlichen Aufrufe zur Überprüfung und Autorisierung belasten die Authentifizierungsinfrastruktur erheblich, selbst wenn sie in regelmäßigen Abständen erfolgen, um eine Sitzung zu „aktualisieren“. Dieselbe Authentifizierungsinfrastruktur, die die Anmeldung unterstützt. Es handelt sich um dieselbe Art von Stress, die wir erlebten, als die Browserbeschränkungen für Verbindungen pro Benutzer von 2 auf 8 erhöht wurden. Ein einzelner Benutzer verbrauchte nun das Achtfache an Ressourcen, um auf eine Anwendung zuzugreifen. Ähnlich verhält es sich mit der Kapazitätsanforderung für eine App, die auf Autorisierung pro API-Aufruf angewiesen ist. Hier muss man ein wenig rechnen und herausfinden, wie viele Xs mehr der einzelne Benutzer verbrauchen wird.
Wenn dies nicht gelingt, sind die 8-Jährigen wütend (und Loris übrigens auch), wenn überlastete Anmeldedienste zwischen ihnen und dem Pikachu stehen, das sie unbedingt fangen möchten.
Skalierungs-ID und A sind entscheidend für die Verfügbarkeit
Identität und Zugriff sind kritische App-Dienste . Wir haben in unseren Umfragen zum Stand der Anwendungsbereitstellung in den vergangenen zwei Jahren eine zunehmende Bedeutung dieser Technologien beobachtet und – ohne zu viel zu verraten – können wir in unseren Daten für 2017 bereits Zuwächse sowohl bei der Identitätsföderation als auch bei der Anwendungszugriffskontrolle feststellen. Und der Grund hierfür liegt nicht nur in den Apps, sondern auch in den Dingen sowie in der wachsenden Notwendigkeit, die gesamte Bandbreite der Identitätsdienste-Infrastruktur zu skalieren, um mehr Dinge, mehr Benutzer und mehr Apps zu unterstützen, die APIs zur Interaktion mit Back-End-Anwendungen verwenden.
Die Verfügbarkeit basiert häufig ausschließlich auf der Messung der Ausfallzeit. Wenn die Server aktiv waren und ordnungsgemäß funktionierten, sind sie verfügbar. Es ist eine Inside-Out-Perspektive. Doch wie bei der Sicherheit müssen wir diese Messung umdrehen und sie von außen nach innen betrachten. Auf die Kapazität kommt es an. Es reicht nicht aus, einfach nur aktiv und verfügbar zu sein. Die Dienste müssen für jeden, der sie nutzen möchte, „aktiv“ und „verfügbar“ sein. Das bedeutet, die Skalierung erfolgt so schnell, wie Ihre Python-Skripte ausgeführt werden können.
Es bedeutet auch, die Beziehung zwischen den verschiedenen Back-End-Diensten zu verstehen, die die von Ihren APIs bereitgestellte Funktionalität tatsächlich implementieren. Identitäts- und Zugriffsdienste sind für die Verfügbarkeit ebenso wichtig wie die eigentliche Anwendung selbst. Verfügbarkeit ist, wie Sicherheit, nur so gut wie ihr schwächstes Glied. Und wenn Ihre Identitätsdienste nicht so skalierbar sind (oder besser skalierbar, wenn Ihr Modell auf einer Authentifizierung pro API-Aufruf basiert) wie der Rest Ihrer Anwendung, werden Sie feststellen, dass die Verfügbarkeit ein erhebliches Problem darstellt, selbst wenn auf all Ihren Dashboards „grün“ steht.
Denn von außen sehen wir „rot“. Wörtlich und im übertragenen Sinne.