El dinero, como la materia, ni se crea ni se destruye, solo se transforma. Ni siquiera con blockchain podemos inventar el dinero (aunque sí reinventarlo). Pero no vamos a hablar de la cadena de bloques en este post, sino de automatización aplicada a la gestión de la infraestructura TI. Y es que nuevos paradigmas, como la infraestructura como código (Infraestructure as Code o IaC) están provocando cambios significativos en los procesos de su gestión. En este artículo os propongo un acercamiento al mundo de la IaC y de la automatización de la TI desde un punto de vista práctico, organizativo y económico, desde la experiencia que aporta de un entorno muy propicio para la automatización como es del tratamiento masivo de datos.
Las empresas se están convirtiendo en software
Jay Creps, uno de los tres creadores de Apache Kafka y actual CEO de la empresa Confluent (un muy reconocido software de procesamiento de eventos en streaming con una gran adopción en entornos de big data y epicentro tecnológico de la llamada arquitectura Kappa de streaming de datos), señalaba hace unos días en un interesante artículo que las empresas se estaban convirtiendo en software.
Creps afirma que el software ha pasado de ser un instrumento de mejora de la productividad a convertirse directamente en un elemento que implementa por completo un proceso de negocio: “Companies aren’t just using software as a productivity aid for human processes, they are building out whole parts of the business in code.” Según Creps, estamos codificando nuestros negocios. Y no le falta razón. No solo eso, sino también nuestras vidas. Pero ¡ojo! sigue habiendo cosas que no se pueden codificar, como el dinero, la empatía, la confianza, el amor o el alma. Al menos, de momento. Es necesario acompasar la automatización de procesos y tareas con cambios culturales e incluso organizativos y tener en cuenta en todo momento los efectos colaterales, a menudo ocultos y no planificados.
La informática es el instrumento para automatizar los procesos de negocio, pero ¿quién automatiza a la informática?, ¿puede un peluquero cortarse el pelo a sí mismo o un médico autodiagnosticarse?
Entornos propicios para la automatización
Ya no basta con tener interfaces y API para poder programar la infraestructura. Queremos gestionarla de forma sencilla. Y, para ello, qué mejor que ofrecer a los informáticos para que gestionen su infraestructura la programación, que es un recurso que ya conocen. Así surge el paradigma Infraestructure as Code (IaC) y las herramientas de automatización de configuración continua o Continuous Configuration Automation (CCA). En el mundo TI ya son muy conocidas herramientas como Ansible, Puppet o Chef así como diferentes plataformas de gestión en la nube o CMP. Pero esta automatización no es exclusiva del mundo TI, también ha llegado con fuerza a los entornos de telecomunicaciones de la mano de la virtualización de la red y NFV. Tecnologías como Open MANO, ONAP o TOSCA aparecen para modelar y automatizar los despliegues de servicios de red e infraestructuras. No vamos a profundizar en estas tecnologías sino, como explicaba al principio, hacer un acercamiento práctico, organizativo y económico.
Cualquier entorno de infraestructuras es susceptible de someterse a las mejores prácticas de la IaC y la automatización. No obstante, algunos son más propicios que otros. En mi opinión, tres factores fundamentales caracterizan a los entornos más propicios:
- Gran volumen de infraestructura. Para que automatizar algo no sea un esfuerzo inútil, tiene que haber tareas repetitivas, muchos elementos similares que gestionar.
- Alto ritmo de innovación. En entornos donde la innovación es muy alta, la probabilidad de que se ejecuten despliegues “a mano” no controlados por parte de administradores o usuarios avanzados, es elevada. La IaC ayuda a sacarlo a la luz y tener orden.
- Necesidad de estandarización. Al contrario que en Telecomunicaciones, en TI no existen organismos internacionales que estandaricen el uso de las tecnologías. Esto obliga a cada organización a crearse sus propios estándares, normativas y arquitecturas de referencia. Tradicionalmente esta normativa se implementaba en documentos que, con los años, acababan desactualizados en algún rincón perdido de la Intranet de usuarios. La IaC convierte ese documento que nadie leía en un proceso tecnológico que gobierna la infraestructura y asegura su cumplimiento.
Dado que ni un entorno mainframe ni un sistema UNIX legado cumplen los requisitos anteriores no son adecuados para obtener los beneficios de IaC. Una red de telecomunicaciones, por ejemplo, reúne las dos primeras condiciones pero, al tener estándares y arquitecturas muy claras y regladas, hay mucho más orden que en la TI y los procesos de creación de red están muy consolidados. Los entornos de business intelligence y big data son los más idóneos, pues reúnen las tres características, por ello la IaC suele aparecer de forma casi espontánea desde el inicio de estos proyectos
La infraestructura como código en la cuarta plataforma de Telefónica
En los entornos BI y big data de Telefónica se vienen utilizando con éxito los paradigmas de automatización de forma nativa. Los despliegues físicos de infraestructura se automatizan con herramientas de gestión de clúster (ej. CMU de HPE). Para bastionados de sistemas de big data hace tiempo que se emplean tecnologías como Puppet o similares propietarias de proveedores. Y para los servicios IaaS generalistas se usan las tecnologías de automatización que ofrece su propio servicio VDC. El despliegue de pequeños agentes de monitorización y supervisión también se centralizan con Ansible. Los despliegues de infraestructura y aplicaciones nativas en cloud pública se realizan mediante Ansible y las API de los proveedores cloud.
Así, la cuarta plataforma de Telefónica se despliega en poco tiempo, un tiempo que se multiplicaría por diez o por quince sin estas tecnologías. El trabajo de dos o tres días se alargaría a varios meses. Esto, lógicamente, se traduce en una reducción directa de costes pero el ahorro más interesante es el que se produce a largo plazo, como efecto del mantenimiento de una arquitectura ordenada, como permite la IaC. La cuantía es difícil de tangibilizar pero esa arquitectura ordenada es vital.
Seis reglas para una correcta automatización
Sin duda, la automatización y la IaC aportan numerosas ventajas, pero hay que aprender a utilizar estas tecnologías de forma adecuada porque también se producen efectos colaterales no previstos que deben considerarse:
- Infraestruture as code es sinónimo de money as code. La primera regla que hay que tener en cuenta es que los cambios en la infraestructura a menudo pueden tener impacto en los costes. En los entornos de cloud pública esto es inmediato y la factura mensual se incrementa. Los CIO suelen entender bien las ventajas de la IaC pero no los CFO. Una tecnología que puede disparar el OPEX de forma incontrolada está condenada al fracaso, por eso hay que planificar los costes con mucha cautela. Un entorno on premise tampoco se libra de este problema, ya que los costes de licencias software pueden cambiar simplemente variando los núcleos de una máquina virtual. El control de licencias debe ser riguroso mediante herramientas de autodescubrimiento de infraestructuras.
- Para controlar los costes, que pague la fiesta el que diseña. En la medida en que la infraestructura tiene impacto directo en los costes, la forma más práctica de que este control de costes se ejecute es que pague la factura quien diseña la automatización. Cuanto más alejados estén organizativamente los centros de coste del que diseña y del que paga, más desalineamiento habrá.
- Automatización horizontal versus vertical: no es lo mismo automatizar una tarea que una persona repite cien veces (automatización vertical,) que automatizar una tarea que repiten cien personas una vez (automatización horizontal). En el primer caso el ahorro es inmediato y directo. En el segundo, aparecerán costes ocultos de formación, soporte, gestión del cambio cultural e incluso se llegará a poner en cuestión las ventajas que aporta la IaC.
- No hay que confundir informático con programador. La IaC está pensada para facilitar la las tareas que venía haciendo un administrador informático. Por eso, si se pone a un programador informático a codificar el trabajo del administrador hay que procurar que conozca su trabajo porque el programador conoce la tecnología pero no los procesos para gestionarla así que no caerá en la cuenta de que hay que tener backup, monitorización, inventarios, auditorías, control de calidad, gestión de ventanas de cambio, etc.
- Las tuberías comunicantes. Una automatización de tareas en un punto de un proceso puede ocasionar a posteriori un serio problema en otro lugar de la cadena, de la misma forma que una subida de la presión en una tubería puede causar una fuga en un grifo del sótano. Por ejemplo, si el ritmo de despliegue pasa de uno al mes a uno a la semana podría generar un cuello de botella al equipo de certificación y pruebas. Es importante, por tanto, dimensionar todo con una visión extremo a extremo del proceso, aunque a menudo es complicado que haya gente con esa visión completa.
- Antes de automatizar, repítelo tres veces. Aunque parezca una obviedad, conviene no automatizar nada que antes no haya repetido uno mismo de manera manual tres veces. Es la mejor manera de comprobar dónde está el problema de lo que hay que automatizar.
En definitiva, la receta para minimizar estos riesgos consiste en planificar, planificar, planificar y en aplicar el sentido común, que es el menos común de los sentidos. ¿Podremos automatizar alguna vez el sentido común?
Imagen: txmx2
The post Infraestructura como código, sinónimo de dinero como código appeared first on Think Big.