He sido invitado esta semana a un evento con mesas redondas entre usuarios expressando sus problemas en el mundo del Cloud y de la virtualización.

Me enteré no sólo de muchas cosas, pero sobre todo descubrí la visión de la producción sobre la calidad de las aplicaciones.

Aviso a los equipos de desarrollo: pan para hoy, mañana…

Como probablemente sabes, la razón principal por la cual las empresas se mueven desde la infraestructura física a una infraestructura virtual se encuentra en la reducción de costes. No te puedes – bueno yo no podía – imaginar la cantidad de servidores en cualquier organización, que no utiliza el 5% de su CPU. Esta subutilización representa con frecuencia entre el 20% y el 40% de la infraestructura. El cálculo es simple: si decides usar menos del 50% de los recursos de la CPU para mantener la capacidad existente con el fin de manejar los picos de uso o poner en marcha una política de HA (High availability o alta disponibilidad), una ganancia de la mitad de la capacidad del 20% o 40% de las máquinas representa un potencial de reducción de 10% a 20% de las compras futuras.

En cambio, esta evolución se acompaña de una mayor complejidad para los equipos de producción:

• La mayoría de las empresas llegan a virtualizar el 50% de su granja de servidores, el 80% rara vez, nadie es 100% virtual.
• La racionalización no está en el orden del día: equiparse de servidores de un constructor único, de los mismos sistemas virtuales o de OS sería una manera de limitar los gastos de funcionamiento. Sin embargo, los departamentos de TI prefieren poner en competición a constructores y editores de software con el fin de bajar los costes.

La virtualización se acompaña de una fuerte heterogeneidad de la infraestructura, tanto física como virtual, y crea silos de tecnología de hardware / software que requieren una especialización muy importante de los equipos de producción. Ningún ingeniero sistema es capaz de controlar todo el entorno y resolver todos los incidentes que puedan ocurrir.

Mientras tanto, la virtualización provoca un requisito de servicio superior:

• Antes, si se necesitaba un nuevo servidor para un nuevo proyecto, la respuesta era: » Dentro de 1 mes, el tiempo que se entrega una nueva máquina «. Ahora, instalar una nueva VM (máquina virtual) se hace con tres clicks de ratón, pues la demanda se hace de la noche a la mañana y no se entiende bien si no se consigue satisfacción rápidamente. Time to market llega cada vez más a las salas de producción.
• Antes, si tu servidor encontraba un problema de rendimiento, era tu servidor, bajo tu responsabilidad, y tenías que investigar y resolver este problema. Ahora, es la culpa de la máquina virtual.

Así como acabamos de verlo, los equipos de producción son mal equipados para hacer frente a la complejidad inducida por la heterogeneidad. De donde viene el problema: ¿de una saturación CPU o de memoria o de un disco duro? Para entenderlo, debemos reunir al ingeniero sistema especialista de tal tipo de máquina virtual, del especialista de tal sistema operativo sobre tal hardware. Y el problema puede provenir de una otra aplicación en una otra VM en el mismo servidor. Hay que desarrollar y mantener scripts para recuperar las métricas adecuadas, generalmente no muy comparables entre los diferentes sistemas y pasar tiempo en colecta y análisis de estos datos. El seguimiento de alertas y la gestión de los incidentes se han convertido en una preocupación superior en las salas informáticas.

Así que la virtualización permite ganar en optimización de la infraestructura pero resulta en:

• Una inflación de máquinas virtuales y del almacenamiento pues en definitiva un crecimiento de la infraestructura.
• Gastos de explotación siempre más elevados.

¿Hay sólo los proyectos de desarrollo que se miden en día/hombre? No, el número de VMs también. Vas a decirme: » ¿Que hay de la calidad de los desarrollos en todo esto? «.

Es muy sencillo. Cuando las ganancias en reducción de costes de infraestructura están siendo superadas por el incremento en el gasto de siempre más hardware para sostener siempre más las demandas de los usuarios y la cargas crecientes de mantenimiento y de resolución de incidentes, la respuesta de las direcciones informáticas se convierte en ‘Stop’. Algunas declaraciones recogidas durante el evento:

• El equipo del proyecto que solicita un servidor de base de datos nuevo y no lo usa: Stop.
• El equipo de QA que requiere una base de pruebas idéntica a la de producción, pues otros 800 Go de disco duro: Stop. Volved a aprender a programar datos de pruebas.
• Los directorios enteros de datos abandonados y que ningún programa sabe leer, los archivos de Excel que ya no se sabe a lo que corresponden, los usuarios que no saben cual es la duración reglamentaria de conservación de los datos, todas las aplicaciones que se conservan porque no se sabe reciclar los datos: Stop.

Y guardo el mejor para el fin. Planteé una cuestión estúpida: » ¿Existen unas tecnologías más consumidoras en capacidad que otras? «. Pensaba que las bases de datos, el datamining y los infocenters eran más consumidoras que otras. Me mirraron con incomprensión.

Luego la respuesta llego: » No existe mala tecnología, sólo existe código malo «.

• La aplicación J2EE cuyos escapes de memoria saturan la VM y sus vecinas en el servidor: Stop.
• El query SQL que crea panica en las cabezas de lectura del disco duro: Stop.
• Los tratamientos costosos en bucles: Stop.

Se usan más y más las herramientas para controlar toda la cadena de principio a fin, desde el hardware hasta la aplicación, e identificar los procesos técnicos que saturan las máquinas virtuales. Y los ingenieros de sistemas están empezando a mirar a las herramientas de calidad del código.

No hay tecnología mala, sólo código malo. Pan para todos hoy. Mañana…

Esta entrada está disponible también en Lire cet article en français y Read that post in english.