Trata también tu código de automatización de TI como ganado.

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

El departamento de TI debe adoptar la estandarización del código que sustenta su funcionamiento o se arriesga a crear sistemas que menoscaben los beneficios económicos y de eficiencia de la automatización de TI.

Pasé casi una década desarrollando software. Software embebido. Software web. Software cliente-servidor. Middleware y software para mainframes. A lo largo de mi carrera, he escrito código en nueve lenguajes distintos. Lo curioso es que no recuerdo haber utilizado más de dos lenguajes en una misma organización.

La mayoría de las organizaciones empresariales estandarizan no solo los servidores, las plataformas y los frameworks, sino también los lenguajes. El objetivo es garantizar la mantenibilidad de un software cuya vida útil no se limita a unos minutos y que, en ocasiones, se mide en décadas. La mantenibilidad es la característica que permite que otra persona pueda hacerse cargo del software y mantenerlo durante todo su ciclo de vida, independientemente de cómo se mida su duración. Esto suele deberse a la rotación de desarrolladores, a la disponibilidad en el mercado de profesionales que dominen el lenguaje y a los costes de formación y mantenimiento general. Por regla general, las empresas estandarizan los lenguajes de programación.

Eso es contrario a las tendencias actuales en microservicios y computación sin servidor, que presentan como ventaja la capacidad de admitir un conjunto muy diverso (políglota) de lenguajes. Bob y su equipo pueden programar en Go, mientras que Alice y el suyo desarrollan en C, Java o Lambda. Aunque sin duda supone una ventaja para los desarrolladores (cada uno tiene su lenguaje favorito), no resulta tan beneficioso para las organizaciones empresariales que necesitan mantener ese software a lo largo del tiempo. Las API permiten integrarlo y utilizarlo, por lo que su lenguaje de implementación resulta en gran medida irrelevante para el desarrollo de aplicaciones; sin embargo, en una empresa, el código subyacente sigue necesitando mantenimiento.

En lo que respecta a la automatización de TI —la transformación digital interna que se está produciendo en el área de producción de la empresa—, es importante que las organizaciones reconozcan no solo las ventajas de estandarizar los scripts y sistemas que se están creando para respaldarla, sino también los riesgos de no hacerlo. Porque estos sistemas no se crean con la intención de desecharlos la semana que viene, el mes que viene ni siquiera el año que viene. Son una inversión a largo plazo que respaldará la digitalización de los despliegues durante muchos años. Esto implica establecer unos cimientos flexibles pero sólidos, basados en las mejores prácticas adquiridas durante décadas por los equipos de desarrollo de aplicaciones de empresas de todo el mundo, la primera de las cuales es la estandarización.

1. Mantenibilidad

Sé que te gusta programar en PERL, pero todo el mundo usa Python. Desarrollar automatizaciones en tu lenguaje favorito las convierte en tu mascota, lo que significa que nadie más podrá mantenerlas en el futuro. Eso es malo para ti, porque tendrás que cargar con ellas durante años, como con aquel pez de colores que les suplicaste a tus padres que te compraran cuando tenías ocho años. También es malo para la organización porque, si te marchas, se quedará con un código que no puede mantener y al que quizá le resulte difícil dar soporte. Una encuesta realizada en 2016 por SIG y O’Reilly reveló que «el 70 % de los encuestados considera que la mantenibilidad es el aspecto más importante del código que debe medirse, incluso por encima del rendimiento o la seguridad».

Así de importante es. Considere los scripts y los sistemas como recursos compartidos que la mayoría de los profesionales de TI puedan modificar y mantener fácilmente, tanto ahora como en el futuro.

2. Compatibilidad

A medida que cada vez más servicios de TI se implementan como software, aumenta la dificultad de mantenerlos actualizados y compatibles con otros sistemas. Si cree que las API REST eliminan el problema de la «compatibilidad con versiones anteriores», piénselo de nuevo. Las API son productos (o deberían serlo) y, por tanto, también evolucionan constantemente. Y la situación es aún peor en «la red», donde existen diferencias incluso dentro de una misma línea de productos, con API que varían de una versión a otra y convierten la estandarización en una tarea de Sísifo. Es un problema tan generalizado que la estandarización de las API ocupó el tercer puesto en la lista de retos tecnológicos que deben resolverse en los próximos años, según uno de cada cuatro encuestados en el informe State of API 2016 de Smart Bear.

Y dado que muchos de los lenguajes que utilizamos en TI son interpretados, los cambios entre versiones pueden echar por tierra sistemas y scripts de automatización cuidadosamente diseñados. Pasar de una versión de node.js a otra puede tener consecuencias muy negativas, desde hacer que un script deje de funcionar hasta provocar comportamientos inesperados. La estandarización en versiones estables de lenguajes y entornos de scripting ayudará a minimizar el impacto de estos cambios.

Y aun así tendrás que gestionar los parches y las actualizaciones de cada sistema subyacente que sustenta esa automatización, así que cuantos menos haya, mejor.

3. Resolución de problemas

Renunciar a la estandarización supone complicar la resolución de problemas. Esto es especialmente importante si se está adoptando una métrica basada en el tiempo de resolución para los KPI de TI. Cuanto más se tarde en encontrar el problema, peor será el resultado de esa métrica. La estandarización es un factor importante para reducir el tiempo de resolución. Si Bob es el único experto en Python de la plantilla, está de vacaciones (y no se puede contactar con él) y su script falla, a quien se le asigne la tarea de resolver el problema le espera una semana muy larga. Cuando se anima al equipo de TI a utilizar su lenguaje favorito, se limita considerablemente la capacidad de los demás para diagnosticar y resolver problemas. Incluso si Bob no está de vacaciones pero no consigue encontrar el problema, habrá pocas personas que puedan ayudarle.

Este no es un aspecto con el que convenga jugársela. Según InitialState, se tarda 30 veces más en corregir un error que en escribir una línea de código. Puedes imaginar cómo el dinero va entrando lentamente en la trituradora mientras intentas encontrar un error en un código con el que no estás familiarizado y después corregirlo. No es una imagen agradable. No puedes eliminar el coste de la resolución de problemas, pero sí limitarlo eliminando el tiempo adicional que necesita alguien que, para empezar, no conoce el lenguaje. En producción, el tiempo es oro, así que cualquier medida que permita reducir el tiempo de resolución supone una gran ventaja.

Por eso, a medida que el departamento de TI va adoptando poco a poco lenguajes de scripting, herramientas y sistemas, no es mala idea coordinarse con el equipo de desarrollo de aplicaciones. Si TI se estandariza en torno a los mismos sistemas y lenguajes (o, al menos, algunos de ellos), dispondrás de todo un ejército de expertos capaces de ayudar a resolver problemas y colaborar en otros procesos relacionados con el desarrollo, como las revisiones de código. Porque estás utilizando las revisiones de código para detectar los errores antes de que causen problemas, ¿verdad? ¿Verdad?

La estandarización se cita como un medio para combatir el aumento de los costes y, sin duda, es un factor clave en este tipo de iniciativas. Pero también ofrece muchas otras ventajas, como minimizar la deuda técnica, reducir el tiempo de resolución y simplificar el mantenimiento operativo diario. La ausencia total de estandarización tiene, sin duda, el efecto contrario sobre los presupuestos y los plazos, ya que introduce complejidad y cuellos de botella que anulan las ventajas de la automatización e impiden que la empresa alcance la rentabilidad y la productividad que necesita para crecer. Al iniciar —o continuar— su proceso de automatización de TI, recuerde tratar esos scripts y sistemas más como ganado que como mascotas. Porque las mascotas requieren una atención constante y personalizada que TI no puede permitirse de cara al futuro.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie