Técnicas del Radar Tecnológico que han durado en el tiempo

El Radar de Tecnología Thoughtworks está ahora en su décimo año, con la 22ª edición del Radar a punto de ser publicada. El Radar intenta resaltar y dar consejos sobre lenguajes, herramientas, plataformas y técnicas que son importantes en la industria de TI de hoy. Sin embargo, el Radar es sólo una instantánea en el tiempo: incluimos "blips" que son relevantes para cada publicación y, a menudo, los elementos que aún son útiles desaparecerán del Radar a medida que damos espacio a información más actualizada.

Mientras celebramos los primeros 10 años del Radar, encuestamos a Thoughtworkers para obtener sus opiniones sobre los buenos consejos más duraderos del Radar, independientemente de cuándo apareció. Aunque preguntamos acerca de todos los cuadrantes de radar, el cuadrante de "técnicas" apareció en gran parte de las respuestas. La subyacentes  tecnologías y plataformas pueden cambiar con el tiempo, pero las mejores técnicas, el "cómo" del desarrollo de software, tienden a mantenerse estables a largo plazo. Este artículo es un examen y una explicación de estas "técnicas duraderas" del Radar.

Una década de la industria TI

Es importante recordar de dónde (en el  tiempo) proviene el Radar. Mirando hacia atrás en la primera edición, presentamos artículos sobre Amazon EC2 y Google Wave. Uno de ellos sobrevivió, por supuesto, y el oro no, pero dado que mencionamos a EC2 específicamente, en lugar de tomar todos los servicios de Amazon y etiquetarlos como "AWS", le da una idea del estado de la industria en ese momento. En los últimos 10 años del Radar, se han creado una serie de historias, y las técnicas presentadas en el Radar están cercanamente relacionadas con esas historias.

El ascenso de la Nube

Probablemente la historia más obvia sobre la vida del Radar ha sido el surgimiento y el dominio de la computación en la nube. Cuando se creó el Radar por primera vez, la nube todavía estaba en su infancia. La "nube de cómputo elástica" de Amazon se usó como una forma de sobrevivir a los picos de demanda repentinos, como una startup que se hizo popular o que necesitaba una expansión de capacidad a corto plazo en caso de que su producto fuera presentado en el programa de Oprah Winfrey (este es un caso de uso real para un proyecto Thoughtworks). Pero la mayoría de los departamentos de TI operaban con infraestructura tradicional. VMware y la virtualización habían comenzado a incursionar, pero la mayoría de las organizaciones ni siquiera consideran mover sus aplicaciones, y especialmente sus datos, lejos de un centro de cómputo. Después de 10 años y aunque todavía hay algo de FUD alrededor del uso de proveedores en la nube, incluso las grandes organizaciones financieras están confiando el núcleo de de sus activos de  datos a la nube. Las fortunas de las principales empresas, incluida Microsoft, ahora depende del éxito de su oferta en la nube. La nube ha alcanzado la mayoría de edad y en muchas organizaciones la nube es lo predeterminado: si desea realizar un alojamiento en las instalaciones, necesita una excepción, no al revés.

Ágil se vuelve convencional

En el momento del primer Radar, el desarrollo de software Ágil se consideraba nuevo, de vanguardia y definitivamente arriesgado. Las metodologías en cascada y el gran diseño y planificación prevalecieron en toda la industria. Afortunadamente, la historia de TI en la última década también es la historia del surgimiento de Agile como una práctica de desarrollo convencional. Las organizaciones se han dado cuenta de que trabajar en iteraciones más cortas y regularmente "enviar" código (ya sea a un entorno de prueba o producción) y permitir que los usuarios comerciales cambien de dirección a mitad de camino conduce a un mejor software, usuarios finales más felices y más valor creado. Dos principios clave de Agile: que debe acortar los circuitos de feedback y descomponer los silos, se han extendido más allá del equipo de desarrollo y han comenzado a impactar a todo el departamento de TI e incluso a todo el negocio, reconfigurando a las empresas en torno a lo rápido que pueden experimentar y obtener datos y feedback acerca lo que están haciendo bien y mal.

La automatización libera el potencial de la Nube

En los primeros días de la nube, la mayoría de las organizaciones usaban un hosting local. Algunos habían comenzado a moverse del alojamiento "en los fieros" a VMware u otra tecnología de virtualización, pero incluso si la infraestructura era virtual, los procesos que rodeaban las máquinas eran muy tradicionales. Los equipos de operaciones aprovisionaron ligeramente servidores más rápidos porque podían hacer clic en un botón en lugar de esperar por el hardware físico, pero luego instalaban y parchaban manualmente los sistemas operativos y el software, enviaban requerimientos al equipo de la Red para obtener una dirección IP y lo entregaban al equipo de seguridad para ellos hacer su trabajo.

Nada de esto funcionó muy bien cuando se trataba de computación en la nube. El Elastic Load Balancer (ELB) de Amazon, la tecnología central que permitía sobrevivir ser 'Slashdotted', funcionó haciendo girar nuevas instancias de máquinas virtuales basadas en imágenes de disco. Las instancias necesarias para iniciarse automáticamente, configurarse automáticamente y unirse a un conjunto de trabajadores en función de una sola señal de "marcha" desde el equilibrador de carga. Este fue uno de los impulsores clave del movimiento de automatización y DevOps: la nube solo tenía un 10% de efectividad sin una fuerte automatización, y había un límite en la gran cantidad de máquinas virtuales que se podía administrar manualmente. A escala, las compañías como Netflix no podían permitirse tener la proporción tradicional de un operador por cada 10 servidores y necesitaban desarrollar la automatización para que un solo operador pudiera administrar cientos o incluso miles de máquinas virtuales.

Entrega Continua y DevOps

Con el surgimiento de Agile como metodología convencional, las pruebas automatizadas también se convirtieron en la corriente principal. Ya no era aceptable que un "guión" de prueba fuera un conjunto de pasos en una hoja de Excel que un humano necesitaba seguir y firmar que el software estaba listo para la producción. El éxito de Ágil se basa en una red de seguridad de pruebas automatizadas que pueden ejecutarse de fin a fin, probando en lo pequeño y en lo grande, simulando las interacciones de los usuarios y las fallas de infraestructura, y certificando que el software hace lo que se supone que debe hacer en una amplia gama de escenarios.  Los equipos utilizaron servidores de integración continua (CI) para construir y probar su software, y no pasó mucho tiempo antes de que estas técnicas se extendieran a su conclusión natural: una "pipeline" automatizada desde el cambio de código hasta la implementación de producción, con equipos capaces de poner el software en producción a voluntad, conocida como entrega continua (CD).

Aquí, el movimiento cultural DevOps estuvo a la vanguardia para lograr que los desarrolladores piensen más como operadores y que los operadores piensen más como desarrolladores. Eso no quiere decir que el desarrollo u operaciones sean intercambiables o que un equipo no deba contener personas con experiencia específica en esas áreas; DevOps es un cambio cultural para revertir deliberadamente la mentalidad de "tirarlo por sobre la pared" y la cultura de culpar que ha existido durante muchos años.

Podemos parecer un poco pedantes aquí, pero es importante tener en cuenta que la integración continua, la entrega continua y DevOps son cosas diferentes. Si utiliza términos como "CI / CD" o "equipo de CD / DevOps" puede significar que está confundido acerca de lo que específicamente está tratando de lograr. CI, CD y DevOps están relacionados entre sí y se apoyan mutuamente, pero son cosas fundamentalmente diferentes.

Transformación al negocio Lean

Thoughtworks se involucra con muchas iniciativas de "transformación Ágil". Nuestros clientes a menudo intentan transformar su departamento de TI, o "ir a Ágil" u otras variaciones sobre el tema. ¿Pero con qué fin? ¿De qué sirve un departamento de TI que pueda desarrollar rápidamente software de alta calidad si ese software resulta ser incorrecto para el negocio? Una historia general, especialmente de los últimos años, ha sido el surgimiento del negocio “Lean”. Esta es una organización con un enfoque centrado en el valor del cliente en toda la empresa, con la capacidad de entregar software en producción en pequeños pedazos, medir el valor y después duplicar los experimentos que están teniendo éxito mientras elimina cosas que no son. Se han escrito libros completos sobre este tema, pero la integración de la tecnología y los enfoques iterativos en el mundo de los negocios ha sido transformadora y continúa hasta nuestros días.

Juntando todo

La última década contiene muchas historias, pero las que consideramos más importantes son el surgimiento de la nube, la "integración" del desarrollo de software Ágil, el surgimiento de la automatización, la invención de la entrega continua y la introducción de la cultura DevOps. Todos estos juntos hacen posible el Negocio Lean. El siguiente diagrama intenta mostrar algunas de las principales relaciones entre estas historias, así como técnicas específicas del Radar que formaron nuestra lista "más recomendada".

TI Ágil

El núcleo de Agile IT es por supuesto, la entrega de software Agile, y hay una gran cantidad de contenido sobre esto tanto de Thoughtworks como en la industria en general. Desde el Radar, las técnicas específicas que consideramos importantes incluyen:

• Prueba al nivel apropiado, incorporando pruebas unitarias, funcionales, de aceptación e integración para construir una pirámide de prueba efectiva, en lugar de probar todo a través de pruebas de IU que a menudo son lentas y frágiles.
• Coding Architects que trabajan con equipos y en realidad escriben software, en lugar de existir como "el Departamento de Arquitectura" en una torre de marfil que pontifica sobre las mejores formas de escribir software. Esto ayuda a los arquitectos a comprender el contexto completo de sus recomendaciones y lograr su visión técnica a largo plazo.
• Registros de decisiones de arquitectura ligera proporciona un rastro documental sobre decisiones importantes sin convertirse en otra pieza de documentación en un wiki que nadie lee.
• Si bien el código es maleable, las capas de almacenamiento de datos lo son tradicionalmente menos. La base de datos Evolutiva rechaza la noción de que un esquema de base de datos es fijo y difícil de cambiar y aplica técnicas de refactoring a nivel de base de datos. Esto permite que la base de datos evolucione de manera similar al código y evita un esquema que no coincida con la aplicación que lo utiliza.
• La arquitectura del software a menudo ha tratado de predecir el futuro, pero cualquiera que haya sido testigo de la explosión de Docker, Kubernetes o el fenómeno “JavaScript se come el mundo” se dará cuenta de que hacer predicciones más allá de unos seis meses es muy difícil. La Evolutionary Architecture acepta esta realidad y, en cambio, se enfoca en crear sistemas susceptibles de cambio en el futuro. La creación de funciones de aptitud arquitectónica para describir las características ideales del sistema es el motor que impulsa esta técnica general.
• Una tendencia significativa en las organizaciones modernas, incluso más allá del departamento de TI, es tratar los activos, como el software y los servicios, como productos, en lugar de proyectos. Este es un tema profundo y un buen lugar para comenzar es el articulo general de Sriram Narayan. Una técnica de aplicando la gestión de productos a plataformas internas, y el artículo Evan Bottcher’s tiene buenos detalles sobre lo que esto podría significar para usted.
• Hemos adquirido más comprensión en los últimos años sobre cómo se aplica la  ley de Conway  en una organización y cómo afecta a los sistemas y estructuras que construimos. ¿Pero qué pasa si no tienes la arquitectura que quieres? Una estrategia es aplicar la maniobra inversa de Conway, estructurar equipos para reflejar los sistemas que aspira a tener y dejar que la Ley de Conway reestructure esos sistemas por usted.

Entrega continua

La premisa de la integración continua era bastante radical hace 10 años: cada cambio realizado por cada desarrollador de software debería construirse e "integrarse" frente a todos los demás cambios, todo el tiempo. La entrega continua llevó esta técnica aún más lejos al decir que cada cambio en el software debería ser desplegable en producción en cualquier momento. Jez Humble y David Farley escribieron el libro canónico de entrega continua, y el enfoque ha tenido una adopción significativa.

• La entrega continua se centra en el concepto de la implementación de pipeline automatizado que toma los cambios desde la estación de trabajo de un desarrollador hasta   la liberación en producción. La configuración del pipeline idealmente  debe ser un recurso controlado y versionado, usando pipelines como código.
• Para lograr la entrega continua, un número de técnicas necesitan ser unidas:
• Automate database deployment para garantizar que las actualizaciones de las BD coincidan correctamente con el código.
• Utilizar Consumer-driven contract testing para permitir que muchos equipos colaboren sin detenerse entre sí o crear cuellos de botella.
• Desacoplamiento de la implementación de liberación permite que el código permanezca en producción sin estar activo, haciendo la liberación de una característica sea controlada por un interruptor de software.
• Entrega continua para dispositivos móviles nos permite aplicar técnicas de entrega continua incluso para aplicaciones nativas.
• Phoenix Environments es una técnica para derribar y destruir deliberadamente un entorno completo(desarrollo, pruebas o incluso producción) antes de recrearlo desde cero. Esto ayuda  a garantizar que el nuevo entorno se cree exactamente como se describe dentro de un marco de infraestructura como código y no contiene un inesperado cuelgue o incorrecta configuración.
• Implementación azul-verde permite a un equipo implementar actualizaciones en vivo de su software pero primero creando un clon de configuración en producción, desplegando una nueva versión para el clon, cortando el tráfico en vivo y limpiando la antigua versión. 
• Administrar dependencias de tiempo de compilación puede ser complicado.  Una técnica para hacerlo más fácil es usar Docker para compilaciones, corriendo el paso de compilación en un entorno aislado. 
• Muchos equipos han dominado la entrega continua, pero con el despliegue continuo, cada cambio que resulta en una compilación aprobada también es desplegada automáticamente en producción. 

DevOps

La entrega de software tradicional enfrenta distintos problemas en la “última milla” del sacar el software del desarrollo, ponerlo en producción y después ejecutarlo operacionalmente. Los problemas provienen de equipos completamente diferentes haciendo desarrollo y operaciones con medidas diferentes para su éxito. Generando mucha fricción y animosidad entre los dos. 

• DevOps es un movimiento cultural que trata de unir las dos partes y tener desarrolladores que puedan pensar más como una persona de operaciones, y las personas de operaciones que piensen un poco más como desarrolladores.  Hay muchas sutilezas en el camino correcto para hacer esto, y varios antipatrones en la industria(como un “equipo de DevOps”) pero la clave es crear más empatía entre los dos.
• El libro seminal Accelerate identifica Cuatro métricas claves como identificadores del rendimiento de TI. Mejorar el tiempo de respuesta, frecuencia de despliegue, la tasa de fallas de cambios y el tiempo medio de recuperación mejoran directamente el rendimiento de TI, y estas son generalmente las métricas mejoradas  exactas por la adopción de DevOps dentro de una organización. 
• Centrarse en el tiempo medio de recuperación es una instancia específica de preocuparse acerca de las métricas claves, y los consejos que dimos antes de que Accelerate estuviera disponible.
• Registro estructurado es una técnica para mejorar los datos que obtenemos de los archivos de registro,  mediante el uso de un enfoque sistemático para registrar mensajes. 
• Automatización de pruebas técnicas permite a una organización tomar “operacional ” o pruebas de estilos multifuncionales como failover  y recuperación, y automatizar esas pruebas. 
• Las técnicas para software son relativamente conocidas y están cubiertas en la sección de entrega continua  este artículo. Pero las organizaciones que  están almacenado la configuración de infraestructura como código también puede probar esa infraestructura: Pipelines para infraestructura como código es una técnica que permite encontrar errores  antes de aplicar los cambios de infraestructura aplicados a producción.

La Nube

Está claro que el futuro de la infraestructura es la nube. Las organizaciones generalmente no pueden competir  con la capacidad operativa de clase mundial de los principales proveedores de la nube, todos los cuales compiten para proporcionar cada vez más conveniencia y valor para sus clientes. Si bien el uso efectivo de la nube es un gran tema, pensamos que hay al menos dos consejos duraderos en el Radar.

• Microservicios son la primera arquitectura “nativa de la nube”, nos permite reducir la complejidad de desarrollo de cada componente por una mayor complejidad operativa del sistema en general. Para que los microservicios tengan éxito, requieren la nube para hacer que valga la pena. Al igual  que cualquier estilo popular arquitectónico  hay muchas formas  de mal uso de microservicios, y advertimos a los equipos sobre microservice envy, pero son un defecto arquitectónico razonable  para la nube.
• Con múltiples dispositivos cliente y sistemas consumidores, puede ser tentador intentar crear una única API que funcione para todos ellos. Pero las necesidades del cliente varían, y BFF(Backend for Frontends) es un enfoque que en su lugar crea una capa de traducción simple que permite que muchos tipos diferentes de clientes accedan a una API eficientemente. 

Seguridad

Con una dependencia cada vez mayor de la tecnología, consumidores y empresas confían cada vez más y más en los sistemas de software, crean valiosos, y útiles tesoros de datos. Desafortunadamente, la seguridad ha sido dejada de lado  e implementada pobremente, en parte porque el costo de las medidas de seguridad se pagan por adelantado, pero solo se obtiene un beneficio dudoso(¿fuimos hackeados?) es siempre obtenido de esos costos. Las organizaciones que  han sido o permitido deliberadamente  que los datos de los clientes se usen de manera nefasta han sufrido pocas consecuencias a largo plazo. Si bien esto suena como pesimismo, la buena noticia es que la conciencia del consumidor sobre los problemas de seguridad y privacidad está en aumento y los gobiernos están creando legislaciones para proteger mejor los datos. Abogamos por un enfoque para “incorporar seguridad” a los productos de software en lugar de tratarlo como una opción o una idea de último momento.  Pensamos que las siguientes técnicas son particularmente importantes:

• Modelando amenazas es un proceso específico que los equipos pueden seguir al crear requisitos para el software que construyen, identificando exactamente  qué amenazas son más importantes y  de las que vale la pena defenderse.
• Desacoplando la administración secreta del código para el código fuente y usar Secretos como un servicio ayuda a evitar la situación cuando un desarrollador agrega accidentalmente credenciales en(digamos) un repositorio de GitHub, haciéndolos visibles cuando no deberían.

Conclusión

Ha sido un recorrido audaz para el desarrollo de software en la última década. Cada vez más, la tecnología es el negocio, y tanto las personas de tecnología como los empresarios deben avanzar rápidamente para mantenerse al día, Las técnicas sobre lo que hemos escrito pueden ayudar, y esperamos que  duren por lo menos durante parte de la próxima década también. Esperamos que sigas leyendo y disfrutando del Radar mientras mantenemos el pulso de lo que vendrá después.