Tres mandamientos que deberían impulsar toda estrategia API

A principios de los 2000, empresas como Amazon, eBay y Salesforce impulsaron una tendencia hacia la estandarización de interfaces entre aplicaciones web. El resultado fue una revisión completa de cómo se desarrollaron e integraron las aplicaciones, gracias a una red cada vez mayor de API web abiertas que cualquiera podía consumir.

Durante este período, el fundador de Amazon, Jeff Bezos, escribió un memorando a sus empleados que llegó a conocerse como el ‘Mandato API de Bezos’. Según varias fuentes, este incluía dos requisitos estratégicos que cualquier líder de TI debería considerar cuando busca maximizar el valor de los esfuerzos de sus equipos de desarrollo. La primera es que todas las interfaces entre el software desarrollado por cualquier equipo deben realizarse a través de API. La segunda, que los equipos deben escribir API internas como si fueran a ser consumidas por personas ajenas a la organización.

Este enfoque explica en gran medida cómo Amazon pudo externalizar su infraestructura informática: primero a Merchant.com, la plataforma de ecommerce como servicio de la compañía, para que los minoristas crearan sus propias tiendas, y luego a AWS, con una oferta más amplia que ha cobrado vida propia.

Si avanzamos hasta 2023, los líderes de TI han extraído muchas más lecciones sobre el desarrollo y uso efectivo de API durante las dos últimas décadas. Gran parte de lo aprendido está catalogado por MACH Alliance, un consorcio global de casi 100 proveedores de tecnología que promueve “ecosistemas tecnológicas empresariales abiertos y mejores en su tipo”, con especial énfasis en microservicios y API. Aquí, los miembros ofrecen los siguientes tres mandamientos que deberían sustentar cualquier estrategia API. Estos principios no solo garantizan que los sistemas de software funcionen bien juntos, sino también que los equipos trabajen juntos al servicio de la estrategia general de desarrollo de software de la organización. Después de todo, e igual que ocurre con las API, cuando un grupo de personas proporciona un servicio a otros grupos, las promesas deben ser claras y los límites deben respetarse.

1 Adopte un enfoque centrado en las API

La forma más eficaz de maximizar su estrategia de API es adoptar lo que se conoce como un enfoque ‘API first’, en el que las prioriza como los componentes básicos de la estrategia de desarrollo de software desde cero. Las organizaciones que adoptan este enfoque se centran más en la interconexión que en la integración. Primero definen las API, incluido el servicio que realizan, las entradas que reciben y las salidas que producen, antes de escribir cualquier otro código. De esta manera, en lugar de integrar varios componentes de software para crear una aplicación monolítica, utilizan servicios en componentes que se ponen a disposición de un ecosistema a través de sus API. Las organizaciones que no utilizan un enfoque de API primero desarrollan su software antes de diseñar sus API, lo que limita su utilidad, dice Casper Rasmussen, vicepresidente senior global de tecnología de Valtech y presidente de MACH Alliance.

“En primer lugar, API consiste en diseñar interfaces que sean versátiles, en lugar de específicas para un caso de uso particular”, afirma Rasmussen. “Si ha incorporado API a su software heredado existente, no es 'API first', al menos no históricamente. El software heredado conlleva suposiciones sobre qué hace, para quién y en qué caso de uso. "API first' es mucho más versátil, mucho más genérico. Piense, por ejemplo, en una estrategia API que asume que el consumidor será un cliente web. Comunica HTML, lo que dificulta su uso en otros entornos”.

Un enfoque basado en API permite a las organizaciones aprovechar al máximo la arquitectura de microservicios, una variante de la arquitectura orientada a servicios (SOA), en la que las aplicaciones se estructuran como colecciones de servicios débilmente acoplados. Una empresa que ha adoptado un enfoque de API primero es The Lego Group, lo cual es apropiado, dado que el concepto imita el conjunto de productos Legos, donde las interfaces estándar en los ladrillos permiten a los usuarios reconstruir un todo más grande.

"Nuestra prioridad estratégica es construir sistemas débilmente acoplados, respaldados por nuestros equipos de productos que construyen y operan API para exponer sus servicios", dice Niall Edwards, vicepresidente de marketing y tecnología de canales de The Lego Group. “Nuestra plataforma tecnológica Lego.com se ha basado íntegramente en microservicios y API desde hace varios años y ahora estamos propagando este enfoque en todas nuestras áreas tecnológicas. Ahora estamos llevando este enfoque a los sistemas empresariales más monolíticos”.

Lego Group ofrece un ejemplo perfecto de cómo el enfoque de 'API first' favorece los microservicios, en lugar de funcionalidades más grandes y complejas. Las nuevas API deben realizar servicios estrechamente definidos que puedan ser utilizados por una variedad de aplicaciones. Los sistemas más antiguos se pueden actualizar con API de manera que permitan a las aplicaciones consumir servicios heredados como si fueran desarrollados recientemente.

A medida que las inversiones en tecnología heredada deben ser reemplazadas, los CIO harían bien en asegurarse de incorporar nuevos proveedores solo si ofrecen microservicios y se ajustan a los principios de 'API first'.

2 Desarrollar una política de API y hacerla cumplir

Para garantizar un acoplamiento flexible y una alta coherencia entre los componentes de software desarrollados por diferentes grupos (tanto internos como externos) es necesaria una política API común. La política debe indicar que TI realiza algunos servicios de forma centralizada, incluso cuando la mayor parte del trabajo de API se implementa de forma independiente por una variedad de equipos de desarrollo. Por ejemplo, para garantizar la coherencia, el control de acceso debe gestionarse de forma centralizada, con un único esquema de identificación y autenticación para todas las API. El formato de los datos también debería gestionarse de forma centralizada para garantizar la uniformidad. Y, por último, los acuerdos de nivel de servicio (SLA) deben ser definidos y controlados por TI. Por ejemplo, se podría decir que, para cualquier cosa que tenga que ver con el cliente, las API deberían responder en 50 milisegundos.

"Si no hay claridad sobre quién es responsable de qué, entonces es un caos y nadie sabe la fuente de la verdad", expresa Edwards. “El modelo de datos empresariales debe indicar claramente quién es responsable de qué datos. Los usuarios de esos datos necesitan saber que pueden almacenarlos en caché y usarlos, pero nunca cambiarlos. Los cambios en los datos ocurren sólo en la fuente, y esos cambios deben ser detectables y expuestos a todos los consumidores”.

Las API debían estar respaldadas por microservicios para ser más efectivas. Los CIO deben definir las API con esta suposición y luego crear el servicio internamente o seleccionar proveedores que brinden servicios que se adhieran a este enfoque.

"Las API deben poder llamarse de forma independiente, ser apátridas e idempotentes", afirma Kelly Goetsch, directora de estrategia de Commercetools y autora de cuatro libros sobre API y microservicios. Esto significa que una aplicación puede usar una API sin tener que llamar a otra primero, y que los valores internos del servicio no se cambian de manera que produzca un resultado diferente cada vez que se llama. Por ejemplo, puede invocar una API para agregarla a un carrito varias veces y, si es idempotente, actuará de la misma manera cada vez que se invoque.

Por último, la política debe garantizar que no haya distinción entre API internas y API externas. "Una de las partes brillantes del Mandato de Bezos fue decir que las API deben externalizarse de forma predeterminada", dice Rasmussen. "Y si nos fijamos en AWS, que comenzó como un proyecto interno, lo pusieron a disposición del mundo exterior simplemente cambiando el acceso a lo que ya se estaba utilizando dentro de la empresa".

Una vez que se implementa una política de API, la clave es asegurarse de que todos los equipos la cumplan. Con tantas partes móviles, conexiones y datos en tránsito, esta es una faceta crucial que ningún líder de TI debería pasar por alto.

3 Cree y mantenga un catálogo de API

Dado que es probable que se necesite una gama tan amplia de servicios para cumplir su visión de API, también es esencial indexar las API que su organización está creando, así como aquellas que su organización probablemente dependa de terceros para proporcionarlas.

"Los CIO deberían desarrollar un catálogo de API y una estrategia para gestionar ese catálogo", afirma Goetsch. “El catálogo debe definir las API e incluir todas las funciones que la empresa necesita. Luego podrás decidir si construyes o compras el software que proporciona esos servicios”.

Si bien el catálogo debe mantenerse de forma centralizada, la responsabilidad de la implementación debe dejarse en manos de equipos individuales o proveedores externos. Pero quienes desarrollan los servicios deben respetar lo que se define en el catálogo, afirma Goetsch. "Los equipos que implementan las API pueden elegir su base de datos y muchas otras cosas", afirma. “Pero luego, si se equivocan, responsabilizarlos. Puede determinar muy rápida y fácilmente si un equipo lo está gestionando correctamente. Si las API están fallando, entonces sabes que tienes un problema”.

El catálogo central debe estar bien documentado y acompañarse de herramientas de descubrimiento que permitan a los usuarios internos y externos encontrar API en función de una descripción de sus necesidades o un conjunto de palabras clave. "El Grupo Lego ha invertido en herramientas centralizadas de descubrimiento para ayudar a los desarrolladores a encontrar las API de otros y utilizarlas para componer un producto más grande, tal como lo hace la gente con los ladrillos Lego", indica Edwards.

Al adherirse a estos tres mandamientos y prestar atención a la sabiduría adquirida a lo largo de años de experiencia, los líderes de TI pueden crear un marco que garantice un camino claro hacia cada servicio. Los consumidores pueden contar con una interfaz sólida y los productores obtienen la libertad que necesitan para crear servicios. Cada lado puede innovar a su propio ritmo.