By Mike Mason
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).
