Llegamos a ustedes gracias a:



Reportajes y análisis

Son las 10 p.m. – ¿sabe qué están haciendo sus API?

[06/06/2016] Casi todas las compañías hoy en día están usando, al menos, algunos servicios de nube, y no solo están usando aplicaciones empaquetadas de software como servicio (SaaS, por sus siglas en inglés), servicios de plataforma como servicio (PaaS, por sus siglas en ingles) y máquinas virtuales de infraestructura como servicio (IaaS, por sus siglas en inglés). Se construyen sitios web y aplicaciones personalizadas usando application programming interfaces (API) para todo, desde el trazado de mapas hasta la mensajería, analítica, detección de fraudes y reconocimiento de voz.

Los productos SaaS ofrecen con frecuencia API que permiten trabajar con ellos a través de aplicaciones externas y servicios, o incluso le permiten construir los suyos propios. Por ejemplo, más del 50% del tráfico -y las ganancias- de Salesforce vienen a través de sus API, en lugar de hacerlo directamente de su propio servicio web. Para eBay es el 60%, y para Expedia el 90%. Si usa Twilio para mandar mensajes de texto para soporte al cliente o servicios de detección de fraude de MasterCard, está apoyándose en esas API para sus propios procesos clave de negocio. ¿Cómo las mide y monitorea para averiguar que está recibiendo un nivel aceptable de servicio?

Solo porque está usando un servicio de nube no puede asumir que éste tiene un buen desempeño. Los cortes de servicio son muy ocasionales y puede usar la georedundancia para asegurarse de que su aplicación de nube pase a otra región si el servicio en otra región sufre un corte. Sin embargo, aunque los SLA con los proveedores de sistemas alojados cubren el tiempo de actividad, rara vez mencionan la latencia. Demasiada latencia y sus llamadas a las API expirarán, generando una pobre experiencia para sus usuarios y clientes.

Microsoft se encontró con un problema como ese cuando empezó a mover su buscador Bing a un despliegue continuo y empezó a medir algunas dependencias externas por primera vez, afirma Craig Miller, consejero técnico de Microsoft. "Encontramos servicios que estábamos usando donde no nos dábamos cuenta que el nivel de confiabilidad no era mayor a tres nueves, señala.

Usted podría no saber ni cuántas API y aplicaciones SaaS se encuentran en uso en su compañía, ahora que muchas unidades de negocio están comprando sus propios servicios de nube, así que podría querer empezar a usar herramientas que le dicen qué está activo en su red. Tales productos incluyen a Azure Cloud App Discovery de Microsoft o Skyfence de Imperva. Esto es particularmente importante si es que tiene servicios que heredó de un predecesor o que adquirió en una fusión -necesita saber de qué se está haciendo cargo.

Pero una vez que lo sepa, necesita hacer más que mantener vigiladas las alertas de estado para los servicios y las API en las que se está apoyando; y no puede asumir que los SLA van a cubrir todos los problemas.

Poder ver una cantidad de mediciones y análisis le da una vista más clara del rendimiento de una API.
API

Los portales de las API -que pueden ser servicios de nube como Amazon API Gateway, Apigee API Gateway, el administrador Mashery API de Tibco y el sistema Azure API Management de Microsoft, o los administradores de API internos como aquellos disponibles en Akana, Layer7 y 3scale- le permiten controlar el acceso a las API y administrar los recursos de acuerdo a políticas, medir los clientes límite y ver la analítica del uso. Algunos, como Azure API Management, funcionan como substitutos que le permiten controlar el uso interno de las API externas. Pero, principalmente, se ocupan de empaquetar y ofrecer sus propias API y servicios web, ayudándole a escalarlas, monitorearlas y distribuirlas. Eso no ayuda mucho cuando se trata de entender las API externas y los microservicios que probablemente está usando, con frecuencia sin medirlos. Y si usa un mix de API internas y públicas, también querrá pensar en monitorearlas explícitamente.

Inactividad y locación

La pregunta, de acuerdo a David O'Neill, CEO de APImetrics, servicio de analítica de API, es, "¿Quién le informa sobre los problemas causados por las API? ¿Su equipo de desarrollo y operaciones, o sus clientes? ¿Sabe lo que está haciendo su infraestructura por sus clientes de extremo a extremo? Probablemente no, y si usted supiera se horrorizaría.

Trabajar con API es más complejo de lo que muchas personas entienden, sostiene O'Neill. "Existen algunas cosas realmente extrañas que la industria recién empieza a notar, y que las personas deben considerar, señala. "Hemos creado un nuevo mundo de aplicaciones web y servicios donde las compañías no tienen idea de lo que están pagando, si es que funcionan y qué es lo que en realidad están haciendo. La gente confía en los SLA, pero tienen SLA que no cuentan las mediciones correctas. Los SLA hablan del tiempo de actividad; no hablan de la latencia o la capacidad de respuesta.

No debe solo buscar en sus propios logs, sus propias pruebas, para ver qué tan responsivas son sus API, porque los problemas podrían no ser visibles ahí -solo le dicen qué rendimiento verá cuando acceda a la API desde su red. Ni siquiera puede usar una locación de nube desde la cual realizar las pruebas. Por ejemplo, "si usted llama a la API Foursquare desde la región Azure en Virginia, la llamada fallará o podría tomar hasta 20 minutos para ser respondida, afirma O'Neill. "Pero es solo desde Azure en Virginia; desde Azure en California funciona bien.

"Los valores atípicos son ítems que, efectivamente, se han salido tan lejos de los parámetros estadísticos que no tiene sentido pretender que funcionaron", afirma el CEO de APImetrics, David ONeill.
API

Los logs y las mediciones simples no le dirán todo y, ciertamente, no puede confiar en lecturas de latencia promedio. Si la latencia promedio que está viendo es, digamos, 250 milisegundos, debe verificar si esto incluye respuestas inusualmente rápidas que enmascaran a las que toman de 5 a 10 segundos. Recuerde pensar en la escala de las llamadas de API: Si solo hace mil llamadas, un 99,6% de éxito significa que solo hay cuatro fallas, y ese nivel de desempeño probablemente no causará problemas. Pero si hace un millón de llamadas, serían cuatro mil fallas. Y cuando usa API múltiples desde servicios diferentes, también tiene que considerar la latencia entre ellas.

Se vuelve peor cuando tiene clientes internacionales. "Si está midiendo el desempeño en su servidor, ¿cómo va a medir eso para sus clientes en Japón? No puede enlazar todo a AWS en Virginia y operar un servicio global, pero muchas compañías lo hacen, advierte O'Neill. "Tiene que verlo de extremo a extremo. Si tiene clientes japoneses y se encuentra en el centro de datos de la Costa Este de AWS, va a haber latencia porque la velocidad con la que pueden rutear una consulta depende de la velocidad de luz. Y si tiene tres llamadas de API detrás de la API pública, y cada una de ellas necesita un salto transatlántico, eso podría estar añadiendo bastante latencia. No verá eso en su servidor -y su cliente no experimentará lo que usted hace.

También tiene que ver la manera en qué trata a las llamadas de API una vez que la respuesta llega a su red. "La gente asume que las API son solo páginas web; no lo son, explica O'Neill. "Solo porque es una llamada HTTP no significa que funciona o puede ser tratada como una llamada web.

El proveedor de energía de Reino Unido First Utility estaba usando un conjunto de herramientas de pruebas y monitoreo para administrar las API que usa para la creación de aplicaciones para iOS y Android que usan sus clientes con el fin de monitorear su uso de energía en tiempo real con medidores inteligentes, así como los servicios de cuentas de los clientes en su sitio web. Pero cuando First Utility probó el servicio de APImetrics, descubrió rápidamente que su arquitectura interna no trataba de igual manera a las llamadas de API que al tráfico web y, de hecho, las sofocaba, afectando la experiencia que los usuarios recibían. Otro cliente de APImetrics encontró que, aunque el tráfico web iba a través de su bus de servicio exactamente como se esperaba, las llamadas de API que iban a través del mismo bus experimentaban demoras significativas.

En otro caso, los problemas que parecieron ser causados por una API se resumían a un software de loggin de red al que se le estaba acabando el espacio en el disco una vez por semana: Cada martes en la tarde, mientras estaba en modalidad de mantenimiento y borrando logs para hacer espacio, todas las llamadas de API que estaban en proceso de loggin estaban atascadas en una cola de tareas. Eso generaba muchas quejas por parte de los clientes, pero cuando los ingenieros revisaban el servicio la mañana siguiente, la API y el sistema que le hizo la llamada funcionaban normalmente.

La seguridad de la red -como la inspección profunda de paquetes- también podría afectar la forma en que la red maneja las llamadas de API y las respuestas.

"Se trata de adoptar un enfoque de adentro hacia afuera, indica O'Neill. Hasta que no se concentre en la experiencia de un extremo a otro, no sabrá cómo están funcionando las API con las aplicaciones que crea para sus propios usuarios o para sus clientes.

¿Es lento o es inusualmente lento?

No todas las nubes son iguales. De acuerdo a mediciones que APImetrics ha hecho hace unos años, si está usando ruteo DNS dentro de Azure, experimentará un rendimiento peor. "Lo que toma 10 milisegundos en cluster de AWS, toma 60 milisegundos en un cluster de Azure, afirma O'Neill. "Sin embargo, cuando cambia al uso de direcciones IP, la velocidad de Azure es la misma que la de AWS.

Los desarrolladores que usan API necesitan considerar estos temas y empezar a escoger entre diferentes API y servicios de nube basados en la capacidad de respuesta, así como en el costo de la funcionalidad. Y operaciones deberá monitorear la capacidad de respuesta de las API con el paso del tiempo. Eso no está pasando hoy necesariamente, afirma O'Neill, "porque es difícil de medir y uno debe pensar en la procedencia de sus mediciones, así como en el qué y el cómo. No está siendo medido, y se está escondiendo bajo la alfombra.

El puntaje Insight de APImetrics funciona como un puntaje de crédito para una API, dándole una vista rápida de su rendimiento y variabilidad.
API

Para que eso cambie y para hacer que la administración de desarrollo de API sea más común, los líderes de negocios tendrán que empezar a preocuparse por esas preguntas. "Todo se trata de trasladar el monitoreo del rendimiento y la detección de problemas fuera de DevOps y ponerlos en manos de los administradores de negocios y dueños, a donde pertenece en realidad, argumenta O'Neill. "Los equipos de cara a los clientes y que generan ingresos serán los responsables de esto, y ellos van ser quienes tomen las decisiones.

Para atender a la audiencia, APImetrics está creando métricas que están diseñadas para ser mejor comprendidas por parte de los líderes de negocios que no son expertos en networking. Uno de los enfoques es un número que indica la confiabilidad de una API. O'Neill lo compara a un puntaje de crédito. "Una API podría ser lenta pero consistentemente lenta. Usted tiene que preocuparse de la variación en relación a lo que espera en lugar de preocuparse por la velocidad, explica. "Si el 5% del tiempo es demasiado lenta para ser usada, entonces ese es el problema.

Otro ejercicio útil es mirar los valores atípicos: ¿Cuántas llamadas han sido excepcionalmente malas?

"Lo que necesita saber no es si la API está funcionando, sino si está funcionando lo suficientemente bien como para servir a sus clientes. Parece que fuera lo mismo, pero son cosas sutilmente diferentes, advierte O'Neill."Necesita poder ver qué es estadísticamente normal y cuándo es que no lo puede ver. Puede que no le guste lo que es normal para su API, pero ese es un problema diferente.