Header Ads Widget

Ticker

6/recent/ticker-posts

Cinco conceptos erróneos comunes sobre las API

 

Descubra cómo evitar los conceptos erróneos habituales de las API y la desilusión resultante.

A veces se percibe que las API tienen propiedades casi mágicas. Dado que las API son tan esenciales para la transformación digital, ya que impulsan todas nuestras experiencias digitales, la conclusión es que una vez que tenga y utilice las API, todas las maravillas de la transformación digital simplemente sucederán. Por supuesto, ese no es necesariamente el caso, y el propósito de este artículo es explicar algunas de las cosas útiles donde las API juegan un papel esencial, pero donde las API son necesarias pero no suficientes.

Trabajando con muchas organizaciones globales en el espacio de API, más recientemente como parte del equipo de Axway Catalyst , nuestra función es simplemente ayudar a los clientes a tomar buenas decisiones. Esto, por supuesto, también implica ayudar a los clientes a evitar malas decisiones. Una de esas malas decisiones es tener una comprensión incompleta de la complejidad de la transformación digital y las API. Es fácil esperar demasiado de simplemente "hacer API" sin asegurarse de que todos los factores necesarios para el éxito estén en su lugar.

Explicaré cinco conceptos erróneos comunes sobre los poderes de las API . Esperamos que sucedan estas cosas buenas al utilizar las API, pero también debemos entender que no son tan simples y que el éxito dependerá de que también se aborden las complejidades adicionales. Una mejor comprensión de estas complejidades desde el principio ayudará a evitar la desilusión. También ayudará a asegurarse de considerar todos los ingredientes necesarios para una API exitosa al comenzar su viaje.

Concepto erróneo n. ° 1: ¡Desenredar monolitos!


Las API son esenciales para mejorar la modularidad, lo que permite que los sistemas de TI entrelazados se descompongan en ecosistemas poco acoplados y, por lo tanto, sean más fáciles de mantener y ampliar. Sin embargo, la modularización es una tarea difícil en la que encontrar los límites correctos es el principal desafío.


Una motivación común para usar las API es deshacerse de las soluciones monolíticas que a menudo tienen una variedad de problemas asociados, y lo más importante es que son difíciles de cambiar, difíciles de escalar y difíciles de integrar con otras soluciones. Por definición, las API (en su sentido moderno de "interfaces en red") son esenciales en esta imagen, porque desenredar significa que la estructura modular resultante necesita comunicaciones para funcionar, y estas utilizarán API.

Sin embargo, el trabajo duro en esta imagen es llegar a una modularización adecuada donde la estructura resultante siga principios de diseño estructurados. Existen muchas teorías y prácticas sobre cómo llegar a un "buen" diseño estructurado que represente un sistema complejo. El arduo trabajo de hacerlo conducirá a componentes que luego se comunicarán a través de API, pero estas API son un efecto y no la causa del desenredo.

Monolith to Microservices" de Sam Newman proporciona una guía útil sobre cómo descomponer sistemáticamente un sistema monolítico en uno que se compone de muchos componentes que se comunican. Es revelador que el libro tenga mucho que decir sobre los patrones y estrategias de descomposición, pero se centra poco en cómo diseñar las comunicaciones entre los componentes resultantes. El éxito de una buena descomposición se define mediante la identificación de los componentes correctos y luego tallando las piezas de manera que permitan que el sistema general siga siendo funcional durante la transición. Las API se crearán como un efecto secundario de hacer esto, pero el éxito es una función de los patrones y estrategias de descomposición.

El peor de los casos es que las API empeorarán las cosas porque la descomposición no se realizó correctamente. En este caso, la arquitectura basada en API recién creada sufre de API conversadoras, y las API en sí mismas no son tan útiles para desbloquear nuevos valores. Este resultado a menudo se conoce como un "monolito distribuido", pero este resultado no se puede atribuir a "API que afectan negativamente al rendimiento"; es solo un pésimo diseño de sistema. Además, las malas elecciones de diseño de API pueden tener un impacto más negativo en el sistema resultante, pero la causa principal, en este caso, con mayor frecuencia es un diseño en el que los componentes no están acoplados de manera flexible.

Concepto erróneo # 2: ¡Escalando!


Las API le permiten escalar más fácilmente los recursos de TI al escalar solo aquellas partes que necesitan escalar. Sin embargo, el escalado depende fundamentalmente de la modularización y los problemas de estado compartido, que son tareas de diseño difíciles para las arquitecturas descentralizadas.


La mejora de la escalabilidad es una de las razones por las que los arquitectos consideran las API. Cuando tiene componentes desacoplados, según el razonamiento, se vuelve más fácil escalar aquellas partes que necesitan escala, mientras que otras partes del sistema pueden dejarse solas. En muchos casos, cuando las personas consideran los microservicios o los servidores sin servidor, uno de los principales valores en los que podrían estar interesados ​​es el escalado. Para los microservicios, es posible que deba invertir en cómo implementar el escalado con algo como Kubernetes. Para los servidores sin servidor, el escalado funciona más fácilmente, se les proporcionó una plataforma con la capacidad suficiente, el escalado se puede hacer de forma transparente y es simplemente una cuestión de la frecuencia con la que se invocan las funciones sin servidor.

Dado que las API son esenciales tanto para microservicios como para servidores sin servidor (son parte de la definición de lo que son estas cosas), una vez más, se podría concluir que con las API implementadas, el escalado se vuelve mucho más fácil. Una vez más, este no es necesariamente el caso. Cuando se trata de escalar, y en particular, el escalado selectivo que los componentes basados ​​en API pueden ofrecer (escalando solo aquellos componentes que necesitan ser escalados), entonces, una vez más, la arquitectura es mucho más crítica que las API.

Hace un tiempo, cuando la Transferencia de estado representacional (REST) ​​era un tema muy discutido, un aspecto que a menudo se pasaba por alto era que una de las limitaciones de REST es que los servicios no tengan estado. De esa forma, cada invocación de un servicio es estrictamente una función de la invocación (y no de algún estado de conversación compartido). Este diseño permite que el escalado sea más simple porque los servicios se pueden escalar sin tener que realizar un seguimiento del estado de la conversación. Este es un diseño útil, pero depende de que los diseñadores de servicios creen específicamente diseños sin estado. Para los servicios con estado, el escalado se vuelve considerablemente más difícil porque las solicitudes no pueden usarse tan fácilmente para escalar como se requiere.

Como antes, también existe el peor de los casos. Si el diseño del sistema no considera el estado compartido, el escalado puede tener efectos secundarios no deseados. Aún puede ser posible escalar el componente a pedido, pero escalar el contexto que necesita (porque no es apátrida) puede tener un efecto dominó desafortunado. Esto posiblemente se pueda mitigar mediante enfoques sofisticados de intercambio de estados, pero el problema subyacente a menudo es el de un "estado compartido implícito".

Concepto erróneo n. ° 3: ¡Monetización!


Las API pueden ser nuevas fuentes de ingresos, lo que permite una experimentación rentable con ofertas digitales y la creación de nuevas fuentes de ingresos más allá de las fuentes tradicionales de ingresos. Sin embargo, solo un pequeño porcentaje de las estrategias de API implican monetización directa.


Hay una gran cantidad de presentaciones que destacan cómo algunas empresas ganan mucho dinero con sus API. Los ejemplos más destacados pueden ser Stripe y Twilio . Algunas de estas presentaciones hablan sobre la “Economía API” y luego llegan a la conclusión de que esto significa que se gana dinero al cobrar por el acceso a la API. Para las organizaciones que están considerando sus viajes de API, esto parece una ruta tentadora, que abre nuevas fuentes de ingresos con solo exponer las API y cobrar por ellas. Algunos proveedores de API también anuncian de manera bastante agresiva este tipo de ingresos directos basados ​​en API, con la esperanza de que los clientes potenciales lo tengan en cuenta en sus análisis de ROI.

Sin embargo, la realidad es que es una pequeña minoría de casos en los que el valor de la API se manifiesta directamente en el acceso a la API de pago. En la mayoría de los casos, el valor de la API se manifiesta al permitir más cadenas de valor y una cultura en la que estas cadenas de valor se pueden construir rápidamente y con poca coordinación. Por esta razón, el popular apodo de "API como producto" es una elección de nombre bastante pobre, ya que parece implicar que la API en sí es un producto que puede monetizarse. Hablar de "Producto como API", por otro lado, deja en claro que el valor se crea a través de los productos y que las API simplemente son el tejido conectivo que permite desbloquear y utilizar este valor con mayor facilidad.

Una vez más, es indudable que las API son necesarias para el valor que se crea en el mundo digital actual, y que mejorar la estrategia de API aumenta sus posibilidades de obtener más valor. Pero el valor está en lo que haces y en cómo permites que estas cosas se compongan en cadenas de valor digitalizadas. Si lo que haces tiene poco valor inherente, es posible que tus esfuerzos por digitalizar tu escenario no generen mucho valor adicional. E incluso si lo que hace tiene un gran valor inherente esperando ser realizado, es poco probable que exponer la API correcta sea lo que le impida darse cuenta de ese valor. Lo que vemos con mucha más frecuencia son empresas que luchan por realizar los cambios empresariales y organizativos correctos, de modo que el valor latente de sus productos se pueda realizar mediante la creación de experiencias excelentes y valiosas a su alrededor.

Por supuesto, también tenemos el peor de los casos aquí. Si la percepción de la monetización de la API es tal que el valor de la API se manifiesta con ingresos directos, esto introduce un análisis de valor incompleto para el recorrido de la API. Nadie ha descubierto todavía la fórmula perfecta sobre cómo evaluar con precisión el valor de una API (de modo que las inversiones se puedan orientar hacia la habilitación de API, en primer lugar, con las capacidades que tienen el mayor potencial). Aún así, ciertamente no es tan simple como mirar los ingresos generados a través del acceso a la API. Comprender completamente las cadenas de valor y evaluar y predecir su éxito nunca ha sido una ciencia difícil desde que las organizaciones comenzaron a planificarlas y construirlas. Esto no es diferente para las cadenas de valor digitales, así que asegúrese de adoptar una visión holística.

Concepto erróneo n. ° 4: ¡Comunicaciones!


Las API son la forma de comunicarse en entornos digitales y, a través de las API, todas las capacidades pueden interactuar fácilmente en toda la organización y más allá. Sin embargo, esto solo funciona cuando los canales de comunicación están diseñados y utilizados para depender de un modelo compartido de descripción y comprensión de las cosas.


Las API son un lenguaje: permiten que los compañeros se comuniquen para lograr algún objetivo. Como tal, las API supuestamente deberían permitir a los equipos estar más desacoplados, reduciendo así la sobrecarga de comunicación y coordinación. En un escenario ideal, las comunicaciones entre equipos suceden por completo a través de API o canales asociados (como documentación y canales de soporte). En realidad, las cosas suelen ser un poco más complicadas, y eso se debe en parte a que el lenguaje de la API debe estar a un nivel útil para todos los involucrados.

Por ejemplo, un escenario que vemos a menudo es que los esfuerzos de API comienzan en el lado de la TI. Una iniciativa inicial puede ser crear "API del sistema", que a menudo son API de nivel relativamente bajo que representan las capacidades proporcionadas por ciertos sistemas. Esto a menudo se traduce en una mala experiencia para aquellos equipos que están un poco más lejos de los detalles del sistema: buscan soluciones a sus problemas y no acceso a los detalles de implementación. A menudo se necesitan muchas de estas "API del sistema" y su orquestación de formas específicas para realizar tareas que, desde un punto de vista empresarial, deberían ser relativamente fáciles de realizar. Existe una "discrepancia de idioma" de las API que se están construyendo desde el punto de vista del sistema, y ​​los consumidores de API buscan API que resuelvan sus problemas de dominio. (Para obtener más información sobre las API del sistema,Mira este video que pregunta "¿Son las API del sistema una buena idea?" )

Este problema se resuelve mejor al considerar las API como capacidades de nivel empresarial: deben tener una propuesta de valor por qué otros podrían usarlas, y resolver ese problema de la manera más fácil posible se convierte en el principio rector para identificar y diseñar API. Si bien esto puede parecer fácil, a menudo es un problema difícil de resolver porque requiere un diálogo funcional entre la empresa y TI. Esto puede ser algo natural para las empresas que nacieron digitales. Sin embargo, puede ser un verdadero desafío para las empresas en las que el negocio y la TI siguen siendo dos partes relativamente desconectadas de la organización.

El peor de los casos es que las API técnicas profundicen la brecha entre la empresa y la TI. TI piensa que están aportando valor porque ponen a disposición las capacidades. Las empresas piensan que “esto es solo otra cosa tecnológica” porque no ven un valor comercial claro expuesto en las API técnicas. El remedio para esto es que ambas partes se entiendan mejor y trabajen para establecer y usar un lenguaje compartido. TI debe centrar sus esfuerzos en exponer las API que tienen una propuesta de valor clara y cumplen un propósito comercial. Las empresas deben comenzar a "hablar API", no hasta el punto en que diseñan JSON que esperan como respuestas, sino hasta el nivel en el que piensan en términos de diseño y entrega de productos como cadenas de valor digitalizadas, basadas en API existentes, y exponiendo sus API. Es decir, en esencia,

Concepto erróneo n. ° 5: ¡Problemas organizativos!


Las API pueden ayudar a mejorar la forma en que los equipos se comunican y cómo la organización puede innovar. Sin embargo, las API solo pueden ayudar a la organización a comunicarse mejor, pero no provocarán cambios organizativos.


Las grandes organizaciones tardan en adaptarse a los cambios, mientras que las organizaciones más modernas están demostrando cómo mejorar la agilidad mediante la reorganización. Estas empresas están reorganizando la forma en que crean productos, y esto se refleja en organizaciones y culturas centradas en API.

No hay forma de escapar de la Ley de Conway , lo que significa que para construir algo que no sea monolítico y se pueda cambiar de manera más eficiente, se necesita una organización que tenga las mismas propiedades estructurales.

Las API juegan un papel esencial en esta imagen porque reducen significativamente la sobrecarga de coordinación. En lugar de realizar proyectos de "integración" únicos, las capacidades se exponen a través de API, y cualquiera que las necesite puede simplemente acceder a ellas, idealmente sin siquiera hablar con el equipo que posee esa capacidad. Este enfoque se escala mejor y crea una gran cantidad de opciones cuando se trata de equipos que diseñan nuevas experiencias y buscan habilidades existentes que puedan aprovechar. En una organización que funciona perfectamente, los equipos están desvinculados y pueden trabajar a su propia velocidad, entregando y evolucionando productos según sea necesario.

En realidad, cambiar una organización grande a esta imagen ideal de equipos desacoplados y empoderados es un desafío mucho más difícil que diseñar las API que producirán y necesitarán. Y, por supuesto, incluso si una organización se ha cambiado con éxito, aún se requiere un diseño y ejecución cuidadosos de una estrategia de API y un programa de API. Pero en nuestra experiencia, una vez que estos problemas específicos de API son el problema restante, la parte más difícil de la transformación se ha resuelto.

El peor escenario para esto es que los líderes de la organización ven la transformación digital ante todo como un desafío técnico y se centran en los indicadores técnicos. Una vez que se crean las API, se supone que seguirán cosas buenas. Vemos que muchas organizaciones pierden meses o años de tiempo precioso porque no aprecian completamente las implicaciones para los pilares empresariales y organizativos. En nuestro trabajo con grandes empresas, una parte sustancial de nuestro tiempo consiste en asegurarnos de que se abordan todos los pilares necesarios para la transformación digital (empresarial, organizativa, tecnológica). Desde esa perspectiva, las API simplemente son un efecto secundario de la transformación digital y no una causa.

Conclusiones

Este artículo presenta cinco conceptos erróneos comunes sobre lo que pueden hacer las API y destaca que en realidad pueden hacer estas cosas, pero no por sí mismas. Las API son necesarias pero no suficientes para muchos desafíos y oportunidades importantes en las organizaciones cada vez más digitales de hoy. La conclusión más importante de este artículo es que siempre adopta una visión holística: las API son parte de muchas soluciones en el espacio digital, pero nunca son la solución en sí mismas.

Como todas las tendencias tecnológicas populares, las API están pasando por el ciclo de la publicidad. Al principio, parecen ser la solución a muchos problemas. Luego viene la desilusión, cuando queda claro que son "simplemente plomería" y que muchos otros factores intervienen en hacer que las API sean útiles además de tenerlas. Después de esto, está el arduo trabajo para llegar a la meseta de la productividad, donde las API son una parte esencial de muchas soluciones en el espacio digital, pero también entran otros factores en estas soluciones.

Afortunadamente, las organizaciones hoy en día pueden beneficiarse de una gran experiencia, pueden elegir entre muchos productos disponibles y pueden confiar en asesores confiables para su viaje. Todos estos problemas discutidos anteriormente son desafíos muy reales y relevantes para muchas organizaciones en la actualidad. Asegúrese de que su estrategia de API y su programa de API tengan una visión integral. Muchos informes sobre “iniciativas de transformación digital” muestran altas tasas de fallas y, al mirar más allá de los aspectos técnicos, mejora drásticamente sus posibilidades de realizar cambios significativos que realmente transformen su organización.

Este artículo se basa en una presentación realizada en la Conferencia API en Berlín en octubre de 2019 . Las diapositivas están disponibles en línea en.http://dret.net/lectures/apicon-2019/api-limits Vea la presentación a continuación:

Publicar un comentario

0 Comentarios