Header Ads Widget

Ticker

6/recent/ticker-posts

API en Maersk: un estudio de caso



Maersk es un gigante danés multimillonario que se especializa en logística de contenedores. La compañía ha experimentado anteriormente con la creación de sus propias API para fines internos y externos, pero, como veremos, se ha enfrentado a algunos problemas.

En este artículo, analizaremos la API de Maersk y el viaje de transformación digital, y descubriremos por qué la compañía ahora está enfocando esfuerzos significativos en las API web y en tácticas de administración de API inteligentes. Para hacerlo, seguiremos la charla de Dave Holliday , Product Owner de la API Management Platform de Maersk, en la Cumbre de APIs nórdicas de 2019 .

Vea a  Dave Holliday presente en la  Cumbre de APIs nórdicas de 2019 :

Maersk y la transformación digital

Dave comienza su charla explicando por qué la transformación digital es importante para Maersk. Para hacerlo, presenta el status quo para el seguimiento de la cadena de suministro de hoy en día: el EDI 315 .

El documento EDI 315 Status Details (Ocean) es un mensaje que se genera cada vez que cambia el estado de transporte de un contenedor, como cuando se carga o descarga de un buque de envío. Estos mensajes luego se distribuyen utilizando protocolos de transferencia como FTP, SFTP y AS2.

El problema, dice Dave, es que estos mensajes "horribles" son difíciles de consumir y costosos de desarrollar tanto para Maersk como para sus clientes. Echa un vistazo por ti mismo:

En cambio, Dave (¡junto con otros en Maersk, evidentemente!) Cree que sería mucho más conveniente si pudiéramos expresar esta información como un simple objeto JSON:

{
"move": "gateIn", "time": "2019-10-2T08:28:00Z", "carrier": "maersk", "shipper": "party A", "consignee": "party B", "port": "rotterdam" }

Este formato no solo es significativamente más fácil de entender, sino que también es mucho más fácil de desarrollar. Y, en última instancia, el hecho de que sea más fácil de desarrollar hace que sea más barato y rápido. Este, por supuesto, es el valor de la transformación digital.

Errores en el proceso de API de Maersk

Según Dave, la incursión de Maersk en el mundo de las API se inspiró originalmente en el deseo de mejorar la experiencia del cliente en el sitio web Maersk.comAl adoptar una arquitectura de microservicios impulsada por API , pudieron crear aplicaciones web con fines como el seguimiento, la reserva y la gestión de horarios con facilidad.Maersk sitio web com . Al adoptar una API impulsada

Cuando se implementaron estas API internas, los clientes también comenzaron a mencionar las API y sus beneficios en el mundo de los negocios. Naturalmente, la respuesta de Maersk fue algo así como:

De hecho, ¡tenemos algunas API! ¿Qué tal si los compartimos contigo?

Finalmente, Maersk abrió el acceso a sus API internas , sin realmente apreciar lo que se necesita para construir una externalización adecuada de esas API. Este solo paso en falso llevó a muchos más errores en el futuro.

Sin portal para desarrolladores

Dado que Maersk no se propuso originalmente crear API orientadas al cliente, no tuvo un portal para desarrolladores durante un largo período de tiempo. Esto significaba que los clientes tenían que incorporarse caso por caso y probablemente creaba muchos más problemas de soporte de los necesarios. La solución a este problema es bastante sencilla: cree un portal central para los usuarios de sus API, pero más sobre eso más adelante.

No utilizar los estándares

Uno de los primeros comentarios de los clientes sobre la API de horarios de Maersk, que permite a los clientes saber cuándo Maersk puede realizar envíos entre dos ubicaciones, fue que utilizó los geoID patentados de Maersk para referirse a ubicaciones, lo que dificulta su uso. En cambio, las ubicaciones deberían haberse representado utilizando códigos de ubicación de la ONU. Como aprendizaje clave, Dave dice que cuando analizamos la externalización de las API, siempre debemos adoptar los estándares de la industria para que las API sean interoperables y fáciles de consumir.

Lea también: La construcción con estándares abiertos mejora la longevidad de la API

Funcionalidad limitada

Los clientes que utilizaron las primeras API de Maersk pronto quisieron integrar los servicios en sus propios sistemas. A menudo, esto significaba que necesitarían solicitar docenas, cientos o incluso miles de contenedores a la vez. Sin embargo, Maersk solo admitió solicitar un contenedor a la vez. Para evitar problemas similares con las API externas, es fundamental pensar detenidamente cómo las utilizarán los clientes.

Cortafuegos excesivo

En un momento, algunos clientes no pudieron acceder a las API de Maersk en absoluto. La causa fue un firewall excesivamente estricto, que terminó bloqueando accidentalmente todo el tráfico de las direcciones IP de Amazon Web Services. Una vez más, el aprendizaje aquí es ser consciente de cómo (y dónde) los clientes usarán sus API.

Sin claves API

Al crear sus primeras API, Maersk no apreció la importancia de las claves API y otras medidas de seguridad. Cuando estas API finalmente se lanzaron a los clientes, Maersk rápidamente se dio cuenta de que no podían averiguar quién llamaba a su API, lo que llevó a un esfuerzo frenético para implementar claves de API. Por supuesto, hacer cumplir estas claves fue un cambio radical en la API, que dio lugar a muchas conversaciones con los consumidores. La solución a esto es pensar en cómo ir al mercado con sus API, a fin de garantizar que los cambios masivos (especialmente los más importantes) no tengan que realizarse de inmediato.

Lea también: Por qué las claves de API no son suficientes para la seguridad

El área crucial de la gestión de API

Dave ve la gestión de API como una de las áreas más cruciales del recorrido de API de Maersk. Esto comienza con una plataforma de gestión interna, que debe ayudar a cumplir con los objetivos técnicos, organizacionales y comerciales de la empresa en varias áreas:

  • Descubrimiento:  la plataforma debería ayudar a evitar la duplicación y mejorar la reutilización de las API. Esto se logra con un fácil descubrimiento de las API existentes.
  • Soporte:  la plataforma debe rastrear quién construyó cada API, dónde se guarda el código base, qué pila se usó, cómo se prueba y cómo se proporciona el soporte para la API.
  • Proxies: la plataforma debe permitir la implementación perfecta de proxies API, en un patio de recreo y en entornos superiores.
  • Datos: la plataforma debe permitir la recopilación, el seguimiento y el análisis de datos con fines comerciales. Por ejemplo, los errores 404 en la API de horarios ( Schedule not found.) podrían ayudar a identificar nuevas rutas para que Maersk atienda.

Y para Maersk, existe la plataforma de administración de API externa, que incluye lo siguiente:

  • Descubrimiento:  la plataforma debería ayudar a los clientes a encontrar las API que necesitan.
  • Prueba:  la plataforma debería permitir a los clientes probar las API de forma rápida y sencilla.
  • Monetizar: la plataforma debería permitir la monetización para algunas API.

Pensamientos finales

Es fácil cometer errores al implementar una plataforma de API, especialmente una nacida de la externalización espontánea de las API internas. En este caso de estudio, hemos visto solo algunos de los contratiempos que tuvo Maersk cuando adoptó las API por primera vez y cómo allanaron el camino para el enfoque actual de Maersk en la gestión de API. Con versiones tanto internas como externas, la estrategia de administración de API actual de Dave está diseñada para garantizar que las API sean lo más autoservicio posible y generen el menor número de dolores de cabeza.

Publicar un comentario

0 Comentarios