Menú

TechnologyRadar

Una guía con opiniones sobre las tecnologías de vanguardia
Volumen 23

Descarga el Radar Tecnológico Volumen 23

English| Español| Português| 中文| ไทย|

Temas para esta edición

GraphQL está teniendo su momento. Incentivamos a los equipos a usar GraphQL y la creciente cantidad de herramientas alrededor de éste, pero también llamamos a tener cuidado con el uso de ciertas tecnologías, diseñadas para atender situaciones específicas, para resolver demasiados problemas.
Originalmente diseñados para explorar documentos, hoy los navegadores web hospedan aplicaciones. Esta inconsistencia continúa siendo un desafío para quienes desarrollan, quiénes deben seguir repensando la mejor forma de construir aplicaciones web.
Todo tipo de herramientas innovadoras de visualización han aparecido para múltiples propósitos, como la infraestructura, la ciencia de datos y los servicios en la nube. A medida que los ecosistemas de desarrollo se hacen más complejos una imagen generalmente ayuda a dominar la inevitable sobrecarga cognitiva.
La infraestructura como código ha llegado a su adolescencia. Las herramientas relacionadas han mejorado bastante respecto a su primera generación. Pero como con la mayoría de adolescentes, tiene sus lados positivos y negativos.
Varias de nuestra discusiones se centran alrededor de herramientas y técnicas que promueven la democratización de la programación: habilitar a cualquier persona para ejecutar tareas que solo las personas con conocimientos de programación podían realizar. Pero como ocurre con las herramientas que requieren poca programación, sigue siendo necesario encontrar un balance entre los pros y contras.

La grandiosidad de GraphQL


Vemos que ha aumentado la adopción de GraphQL en muchos equipos, además de la existencia de un próspero ecosistema de soporte. GraphQL resuelve algunos problemas comunes que se manifiestan en las arquitecturas distribuidas modernas como los microservicios. Cuando se dividen las cosas en partes pequeñas, a menudo es necesario volver a consolidar la información para resolver los requerimientos del negocio. Esta herramienta ofrece capacidades convenientes que ayudan a resolver este problema cada vez más común. Como todas las abstracciones poderosas, puede ser necesario realizar compromisos y efectuar evaluaciones cuidadosas por parte de los equipos para evitar efectos negativos a largo plazo. Por ejemplo, hemos visto casos donde se provee demasiados detalles de implementación subyacentes a través de una herramienta de agregación, lo que genera una fragilidad innecesaria en la arquitectura. También vimos que facilidades de corto plazo se convirtieron en dolores de cabeza en el largo plazo, como cuando los equipos intentaron utilizar una herramienta de agregación para crear un modelo de datos canónico, universal y centralizado. Alentamos a que los equipos utilicen GraphQL y las herramientas emergentes que lo rodean, pero insistimos en que sean cautelosos en no generalizar tecnologías cuyo enfoque es restringido para resolver demasiados problemas.

Los desafíos con el Navegador continúan


El navegador web fue diseñado originalmente para explorar documentos, y hoy en día permite principalmente la ejecución de aplicaciones, con lo que el desfase en la abstracción continúa siendo un reto para las personas desarrolladoras. Para superar los múltiples problemas inherentes a este desfase, los equipos de desarrollo siguen repensando y volviendo a desafiar a los métodos establecidos para ejecutar pruebas en el navegador, gestionar el estado y, en general, construir aplicaciones ricas y rápidas. Hemos visto varias de estas tendencias en el Radar. Primero, movimos a Redux a “Adoptar” en 2017 y lo presentamos como la solución por defecto para gestionar el estado en aplicaciones React, y ahora vemos que los equipos de desarrollo buscan algo distinto (Recoil) o retrasan la decisión de adoptar una librería de gestión del estado. Segundo, Svelte ha estado ganando más interés y desafía uno de los conceptos establecidos y aplicados por los frameworks populares como React y Vue.js: el DOM virtual. Tercero, seguimos viendo nuevas herramientas para ejecutar pruebas en el navegador: Playwright es otro nuevo intento de mejorar las pruebas de interfaz de usuario mientras que Mock Service Worker es un nuevo método para desacoplar las pruebas de las interacciones con el back-end. Cuarto, continuamos observando el reto de balancear la productividad de las personas desarrolladoras con el rendimiento: con los polyfills adaptados al navegador se intenta cambiar la escala en este compromiso.

Visualizar todo


Esta edición del Radar presenta varios blips a través de todo el escenario tecnológico con una cosa en común: visualización. Encontrarás blips sobre infraestructura, ciencia de datos, recursos en la nube y un conjunto de innovadoras herramientas de visualización, incluyendo varias formas efectivas para ver abstracciones complicadas. También encontrarás discusiones sobre herramientas interactivas para la visualización de datos y tableros como Dash, Bokeh y Streamlit, así como tambien herramientas para la visualización de la infraestructura, como Kiali, utilizada para visualizar mallas de servicio en arquitecturas de microservicios. A medida que los ecosistemas de desarrollo se hacen más complejos una imagen generalmente ayuda a dominar la inevitable sobrecarga cognitiva.

Adolescencia de la Infraestructura como Código


Administrar la infraestructura como código se ha hecho más común a medida que las organizaciones ven los beneficios de automatizar su infraestructura creando, por consiguiente, un ciclo de retroalimentación de innovación-adopción para los creadores de herramientas y frameworks. Herramientas como el CDK de AWS y Pulumi, entre otras, ofrecen capacidades más extensas que sus predecesoras, mejorando a tal punto que creemos que la práctica de la infraestructura como código ha llegado a su adolescencia, con sus consecuencias tanto positivas como negativas. Estamos gratamente sorprendidos del número de blips en todos los cuadrantes que reflejan positivamente la mejora en madurez de este ecosistema. Sin embargo, también discutimos los desafíos en cuanto a la falta de patrones maduros y los problemas que muchas compañías enfrentan cuando tratan de encontrar el mejor uso de esta práctica, todos los cuales evidencian el avance en el camino hacia la madurez. Esperamos que la comunidad de infraestructura siga aprendiendo lecciones del diseño de software, especialmente en términos de la creación de una infraestructura poco acoplada que sea capaz de ser desplegada.

Democratizando la programación


Varias de nuestras discusiones giran en torno a las herramientas y técnicas que promueven la democratización de la programación: habilitar a cualquier persona para ejecutar tareas que anteriormente solo las personas con conocimientos de programación podían realizar. Por ejemplo, soluciones como IFTTT y Zapier han sido muy populares en este espacio por mucho tiempo. Hemos observado un incremento en el uso de herramientas como Amazon Honeycode, una herramienta que permite crear aplicaciones de negocio simples sin saber programar. A pesar de que estas herramientas proveen un ambiente de programación de propósito específico, los desafíos surgen cuando se mueven estas soluciones a ambientes de producción de gran escala. Las personas desarrolladoras y las expertas con las hojas de cálculo, por mucho tiempo han buscado la forma de encontrar un punto medio entre los ambientes de programación específicos a un dominio y los tradicionales. El advenimiento de nuevas y modernas herramientas renueva la discusión a través de dominios más amplios, donde se presentan muchos de los mismos pros y contras.

Visita nuestro archivo para leer edición anteriores

Suscríbete. Sigue informado/a

Publicamos artículos relacionados al Technology Radar durante todo el año.

¡Gracias!

Te has suscrito al contenido de nuestro Technology Radar. Mantente atento a tu bandeja de entrada, nos pondremos en contacto pronto.