API Management: ¿Otra vez SOA?

“API Management es el modelado y gestión del conjunto de operaciones provistas por cada área funcional que sirve como facilitador de nuevos productos y/o servicios de negocio.” He aquí mi definición; una más entre varias.

La intención de este artículo es presentarles, a mi modo de ver, cuáles son los principales desafíos para adoptar un ecosistema de API dentro de un organización, desde un área de Arquitectura.

Desafío 1:

Hablemos todos el mismo idioma

API es el tema de moda: todos hablan de API, todos quieren API; pero lo que cada uno entiende por API es muy dispar.

Las API son servicios expuestos, los cuales cumplen con ciertas características que los diferencian del resto. Las API son:

• Fácilmente consumibles: promueven la autogestión de los consumidores.
• Recursos y operaciones definidas por el negocio: deben generar valor de negocio, permitir a terceros crear productos y servicios.
• Técnicamente más simples (no más SOAP).
• Comercializadas como productos (permite posicionar nuestra imagen).

Para que una API tenga éxito en una organización es condición necesaria que sea un concepto entendido por todos los stakeholders y gobernado por el negocio. Lo peor que puede pasar es que lo veamos simplemente como una solución IT.

Desafío 2:

Seguridad, la dicotomía entre lo simple y lo confiable

Cuando exponemos un servicio, tenemos el reflejo de aplicar nuestras prácticas habituales de seguridad. Aunque parezca simplemente un tema técnico, la seguridad es un claro ejemplo de cómo una definición aislada del contexto puede afectar directamente el éxito de nuestra API.

Acá se plantea un trade-off entre confiabilidad y simplicidad. Por ejemplo, si para utilizar nuestro servicio un cliente requiere indicarnos cuál es su IP de origen, contar un un certificado instalado, encriptar los mensajes, etc., vamos estar en un entorno confiable. Sin embargo, esto atenta directamente contra la simplicidad y la autogestión. Como nuestras API son un producto, ellas compiten directamente contra otras APIS; y nuestros clientes siempre tenderán a utilizar la API más simple.

En este escollo es donde OAuth 2 entra como anillo al dedo, permitiendo crear una aplicación que consuma recursos de otra aplicación, sin contar en ningún momento con las credenciales del usuario final. El protocolo basa su confiabilidad en SSL y generalmente funciona con un enrolment autogestionado.

Desafío 3:

SOA, no tropecemos con la misma piedra

“¿Pero esto de API no es lo que me dijeron hace 5 años con SOA?”, se escucha en los pasillos.

Cuando comenzamos a analizar la evolución de la implementación de SOA dentro de una organización, suele repetirse el mismo patrón:

• Nace ante la crisis, por la proliferación de integraciones ad-hoc entre diferentes servicios.
• Aparece un gobierno para estos servicios, pero con una mirada puramente IT.
• El origen de un nuevo servicio se basa en la demanda de un sistema que necesita consumir información de otro sistema.
• Tiende a existir una cantidad desproporcionada de servicios que no respetan una taxonomía clara, con un reuso bajo o nulo.

Con eso no estoy diciendo que las implementaciones de SOA fracasaron, sino que el objetivo es otro. Más allá de que existe el concepto de API interna, me gusta verlo como una evolución de SOA. Podemos seguir utilizando y evolucionando nuestro modelo SOA para las integraciones internas y comenzar un desarrollo de API para atender la demanda externa. En este esquema bimodal, las API deberían cumplir con las siguientes características:

• Deben ser creadas antes de la demanda concreta. El proceso de generación debe ser lanzado por los proveedores, no por los consumidores.
• Las operaciones tienen que ser pocas, concretas, de uso general y estar enmarcadas en una taxonomía clara.
• Deben ser gobernadas por el negocio, siendo IT el soporte. Caso contrario, si nuestra organización cuenta con una implementación SOA con un gobierno con tinte técnico, corremos el riesgo de caer en las mismas prácticas y problemas, así como en la comparación de que SOA es lo mismo que API.

Desafío 4:

KPIs: medir, siempre medir

De más está decir sobre la importancia de medir para poder mejorar. Y API, no es la excepción. Para ello, debemos definir quiénes son los stakeholders que intervienen en el ciclo de vida de API. Cada uno de ellos estará interesado en ciertos indicadores.

Más allá de las decisiones en base a los indicadores que cada área puede tomar, es importante (como en cualquier producto), entender el ciclo de vida de los clientes para poder definir qué medir e interpretar cada uno de los indicadores.

• Adquisición: ¿Cómo llegan nuestros clientes a conocer las APIs?: Tráfico del portal, origen de los visitantes
• Activación: ¿Tienen los desarrolladores una buena primer experiencia?: Desarrolladores registrados, API Keys solicitadas
• Retención: ¿Los developers vuelven a utilizar la API?: API calls por desarrolladores, número de App registradas
• Ingresos: ¿Cómo nos beneficiamos mutuamente?: $ por desarrollador, $ por aplicación
• Referencia: ¿Cómo los desarrolladores les cuentan a otros desarrolladores sobre la API?: referencias de desarrolladores, tasa de crecimiento de desarrolladores/aplicaciones.

Desafío 5:

API Manager: no pongamos el carro delante del caballo

Un error muy común es pensar que API es un producto. A la hora de decidir ir hacia un modelo de API caemos en la tentación de creer que un API Manager es la “bala de plata”. Sin haber resuelto antes cada uno de los desafíos planteados en esta nota (junto con un modelo de negocio que amerite una implementación de API), no tiene sentido comenzar a analizar ningún producto.

Una vez sorteado lo anterior, existen el el mercado muchísimas alternativas, cada una con su sabor. Algunas más integrales a todas las necesidades de API, y otras más específicas. Por ejemplo, podríamos implementar API completamente usando un API Manager como API Connect o TyK; o podríamos construir una solución Adhoc utilizando, por ejemplo, Spring Boot junto con Swagger.

Portal: nos permite mostrarle al mundo nuestra API.

SDK/Sandbox: nos permite dar feedback instantáneo a los desarrolladores sobre el uso de la API.

API Gateway: nos permite exponer servicios y enrutarlos con diferentes sistemas. También posibilita homogeneizar los mensajes.

Seguridad: nos permite securizar las API expuestas (por ejemplo, agregarle API keys y Oauth2, o definir cuotas de uso).

Analytics: nos permite obtener indicadores de la parte operacional de las API.

Ciclo de vida: nos permite versionar nuestras APIs, deprecar operaciones, y lanzar pruebas a un conjunto de usuarios limitados.

Monetización: Nos permite montar un modelo de negocio de ingresos directos por el uso de las API.

Desafío final:

El negocio es nuestro aliado inevitable

Podemos alinear a toda la organización, definir el esquema de seguridad más flexible, tener los mejores indicadores, elegir el API Manager más renombrado…y aún así, fracasar.

Las API permiten generar modelos de negocio incorporando a nuestra organización otros aliados estratégicos. Estamos definiendo un nuevo producto, que requiere la identificación de todos los stakeholders involucrados.

Quienes formamos parte de las áreas de Arquitectura debemos brindar el soporte necesario para armar la infraestructura que se precisa, y ser facilitadores de API. Pero por favor, no intentemos ser el gobierno de API. Entendamos que se trata de un concepto del negocio y no de una nueva moda de los arquitectos. API es el medio y no el fin.