El nuevo AAA: API, autenticación y disponibilidad

Quizás hayas descubierto que sí, soy una de esas personas que juegan Pokémon Go. O, como suele suceder últimamente, no jugar Pokémon Go. Eso es malo, porque también significa que nuestro hijo menor no está jugando, porque resulta que ambos usamos cuentas del Pokémon Trainer Club (PTC) para jugar, no cuentas de Google, y no podemos ingresar.

Eso es significativo, porque mientras los dos estamos frustrados por nuestra incapacidad de “autenticarnos” e iniciar sesión para jugar, mi esposo eligió usar su cuenta de Google y, bueno, no está teniendo los mismos problemas.

Esto me llevó a analizar algunas cuestiones técnicas que realmente deberían resonar en todas las empresas, independientemente de la aplicación que estén lanzando. Esa preocupación gira en torno a la nueva AAA: API, autenticación y disponibilidad.

Curiosamente, esta búsqueda comenzó cuando estaba leyendo un artículo en Forbes sobre el seguimiento de Pokémon en Pokémon Go. Sí, Forbes. Es así de grande. En cualquier caso, eso dio lugar a otro artículo y otro, y uno de ellos especulaba que el motivo por el cual el seguimiento estaba roto (al menos inicialmente) se debía a una actualización del juego en la que, por error, se omitió una clave API de las llamadas de seguimiento a los servidores de Niantic.

Sea este el caso o no, un paso en falso de este tipo, de hecho, rompería las API. Pero lo que seguía pensando era que si no podía iniciar sesión en mi cuenta de PTC y jugar, ¿por qué podía cambiar a mi cuenta de Google y entrar de forma tan fácil y sencilla?

La conexión de autenticación API

Bueno, eso me hizo buscar en Github y explorar las API de Pokémon Go (prefiero Java , pero Python también existe, vuélvete loco) y eso finalmente hizo que se encendiera la luz "ajá". Mira, casi todas las llamadas API en esos repositorios manejan la misma excepción: LoginFailedException . 

En otras palabras, incluso una simple llamada para encontrar Pokémon cercanos puede resultar en una LoginFailedException .

Lo cual en realidad no es tan sorprendente. Mira, las aplicações web monolíticas a menudo rastrean a los usuarios autenticados a través de sesiones, lo que a menudo significa una cookie que contiene un ID de sesión o algún otro token que la aplicação verifica antes de hacer cualquier otra cosa (esa es una arquitectura con estado , para aquellos que siguen). Las API no son tan diferentes, en el sentido de que cada llamada API debe tener una forma de garantizar que la aplicação que realiza la llamada (el usuario) esté realmente autorizada para realizar la llamada en primer lugar. Tienen que estar “logueados”.

Actualmente, las API suelen utilizar claves API para lograr esto. Generalmente, la clave se compara con un perfil de usuario para garantizar que la llamada esté autorizada. Cada llamada (en una arquitectura sin estado ). Hay varias razones para tal decisión, incluida la posibilidad de limitar la velocidad de las llamadas. Lo cual es una gran cosa. Estado de las API 2016 de Apigee El informe señaló que el 68% de las API aprovechaban la gestión de cuotas (que también se conoce como limitación de velocidad, medición, etc.). Para realizar ese truco técnico, primero hay que saber cuántas llamadas se han realizado en el último minuto/hora/día y, por lo tanto, se debe rastrear en algún lugar seguro (para que los usuarios no puedan manipularlo y engañar a la aplicação para que permita más llamadas por período de tiempo).

En otras palabras, las API pueden resultar muy exigentes para la infraestructura de autenticación porque tienen que verificar el estado, la autorización y, potencialmente, aplicar limitaciones de velocidad. Eso es mucho trabajo.

Sin embargo, nuestra mentalidad de arquitectura de aplicaciones, a menudo todavía tradicional, no tiene en cuenta el impacto de esas llamadas adicionales en la capacidad. Esas llamadas adicionales para verificar y autorizar, incluso si se realizan periódicamente para “refrescar” una sesión, supondrán una presión considerable sobre la infraestructura de autenticación. La misma infraestructura de autenticación que respalda el inicio de sesión. Es el mismo tipo de estrés que vimos cuando las limitaciones del navegador en las conexiones por usuario aumentaron de 2 a 8. Un solo usuario ahora consumía ocho veces más recursos para acceder a una aplicação. De manera similar, al considerar las necesidades de capacidad de una aplicación que depende de la autorización por llamada a API, hay que hacer algunos cálculos y determinar cuántas X más consumirá ese usuario individual.

No hacerlo da como resultado, bueno, niños de 8 años enojados (y Loris enojado, también, de hecho) cuando los servicios de inicio de sesión sobrecargados son lo que se interpone entre ellos y ese Pikachu que desesperadamente quieren atrapar.

Identificación de escalamiento y un factor crítico para la disponibilidad

La identidad y el acceso son servicios de aplicaciones fundamentales . Hemos visto aumentar su importancia en nuestras encuestas sobre el estado de la entrega de aplicação durante los últimos dos años y, sin revelar demasiado, ya estamos viendo aumentos en nuestros datos de 2017 tanto para la federación de identidad como para el control de acceso a aplicação . Y no es sólo por las aplicaciones, es también por las cosas y la creciente necesidad de escalar toda la gama de infraestructura de servicios de identidad para soportar más cosas, más usuarios, más aplicaciones que usan API para interactuar con aplicações back-end.

La disponibilidad a menudo se basa únicamente en una medida de tiempo de inactividad. Si los servidores estuvieran en funcionamiento correctamente, estarían disponibles. Es una perspectiva de adentro hacia afuera. Pero, al igual que con la seguridad, necesitamos dar vuelta esa medición y verla desde afuera hacia adentro. La capacidad cuenta, y simplemente estar “activo” y “disponible” no es suficiente. Los servicios deben estar “activos” y “disponibles” para todos aquellos que quieran consumirlos. Eso significa escalar tan rápido como sus scripts de Python puedan ejecutarse.

También significa comprender la relación entre los diversos servicios back-end que realmente implementan la funcionalidad presentada por sus API. Los servicios de identidad y acceso son tan críticos para la disponibilidad como la propia aplicação . La disponibilidad, al igual que la seguridad, es tan buena como su eslabón más débil. Y si sus servicios de identidad no son tan escalables (o más escalables si su modelo es autenticación por llamada API) como el resto de su aplicação, encontrará que la disponibilidad es un problema importante, incluso si todos sus paneles de control están en verde por dentro.

Porque desde fuera vemos “rojo”. Literal y figurativamente.