Microservicios, API e innovaciones: el poder de las API

Hola a todos!



Hoy nos gustaría ofrecerle una traducción de un artículo de programación del famoso Mike Amundsen , el arquitecto principal de API Academy. En este texto comparativamente corto, Mike explica de manera inteligente por qué debe prestar especial atención al desarrollo de la API y cómo se hacen correctamente.

Durante mi tiempo como profesor en la Academia API, tuve la oportunidad de viajar por todo el mundo conociendo gente increíble. Trabajan en proyectos deslumbrantes en varias compañías, desde nuevas empresas hasta empresas globales establecidas. Increíblemente, pero donde sea que estuve y con quién hablé, surgieron muchas ideas, trucos e impresiones comunes en nuestras conversaciones. Los tres más comunes son microservicios, API y una cultura de innovación. Los tres se están introduciendo para acelerar la transformación digital de la organización.

Este artículo es el segundo de una serie de tres publicaciones. Aquí hablaré sobre lo que enseñamos en nuestra academia API en el contexto de estas tres tendencias poderosas, y también describiré algunos trucos que ayudarán a su empresa a pasar de grandes palabras a conversiones reales. En un artículo anterior, presté especial atención a la importancia de los microservicios y me concentré en tres cosas que puede hacer hoy: 1) la transición a la entrega continua, 2) la provisión de implementaciones preparadas y 3) la reducción de la cola "en el trabajo" para reducir el tiempo antes de que el producto llegue El mercado. Estos tres hábitos esenciales ayudarán a su organización a aprovechar al máximo los beneficios de los microservicios.

Las API proporcionan entrega multicanal

Muchas compañías usan microservicios, tratando de encapsular las capacidades clave de su organización de tal manera que se asegure su escalabilidad y confiabilidad. Los microservicios corresponden a elementos funcionales importantes del componente de TI de su empresa. Pero esto es solo la mitad de la batalla. También es necesario descubrir cómo proporcionar estas oportunidades, de modo que con su ayuda sería conveniente resolver los desafíos actuales que enfrenta su negocio. Aquí es donde entra en juego la API.

Las API (interfaces de programación de aplicaciones) desempeñan el mismo papel para una máquina que una interfaz gráfica para los usuarios de los sistemas de información de su empresa. A menudo, las API se utilizan para mezclar diferentes capacidades en una solución consistente y asequible. Por ejemplo, su empresa puede usar servicios para procesar transacciones relacionadas con clientes, cuentas y ventas. Cada uno de estos servicios fue cuidadosamente diseñado, programado, probado, luego de lo cual se lanzó y se incorporó a la infraestructura de su empresa; El servicio proporciona una funcionalidad crítica para su negocio. Una vez que necesite crear una nueva solución para presentar a los usuarios el curso de las cosas, y esta solución debería funcionar en una variedad de dispositivos y plataformas. Entonces, estamos comenzando a usar la API a plena capacidad.

Se puede diseñar una única API, mejorada para soluciones, por ejemplo, una API para familiarizar a los usuarios con el sistema, de modo que las interacciones y los flujos de tareas más importantes que son críticos en la etapa de dicha familiarización salgan a la superficie. Aquí necesitamos una API que le permita mezclar varios elementos funcionales relacionados con clientes, cuentas y ventas en interfaces de usuario seguras, potentes y asequibles para una amplia variedad de públicos objetivo dentro de su empresa. Por ejemplo, el personal de ventas puede iniciar sesión desde un navegador, administradores de oficina desde aplicaciones de PC y clientes potenciales desde teléfonos inteligentes y tabletas.

Podemos decir que la API es una especie de "pegamento" que mantiene unidos los elementos del programa, una capa intermedia a través de la cual interactúan sus servicios internos y los consumidores externos de servicios. API es la herramienta para distribuir la funcionalidad clave de tal manera que los consumidores de servicios puedan usarla, cuya tarea es crear mecanismos importantes para interactuar con el usuario en una variedad de plataformas de hardware. Dichos consumidores pueden incluir otros equipos que trabajan en su oficina, colegas con quienes se comunica remotamente, socios comerciales clave o incluso empleados remotos involucrados en el desarrollo o diseño del lado del cliente.

Pensamiento de diseño y API

La mayoría de las empresas saben lo importante que es dedicar tiempo al desarrollo de una interfaz de usuario para sus aplicaciones. Debido a que se sabe que a los usuarios les gusta el buen diseño, aumenta la lealtad de la marca y le permite promover un nuevo negocio. Al mismo tiempo, un diseño de interfaz mal diseñado puede molestar a los clientes, dañar la marca, reducir los ingresos y seleccionar oportunidades. Lo mismo es cierto para el diseño de API.

Si la API se realiza mal, entonces será difícil para los desarrolladores entenderla, debido a esto pueden introducir errores en el sistema y provocar gastos innecesarios para corregir errores y modificar la infraestructura. Sin embargo, si la API funcionó bien, entonces es más fácil para el empleado trabajar eficazmente con ella. Se reduce el tiempo requerido para crear una solución estable, el equipo incluso recibe un incentivo para emitir soluciones nuevas e innovadoras que ayudarían a clientes y colegas. El diseño de API es un área de trabajo tan importante que Werner Vogels, director de tecnología de Amazon, incluso dijo:

Inmediatamente reconocimos que diseñar una API es una tarea muy importante, ya que solo intentaremos resolverla correctamente.

Son API de alta calidad que ayudan a atraer socios a su ecosistema digital y simplifican las transformaciones corporativas internas de su negocio. La capacidad de dedicar tiempo a hacer todo bien y, a la larga, es una habilidad importante que rastreamos solo de aquellas compañías que han aprendido cómo utilizar completamente sus API.

Consejos esenciales de diseño de API

Es muy importante hacer que la API sea correcta, y hay muchas razones. Después del lanzamiento, es imposible revertir la API Cuando los clientes y las estructuras comerciales clave dependen de su API, cambiar la dependencia puede dañar otros elementos del sistema, romper funcionalidades importantes y poner a cero sus inversiones y el tiempo invertido. Al implementar el programa API, debe tener en cuenta otras cosas importantes. Mencionaré solo algunos.

API canónica no existe

Es un error intentar "por adelantado" elegir un diseño de API canónico para toda su empresa. Solo tratando de implementar algunos objetos y modelos de datos en toda la empresa, es decir, tratando de crear una API única que tenga en cuenta todos los aspectos de su organización sin excepción, ahora y en el futuro, lo más probable es que sea un callejón sin salida. Es mucho mejor proporcionar a sus desarrolladores recomendaciones e indicar restricciones que los ayudarán a evitar errores, revelar creativamente y aplicar el conocimiento del dominio para crear API sorprendentes que atraerán tanto a colegas como a socios.

Proceso de implementación: cortar todo lo innecesario

Dado que la API es solo una interfaz, no funcional como tal, debe poder diseñar, implementar, probar e implementar la API en cuestión de días y semanas, pero no en meses. Sabemos cómo las empresas están tratando de reducir los riesgos de crear una API, asegurando que la API sea conveniente para probar por adelantado, automatizar el proceso de lanzamiento, de modo que las API en sí mismas sean menos costosas y más cómodas de componer.

Centrarse en la interacción, no en la integración.

Otro aspecto clave que las empresas exitosas pueden enfrentar es la capacidad de enseñar a los equipos de desarrollo a integrar en la API la capacidad de interactuar con otros elementos que ya están en la etapa de diseño. Dichas organizaciones explican cómo trabajar con sus API; por lo tanto, estas API no solo son fáciles de entender, sino que también se vinculan fácilmente con otras API de esta empresa. Centrarse en una interacción amplia es más importante que diseñar una integración estrecha y estrecha.

Tres cosas que puedes hacer hoy

Tal trabajo, como cualquier cambio importante, lleva tiempo. Sin embargo, no tardará mucho en esperar el éxito. Te contaré sobre tres medidas que tuve que observar en varias compañías, que puedes tomar hoy.

Adopte su propia práctica de API

Un componente clave del éxito a largo plazo de su programa API es desarrollar prácticas de diseño API específicas de la tecnología. Asegúrese de que dicho programa no dependa completamente de la última moda en programación, usando bibliotecas o plataformas. Para esto, es más conveniente confiar en el paradigma "primer paso - API".

"Lo primero es la API" significa que primero diseñamos la API, y solo luego pensamos en los detalles de su implementación. En principio, el componente comercial es el mismo independientemente de la tecnología que use para implementar la API: ya sea SOAP, CRUD, REST, gRPC, GraphQL o cualquier otra cosa popular. De hecho, es muy probable que un programa bien diseñado le permita formular recomendaciones que sean relevantes para diferentes conjuntos de tecnología, respectivamente, ayudando a su equipo y evaluando posibles ahorros, y manteniendo la coherencia de las decisiones en las versiones posteriores de las plataformas.

Garantizamos bajos riesgos al crear una API

Después de haber diseñado la API con alta calidad, es hora de convertirla en realidad. Al mismo tiempo, recomiendo comenzar con un boceto, luego pasar al prototipo y al patrón de ensamblaje.

Las API de esquema son precisamente "bocetos". Pequeños "dibujos" aproximados que ayudan a dar una impresión de cómo esta API puede resultar "al gusto y al color" desde la posición de un desarrollador. Un boceto API debe hacerse en unas pocas horas, no días. Además, en base a esto, se debe obtener un proyecto que se pueda mostrar a colegas y partes interesadas para que la primera ronda de discusión y las primeras modificaciones no tengan costo. Me gusta usar la plantilla API de Apiary para esto. Utiliza un lenguaje de marcado simple que le permite simular un servidor API en cuestión de minutos. Una herramienta específica no es tan importante, la práctica es importante. Los esquemas lo ayudan a hacer una investigación barata y solo entonces comienzan a preparar una API completa.

Noté que al crear prototipos, las herramientas como Swagger / OpenAPI son populares. Los prototipos son modelos mucho más elaborados de su producto final. Son similares al escenario de la película. Si no miras de cerca, ¡ves una escena prácticamente real! El equipo debería poder preparar un prototipo detallado en solo unos días. Dicho prototipo debería conectarse libremente a instrumentos de prueba, servicios de virtualización y otros elementos de la plataforma para que pueda observar directamente cómo interactúa con su sistema. Se necesitan prototipos para probarlos. Son su última línea de defensa antes de que tenga que gastar dinero en crear una API real que funcione.

Aquí se completa la fase de montaje. Luego, debemos formular un plan de trabajo, establecer plazos y comenzar a convertir el prototipo en un producto. Necesitábamos un boceto y un prototipo para resolver los detalles, identificar errores, etc. El proceso de construcción en sí no es tan interesante. Solo necesita mostrar el resultado final todos los días, implementar paso a paso la API hasta que el trabajo esté listo. Muchas empresas se esfuerzan por construir API no más de 90 días.

API de gestión de tres ballenas

Finalmente, si considera la situación de manera más amplia que en el nivel de diseño e implementación de una API en particular, debe adherirse a un programa viable para trabajar con la API en su organización y aplicar recomendaciones generales para desarrollar API que serán conocidas por todos los equipos. Una regulación clara le permite controlar el desarrollo de la API en toda la empresa, sin tener que supervisar excesivamente los detalles de implementación.
Eric Wilde, mi colega en API Academy, enfatiza la importancia de "administrar el panorama de sus API", es decir, regular tres elementos clave de un programa API: protocolos, formatos y terminología.

La regulación de protocolo es una indicación clara de qué protocolos de nivel de aplicación debe admitir un equipo de API al preparar nuevas versiones. La mayoría de las empresas creen que todas las API nuevas deben ser compatibles con HTTP. Algunos también indican otros protocolos opcionales, como MQTT, Thrift y otros protocolos binarios. Aquí, lo más importante es informar a todos los equipos con anticipación: "Si desea garantizar la interoperabilidad de sus API en el futuro, debe usar estos protocolos". Para implementar esta regla, es aconsejable utilizar una tubería de entrega continua.

La regulación de los formatos significa que debe acordar en qué formatos se enviarán los datos entre los servicios. Casi todos los navegadores esperan una respuesta en formato HTML; así como así, a nivel de su API, debe decidir en qué formato interactuará con todo el ecosistema. La mayoría de las empresas prefieren formatos simples, como JSON, XML o CSV, pero sus modelos de mensajes carecen de metadatos clave, en particular nombres de objetos, enlaces y formularios de entrada, y son necesarios para las interacciones a largo plazo. Por otro lado, también conozco empresas que usan formatos más avanzados, por ejemplo, HAL, Siren y Collection + JSON para API basadas en HTTP. Para las interacciones binarias entre servicios, muchas organizaciones toman protobuf y formatos similares como base. Independientemente del formato que elija, es importante verificarlo en su línea de ensamblaje, asegurándose de que solo las API que cumplan completamente con las regulaciones entren en producción.

El tercer kit de administración de API es la terminología. En este caso, estamos hablando del control sobre los nombres de los puntos de datos y los identificadores de acción utilizados al intercambiar mensajes entre servicios. Cumpliendo con la terminología, la organización puede no tener dudas de que los servicios nuevos serán normalmente aceptados por los existentes. Recordando el "lenguaje común" propuesto por Eric Evans para el diseño orientado a temas (DDD), noto que la terminología que elija es necesaria para hablar sobre la operación comercial más crítica. Debería ser difícil producir un servicio en producción que utilice nombres "completamente nuevos" para los campos de datos y los identificadores de acción. Por el contrario, los elementos de la línea de ensamblaje deben verificarse para que cumplan con la terminología general aceptada en toda la compañía, y las API que abandonan esta terminología no deben entrar en producción.

Después de haber aprendido estos principios: "Primero que nada - API", "bosquejo-prototipo-ensamblaje" y "kit de control de tres API", su equipo podrá usar sus API a plena capacidad, sin arriesgar su estabilidad durante la ejecución.