Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Técnicas

Adoptar ?

  • Aunque el mapeo de procesos hasta producción (path-to-production mapping) es una práctica casi universal en Thoughtworks desde la codificación de Entrega continua, a menudo nos encontramos con organizaciones que no están familiarizadas con esta práctica. Esta actividad se suele desarrollar en un workshop con un grupo multidisciplinar de personas – que incluye a todo aquel implicado en el diseño, el desarrollo, la publicación y el operación del software – en torno a una pizarra (o su equivalente virtual). En primer lugar, se enumeran en orden todos los pasos del proceso, desde el equipo del desarrollador hasta producción. A continuación, se lleva a cabo otra sesión para recabar más información y puntos débiles. La técnica más común que vemos se basa en el Mapa del flujo de valor, aunque existen múltiples variantes del mapa de procesos que son igualmente válidas. Esta actividad suele ser reveladora para la mayoría de los participantes, ya que identifica retrasos, riesgos e inconsistencias además de seguir utilizando la representación visual para la mejora continua del proceso de construcción y despliegue. Consideramos esta técnica tan fundamental que nos ha sorprendido descubrir que no la habíamos incluido con anterioridad en el radar.

  • La interacción entre un equipo supone un concepto clave cuando rediseñamos una organización para mejorar la agilidad y velocidad empresarial. Estas interacciones quedan reflejadas en el software a desarrollar (ver Ley de Conway) e indican cuán efectivos pueden ser los equipos entregando valor a sus clientes de manera autónoma. Por ello, aconsejamos invertir tiempo y esfuerzo en establecer el diseño y la interacción de los equipos y, puesto que estas variables pueden evolucionar con el tiempo, es especialmente importante medir y hacer un seguimiento de la carga cognitiva del equipo, la cual indica cómo de fácil o difícil es para los equipos desarrollar, hacer pruebas y mantener sus servicios. Esta plantilla nos ha resultado útil para evaluar la carga cognitiva de los equipos, basada en las ideas de los autores del libro Team Topologies.

    Seguimos sorprendiéndonos del impacto positivo que tiene aplicar los conceptos de este libro al comunicarnos con clientes y rediseñar organizaciones. Los autores recomiendan un enfoque simple pero efectivo para diseñar organizaciones: consiste en identificar solo cuatro tipos de equipos y tres modos de interacción. Esto ayuda a reducir la ambigüedad dentro de la organización y proporciona un vocabulario común para los equipos, partes interesadas y el equipo de dirección para describir y diseñar el trabajo de un equipo. Para implementar este cambio de diseño organizacional, planteamos una estructura ideal de topología de equipo, aplicamos cualquier limitación técnica o de personal (por ejemplo, no hay suficientes empleados) y así extraemos la estructura definitiva. Esto nos permite poder aconsejar mejor a nuestros clientes y anticipar si estamos efectivamente mejorando la carga cognitiva al comparar la estructura actual con la definitiva.

  • Seguimos recomendando que los equipos continúen haciendo uso del modelado de amenazas — un conjunto de técnicas que ayudan a identificar y clasificar amenazas potenciales durante el proceso de desarrollo — pero queremos enfatizar que esto no es una actividad a realizar únicamente al comienzo de los proyectos; los equipos deben evitar el security sandwich. Esto sucede porque durante todo el ciclo de vida de cualquier software, nuevas amenazas surgirán y las existentes continuarán evolucionando debido a eventos externos y constantes cambios de requisitos y arquitecturas. Esto significa que el modelado de amenazas se tiene que repetir de forma periódica — la frecuencia de repetición dependerá de las circunstancias y necesitará considerar factores como el coste de realizar el ejercicio y el riesgo potencial para el negocio. En combinación con otras técnicas, como el establecimiento de requisitos de seguridad multifuncionales para manejar riesgos comunes de las tecnologías del proyecto y el uso de escáneres de seguridad automatizados, el modelado de amenazas puede ser un poderoso recurso.

Probar ?

  • Desde la última vez que hablamos de BERT (Bidirectional Encoder Representations from Transformers) en el Radar, nuestros equipos lo han utilizado exitosamente en unos cuantos proyectos de procesamiento del lenguaje natural (NLP por sus iniciales en inglés). En una de nuestras colaboraciones, observamos mejoras significativas al cambiar el tokenizador por defecto de BERT por un tokenizador word-piece entrenado por el dominio, para preguntas que contenían nombres de marcas o dimensiones. Aunque NLP tiene varios modelos nuevos de transformador, BERT es bien conocido, con una buena documentación y una vibrante comunidad, y continuamos considerándolo efectivo en un contexto de NLP empresarial.

  • Las pruebas de regresión visual son una herramienta útil y poderosa que debes tener siempre a mano, aunque tienen un coste significativo dado que se realizan para toda la página. Con el surgimiento de frameworks basados en componentes como React y Vue, también hemos sido testigos del surgimiento de las pruebas de regresión visual de componentes. Esta técnica logra un buen equilibrio entre valor y coste para asegurarnos de que no se añaden elementos visuales indeseados a la aplicación. En nuestra experiencia, las pruebas de regresión visual de componentes presentan menos falsos positivos y abogan por una buena arquitectura. Utilizar estas pruebas en conjunto con herramientas como Vite y la característica de webpack Hot Module Replacement (HMR), puede ser visto como un cambio de paradigma para aplicar Desarrollo Dirigido por Pruebas (TDD) en proyectos de frontend.

  • Cuando nos enfrentamos al desafío de usar de forma consistente un sistema de diseño en varios factores de forma y plataformas, el equipo de Salesforce ideó el concepto de Tokens de diseño. Los tokens almacenan valores, como colores y fuentes, de forma centralizada. Esto hace posible separar las opciones de las decisiones, y mejora significativamente la colaboración entre equipos. Los Tokens de Diseño no son nuevos, pero con la introducción de herramientas como Tailwind CSS y Style Dictionary, vemos que los Tokens de diseño están siendo utilizados con mayor frecuencia.

  • Usar cuentas de correo electrónico de pruebas, así como servidores SMTP completos para pruebas (del inglés Simple Mail Transfer Protocol o Protocolo Simple para Transferencia de Correo), siguen siendo prácticas habituales de pruebas de software. Sin embargo, el uso de un servidor real conlleva el riesgo de que los correos electrónicos de prueba se acaben enviando a personas reales y a menudo complica las pruebas de integración automatizadas. Hemos observado casos de éxito usando un servidor falso SMTP para probar envíos de correos electrónicos, el cual registra una petición de envío de correo electrónico sin llegar a enviarlo realmente. Existen múltiples herramientas de código abierto en este ámbito, incluyendo fake-smtp-server, el cual representa correos electrónicos dentro de una interfaz de usuario web para pruebas visuales, y mountebank, que expone los correos electrónicos enviados a través de una API REST para realizar pruebas de integración. Recomendamos explorar esta técnica para reducir el riesgo y mejorar la eficiencia de las pruebas.

  • Recientemente estamos observando proyectos de clientes que usan Machine Learning federado (ML). Tradicionalmente el entrenamiento de modelos de ML ha requerido que los datos se coloquen en una ubicación centralizada donde ejecutar el correspondiente algoritmo de entrenamiento. Esto es problemático desde el punto de vista de la privacidad, especialmente cuando los datos de entrenamiento contienen información confidencial o de identificación personal. Los usuarios pueden ser reacios a compartir datos o la legislación local de protección de datos nos puede impedir moverlos a una ubicación centralizada. El ML federado es una técnica descentralizada para entrenar un conjunto grande y diverso de datos que permite que éstos permanezcan remotos, por ejemplo, en el dispositivo de un usuario. El ancho de banda de la red y las limitaciones computacionales de los dispositivos aún presentan desafíos técnicos significativos, pero nos gusta la forma en que el ML federado deja a los usuarios en control de su propia información personal.

  • Hemos estado escribiendo sobre plataformas para desarrolladores y cómo construirlas en prácticamente todas las ediciones del Radar desde 2017. Mientras tanto, el libro Team Topologies también ha hecho un gran trabajo al describir el ideal de una plataforma que apoya a los desarrolladores con "APIs de autoservicio, herramientas, servicios y conocimiento". Sin embargo, a menudo vemos equipos que se precipitan al perseguir esa visión de plataforma demasiado rápido. En su lugar, es clave la construcción de una plataforma de desarrollo incremental.Team Topologies recomienda esforzarse siempre por conseguir lo que ellos llaman la "Plataforma viable más fina" necesaria en cada etapa, donde la primera versión podría ser incluso sólo un conjunto de documentación en una wiki. El siguiente incremento podría aumentar el nivel de servicio al proporcionar plantillas o permitiendo a los equipos crear pull requests. Incrementos posteriores podrían entonces introducir APIs de autoservicio, pero sólo si aportan valor. En resumen, aunque hayamos advertido contra los modelos operativos de plataforma orientado a tickets, pasar de cero al autoservicio es el otro extremo. Hay que ir con calma, trata tu plataforma como un producto y constrúyela incrementalmente.

  • Desde que se introdujeron en el Radar en 2016, hemos visto la adopción generalizada de micro frontends para las interfaces web. Recientemente, sin embargo, hemos visto proyectos que amplían este estilo arquitectónico para incluir también micro frontends para aplicaciones móviles. Cuando una aplicación se vuelve lo suficientemente grande y compleja, es necesario distribuir el desarrollo entre varios equipos. Esto presenta una serie de desafíos en torno a la autonomía del equipo, las estructuras de los repositorios y los frameworks de integración. En el pasado hemos mencionado Atlas y BeeHive, pero estos marcos no lograron ganar tracción y ya no están en desarrollo activo. Otros enfoques más recientes son Tuist o el Swift Package Manager para integrar el trabajo de varios equipos en una sola aplicación. Pero, según nuestra experiencia, los equipos suelen acabar implementando su propio framework para la integración. Mientras que definitivamente vemos la necesidad de la modularidad en la ampliación de los equipos de desarrollo móvil, el caso de los micro frontends es menos seguro. Esto se debe a que, mientras que los micro frontends implican una correspondencia directa entre los equipos y las páginas o los componentes, esta estructura podría acabar desdibujando las responsabilidades de los contextos del dominio empresarial, aumentando así la carga cognitiva del equipo. Nuestro consejo es seguir los fundamentos de un diseño de aplicación correcto y limpio, abrazar la modularidad cuando se amplíe a varios equipos y adoptar una arquitectura de micro frontend sólo cuando los módulos y el dominio de negocio esten fuertemente alineados.

  • Las prácticas de observabilidad han trasladado la conversación de la monitorización de problemas bien entendidos a ayudar a localizar el origen de problemas desconocidos en sistemas distribuidos. Hemos visto casos de éxito sacando esa perspectiva fuera del entorno tradicional de producción al aplicar la observabilidad para los pipelines CI/CD para ayudar a optimizar cuellos de botella en el testing y los despliegues. Los pipelines complejos ofrecen fricción a los desarrolladores cuando su ejecución es muy lenta o no determinista, ralentizando el feedback y reduciendo la efectividad de los equipos. Además, su rol como infraestructura crítica de despliegue crea puntos de tensión durante períodos de despliegues rápidos, como les sucedió a diferentes organizaciones que respondían a la reciente vulnerabilidad de log4shell. El concepto de trazas se traslada bien a los pipelines: en lugar de capturar la cascada de llamadas a servicios, los spans hijos capturan información de cada fase de la construcción. Las mismas gráficas de cascadas usadas para analizar el flujo de llamadas en una arquitectura distribuida pueden ser efectivas para ayudarnos a identificar cuellos de botella en los pipelines, incluso las complejas con topologías fan-in y fan-out. Esto permite focalizar mucho mejor el esfuerzo en optimización. Aunque la técnica debería funcionar con cualquier herramienta de trazabilidad, Honeycomb soporta una herramienta llamada buildevents que ayuda a capturar la información de las trazas de los pipelines. Otra alternativa para abordar la captura de información ya expuesta de plataformas CI/CD, adoptada por la herramienta de código abierto buildviz (creada y mantenida por un Thoughtworker) permite investigación similares sin cambiar los pasos de configuración en sí.

  • Así como el software sigue creciendo en complejidad, la cantidad de amenazas en las dependencias de software se vuelve cada vez más difícil de proteger. Los niveles de la cadena de suministro para artefactos de software, Supply chain Levels for Software Artifacts o SLSA (pronunciado "salsa"), es un conjunto de guías seleccionadas por un consorcio para que las organizaciones se protejan contra los ataques a la cadena de suministro, guías que evolucionaron gracias a la dirección interna que Google ha estado utilizando durante años. Apreciamos que SLSA no se comprometa con una "bala de plata", es decir, un enfoque de solo herramientas para proteger la cadena de suministro, sino que proporciona una lista de verificación de amenazas y prácticas concretas a lo largo de un modelo de madurez. El modelo de amenazas es fácil de seguir con ejemplos de ataques del mundo real y los requisitos brindan orientación para ayudar a las organizaciones a priorizar acciones en función de los niveles de una robustez creciente para mejorar su posición de seguridad en la cadena de suministro. Desde que lo mencionamos por primera vez en el Radar, SLSA ha agregado más detalles sobre certificaciones de software con ejemplos para rastrear inquietudes como la fuente de compilación. Nuestros equipos han encontrado que SLSA logra un buen equilibrio entre asistencia de implementación y la conciencia de alto nivel sobre las amenazas alrededor de la cadena de suministro.

  • Con la presión continua para mantener los sistemas seguros y sin que se reduzca el panorama general de las amenazas, una Software Bill of Materials (SBOM) legible por una máquina puede ayudar a los equipos a mantenerse al tanto de los problemas de seguridad en las librerías de las que dependan. Desde que la Executive Order original fue publicada, la industria ha ganado claridad y entendimiento de lo que es SBOM y cómo crear uno; el Instituto Nacional de Estádares y Tecnología (INET), por ejemplo, ahora tiene más consejos específicos sobre como seguir con la norma. Hemos tenido experiencia en producción utilizando SBOMs en proyectos que van desde pequeñas compañías hasta en grandes multinacionales e incluso en departamentos gubernamentales, y estamos convencidos de que ofrecen un beneficio. Muchas organizaciones y gobiernos deberían considerar exigir SBOMs para el software que utilizan. La tecnica será fortalecida por nuevas herramientas que continuan apareciendo, como Android Firebase BOM que automáticamente alinea las dependencias de las librerías de una aplicación con las que aparecen listadas en la BOM

Evaluar ?

  • La sustentabilidad es un tema que exige la atención de las empresas. En el ámbito del desarrollo de software su importancia ha aumentado, y ahora estamos viendo diferentes formas de abordar este tema. Por ejemplo, en cuanto a la huella de carbono del software de construcción, recomendamos evaluar la eficiencia del carbono como una característica arquitectónica. Una arquitectura que tiene en cuenta la eficiencia del carbono es aquella en la que las elecciones de diseño e infraestructura se han hecho para minimizar el consumo de energía, por lo tanto, las emisiones de carbono. Las herramientas de medición y el asesoramiento en este ámbito están madurando, lo que hace factible que los equipos consideren la eficiencia del carbono junto con otros factores como el rendimiento, la escalabilidad, el costo financiero y la seguridad. Como casi todo en la arquitectura de software, esto debería considerarse una compensación; nuestro consejo es pensar en esto como una característica adicional en todo un conjunto de atributos de calidad relevantes que son impulsados y priorizados por los objetivos de la organización y no dejados a un pequeño grupo de expertos para reflexionar de manera aislada.

  • ¿Cómo te planteas la escritura de un buen código? ¿Cómo puedes juzgar si has escrito código de calidad? Como desarrolladores de aplicaciones, siempre estamos buscando reglas, principios y patrones que podamos utilizar para compartir un lenguaje y unos valores a la hora de escribir código simple y fácil de modificar.

    Daniel Terhorst-North ha hecho recientemente un nuevo intento para crear una lista de control para un buen código. Sostiene que, en lugar de ceñirse a un conjunto de reglas como SOLID, es más aplicable el uso de un conjunto de propiedades a las que aspirar. Ha ideado lo que llama las propiedades CUPID para describir lo que debemos hacer para conseguir un código "alegre": el código debe ser componible, seguir la filosofía Unix y ser predecible, idiomático y basado en el dominio.

  • La publicación accidental de secretos parece ser un problema perenne, y herramientas como Talisman aparecen para ayudar con este asunto. Hasta ahora, los usuarios de GitHub Enterprise Cloud que tuvieran una Advanced Security License (licencia avanzada de seguridad) podían habilitar el escaneo de seguridad de sus cuentas, de forma que cualquier secreto (API keys, access tokens, credenciales, etc.) que fuera accidentalmente incluido en un commit al que se le haya hecho push, activaría una alerta. Protección del push de GitHub da un paso más adelantándose a una etapa anterior del workflow de desarrollo, al bloquear y evitar que los cambios pasen a un push si se detecta la presencia de secretos. Pese a que esto requiere ser configurado a nivel de organización y aplica sólo a aquellos que posean las licencias requeridas, siempre se agradecen protecciones extra a la hora de evitar publicar los secretos.

  • En una aplicación centralizada, los datos del servidor son la única fuente de verdad: cualquier modificación de los datos debe pasar por el servidor. Los datos locales están subordinados a la versión del servidor. Esto parece una opción natural e inevitable para permitir la colaboración entre múltiples usuarios del software. La aplicación local-first, o local-first software es un conjunto de principios que permite tanto la colaboración como la propiedad de los datos locales. Prioriza el uso del almacenamiento local y las redes locales sobre los servidores en centros de datos remotos o en la nube. Técnicas como los tipos de datos replicados sin conflictos (CRDTs por sus siglas en inglés) y las redes peer-to-peer (P2P) tienen el potencial de ser una tecnología fundacional para hacer realidad el software local-first.

  • Tienda de métricas, a veces denominada como inteligencia empresarial “sin cabeza” (BI), es una capa que desvincula las definiciones de métricas de su uso en informes y visualizaciones. Tradicionalmente, las métricas eran definidas dentro del contexto de herramientas BI, pero este enfoque genera duplicación e incoherencias, ya que diferentes equipos los utilizan en diferentes contextos. Al desacoplar la definición en la tienda de métricas, obtenemos una reutilización clara y consistente en los informes de BI, visualizaciones e incluso analíticas integradas. Esta técnica no es nueva; por ejemplo, Airbnb introdujo Minerva hace un año. Sin embargo, ahora estamos viendo una tracción considerable en el ecosistema de datos y analítica con más herramientas apoyando con las tiendas de métricas fuera de la caja.

  • La interfaz de usuario orientada a servidor sigue siendo un tema candente de discusión en los círculos de aplicaciones móviles debido a que permiten a los desarrolladores aprovechar ciclos de cambio más rápidos sin contradecir las políticas de las tiendas de aplicaciones en torno a la revalidación de la propia aplicación. La interfaz de usuario orientada a servidor separa la representación (rendering) en un contenedor genérico en la aplicación móvil, de la definición de la estructura y los datos para cada vista, que es proporcionada por el servidor. Esto significa que los cambios que en su momento necesitaban pasar por la tienda de aplicaciones, pueden ahora ser logrados a través de cambios simples en las respuestas que envía el servidor. Mientras que algunos equipos muy grandes de desarrollo de aplicaciones móviles han logrado grandes resultados con esta técnica, también se requiere una inversión sustancial para construir y mantener su propio framework. Esta inversión requiere de un caso de negocio que la justifique. Mientras no se disponga de dicho caso de negocio, puede ser mejor proceder con precaución; de hecho, hemos podido experimentar planteamientos horrendos, y exageradamente configurables, que en realidad no ofrecían los beneficios prometidos.

    Pero con el respaldo de gigantes como Airbnb y Lyft, puede ser que veamos emerger frameworks útiles que ayuden a domar dicha complejidad. Estemos atentos.

  • Desde que Google popularizara por primera vez los Indicadores de Nivel de Servicio y los Objetivos de Nivel de Servicio (SLIs y SLOs respectivamente, por sus siglas en inglés) como parte de su práctica de Ingeniería de Confiabilidad de Sitios (SRE), las herramientas de observabilidad como Datadog, Honeycomb y Dynatrace comenzaron a incorporar la monitorización de SLO entre sus utilidades. OpenSLO es un estándar emergente que permite definir SLI y SLO en código, utilizando un lenguaje de especificación declarativo e independiente del proveedor, basado en el formato YAML utilizado por Kubernetes. Si bien el estándar aún es bastante nuevo, estamos viendo un impulso alentador, como la contribución de Sumo Logic con la herramienta slogen para monitorizar y generar dashboards. Estamos entusiasmados con la promesa de versionar las definiciones de SLI y SLO en código y actualizar las herramientas de observabilidad desde los pipelines de integración y despliegue contínuo del propio servicio que se está desplegando.

  • Durante nuestros debates para esta edición del Radar, surgieron varias herramientas y aplicaciones para la generación de datos sintéticos. A medida que las herramientas van madurando, hemos comprobado que el uso de datos sintéticos para modelos de prueba es una técnica potente y ampliamente útil. Aunque no pretenden sustituir a los datos reales a la hora de validar el poder de discriminación de los modelos de aprendizaje automático, los datos sintéticos pueden utilizarse en diversas situaciones. Por ejemplo, pueden usarse para evitar fallos catastróficos de los modelos en respuesta a sucesos que ocurren de forma excepcional o para testear las pipelines de datos sin exponer información personal identificable. Los datos sintéticos también son útiles para explorar casos límite que carecen de datos reales o para identificar el sesgo del modelo. Algunas herramientas útiles para generar datos son Faker o Synth, que generan datos que se ajustan a las propiedades estadísticas deseadas y herramientas como Synthetic Data Vault que pueden generar datos que imitan las propiedades de un conjunto de datos de referencia.

  • Seguimos entusiasmados con la técnica TinyML y la posibilidad de crear modelos de aprendizaje automático (ML, machine learning) diseñados para ejecutarse en dispositivos móviles y de baja potencia. Hasta hace poco, la ejecución de un modelo de ML se ha considerado computacionalmente costosa y en algunos casos, requería hardware específico. Si bien la creación de los modelos todavía se encuadra generalmente en esta clasificación, ahora pueden crearse dichos modelos de forma que se puedan ejecutar en dispositivos pequeños, de bajo coste y bajo consumo. Si ha estado considerando la posibilidad de utilizar ML pero pensaba que no era realista debido a las limitaciones de capacidad de cómputo o de red, entonces vale la pena evaluar esta técnica.

  • Cuando lo incluimos por primera vez en el Radar hace dos años, las credenciales verificables (CV) eran un estándar intrigante con algunas aplicaciones potenciales prometedoras, pero no eran ampliamente conocidas o comprendidas fuera de la comunidad de entusiastas. Esto era especialmente cierto cuando se trataba de las instituciones que otorgan credenciales, como los gobiernos estatales, que serían responsables de la aplicación de las normas. Dos años y una pandemia después, la demanda de credenciales electrónicas criptográficamente seguras, respetuosas con la privacidad y verificables por máquina ha crecido y, como resultado, los gobiernos están empezando a despertar al potencial de la CV. Ahora estamos empezando a ver cómo las CV aparece en nuestro trabajo para clientes del sector público. El estándar del W3C sitúa a los titulares de las credenciales en el centro, lo que es similar a nuestra experiencia cuando utilizamos credenciales físicas: los usuarios pueden poner sus credenciales verificables en sus propias carteras digitales y mostrarlas a cualquiera en cualquier momento sin el permiso del emisor de las credenciales. Este enfoque descentralizado también permite a los usuarios gestionar mejor y revelar selectivamente su propia información, lo que mejora en gran medida la protección de la privacidad de los datos. Por ejemplo, gracias a la tecnología de prueba de conocimiento cero, puedes construir una credencial verificable para demostrar que eres mayor de edad sin revelar tu cumpleaños. Es importante señalar que, aunque muchas soluciones de identidad descentralizada se basan en la tecnología blockchain, ésta no es un requisito previo para todas las implementaciones de la CV.

Resistir ?

  • El término "organización de equipos remotos" no sólo describe una estructura; sino que abarca múltiples patrones y variantes. Y muchos equipos han estado cambiando de patrones recientemente. Están saliendo del modo "todo el mundo siempre en remoto" al que les obligó una pandemia y pasando a un patrón de trabajadores satélites (a menudo rotativos), en el que parte del equipo está en un mismo lugar y otra parte está en remoto. Vemos que muchos de ellos no consideran correctamente lo que esto significa para sus formas de trabajo. Los trabajadores satélites sin formas de trabajo "nativamente remotas" son un retroceso hacia el privilegio de las prácticas co-localizadas. En una modalidad con trabajadores satélite, es importante seguir utilizando procesos y enfoques "nativamente remotos" por defecto. Por ejemplo, si la parte del equipo que se encuentra en el mismo lugar se une a una reunión, todos deben estar en sus computadoras portátiles individuales para participar en la colaboración digital o en el chat de la reunión. Los equipos deben ser conscientes del riesgo de excluir a sus trabajadores satélites y crear silos y sentimientos de exclusión. Si se sabe que siempre habrá al menos un miembro del equipo satélite, las formas de trabajo por defecto deberían asumirse como remotas.

  • El predominio de los equipos que eligen una aplicación de una sola página (SPA en inglés) cuando necesitan crear un sitio web, continua. Seguimos preocupados que las personas no reconocen correctamente a los SPA como un estilo arquitectónico; en su lugar, saltan inmediatamente a la selección de un framework. Los SPA incurren en una complejidad que simplemente no existe con los sitios web tradicionales basados en servidores: problemas como la optimización de motores de búsqueda, administración de historial del navegador, análisis web y el tiempo de carga de la primera página, todos ellos deben ser tomados en cuenta. Se requiere un análisis adecuado y la consideración de las ventajas y desventajas para determinar si esa complejidad está justificada por el negocio o por la experiencia del usuario. A menudo los equipos se saltan el análisis de compensación, ciegamente aceptan la complejidad de los SPAs por defecto aún cuando las necesidades del negocio no lo justifiquen. Aún vemos algunos desarrolladores que no conocen un enfoque alternativo porque han pasado toda su carrera usando un framework como React. Creemos que muchos sitios web se benefician de la simplicidad de la lógica del lado del servidor y estamos alentados por técnicas como Hotwire que ayudan a cerrar esa brecha con la experiencia de usuario.

  • El término "cloud native" se usó originalmente para describir arquitecturas con características que aprovechaban al máximo el alojamiento en la nube pública. Ejemplos de las mismas incluyen arquitecturas distribuidas compuestas por muchos pequeños procesos, stateless y colaborativos, y sistemas con altos niveles de automatización en la construcción, prueba y despliegue de aplicaciones. Sin embargo, estamos observando una creciente tendencia hacia los diseños cloud native superficiales que simplemente utilizan una gran cantidad de servicios propietarios de un determinado proveedor de la nube y se detienen ahí, sin revisar la naturaleza fundamentalmente monolítica, frágil o laboriosa de la aplicación en cuestión. Es importante recordar que las funciones serverless por sí solas no hacen que una aplicación sea más resiliente o más fácil de mantener y que la nube nativa es realmente una cuestión de diseño más que un conjunto de opciones de implementación.

 
  • techniques quadrant with radar rings Adoptar Probar Evaluar Resistir Adoptar Probar Evaluar Resistir
  • Nuevo
  • Modificado
  • Ningún cambio

¿No encontraste algo que esperabas ver?

Cada edición del Radar presenta noticias que reflejan lo que hemos encontrado durante los seis meses anteriores. Es posible que ya hayamos cubierto lo que buscas en un Radar anterior. A veces seleccionamos cosas simplemente porque hay demasiadas de las que hablar. También es posible que falte algún dato porque el Radar refleja nuestra experiencia, no se basa en un análisis exhaustivo del mercado.

 

¿No encontraste algo que esperabas ver?

Cada edición del Radar presenta noticias que reflejan lo que hemos encontrado durante los seis meses anteriores. Es posible que ya hayamos cubierto lo que buscas en un Radar anterior. A veces seleccionamos cosas simplemente porque hay demasiadas de las que hablar. También es posible que falte algún dato porque el Radar refleja nuestra experiencia, no se basa en un análisis exhaustivo del mercado.

 

Descarga el Radar Tecnológico Volumen 27

English | Español | Português | 中文

Mantente informado sobre Tecnología

 

Suscríbete ahora

Visita nuestro archivo y nuestros volúmenes previos