Con el espectacular aumento y crecimiento de las plataformas (públicas) en la nube, se ha hecho posible cambiar radicalmente la forma de gestionar la infraestructura de TI. Pensemos, por ejemplo, en la Infraestructura como código.
Los componentes (servidores, redes) están disponibles de forma virtual, por lo que el montaje y desmontaje de los recursos requiere mucho menos trabajo.
Si antes los tickets se creaban con un gestor que luego pedía el hardware y, a veces, lo configuraba manualmente y lo ponía a disposición, ahora todo el proceso puede completarse con unos pocos clics y en sólo unos minutos.
Esta aceleración radical ha dado lugar a una forma diferente de abordar las infraestructuras. Dado que los costes (en tiempo y dinero) de creación y desmantelamiento de infraestructuras han disminuido considerablemente, se ha reducido el umbral para solicitar nuevas infraestructuras y desmantelar las antiguas.
Importante crecimiento del número de componentes infraestructurales
En muchos casos, el resultado es un gran crecimiento del número de componentes de la infraestructura, con una vida útil más corta por término medio. Además, la infraestructura puede ajustarse mucho mejor a las necesidades del momento, ya que ahora es posible realizar ajustes cuando se necesitan, en lugar de con mucha antelación.
¿Cuál es el inconveniente?
La combinación del crecimiento de la infraestructura y su ciclo de vida más corto también tiene un inconveniente. El mantenimiento manual de las configuraciones y la gestión de los componentes de la infraestructura se vuelven más complejos a medida que aumenta el número de acciones a realizar. Por ejemplo, es más fácil mantener manualmente sincronizada la configuración de tres servidores iguales que la de 100 máquinas virtuales. Realizar un cambio de configuración tres veces o cien veces supone una gran diferencia en la capacidad de gestión necesaria. Tampoco es de extrañar que desde hace tiempo existan diversas herramientas para, por ejemplo, desplegar configuraciones en múltiples máquinas (virtuales).
El siguiente paso: la infraestructura como código
En un entorno de nube (pública) es posible dar el siguiente paso. Esto no sólo automatiza la configuración de los componentes de la infraestructura, sino también su creación. Un entorno completo puede definirse entonces en uno o varios archivos, que son legibles por un sistema que puede configurar los componentes de la infraestructura con esta definición. Este siguiente paso en el proceso de automatización de la infraestructura informática se conoce como «Infraestructura como código», y los sistemas que pueden convertir este código en acciones se denominan «Gestores de Recursos».
Beneficios
Velocidad y fiabilidad
Una de las ventajas más evidentes de aplicar la infraestructura como código es la ganancia de velocidad. En lugar de tener que «encajar» cada recurso a mano, se puede presentar un archivo de configuración, tras lo cual el gestor de recursos hace el resto. Esta ganancia de velocidad también puede suponer una reducción de costes, ya que se requiere menos capacidad de gestión. La reducción del número de acciones manuales también disminuye la posibilidad de errores.
Más tiempo para otros trabajos
Al capturar la infraestructura en el código, y hacer que la despliegue un gestor de recursos, se puede ahorrar tiempo en la gestión de esta infraestructura. En lugar de tener que hacer cambios manuales (varias veces), ahora se hacen completamente en el código. Esto significa que queda más tiempo para el trabajo que añade más valor.
Predictibilidad y mantenibilidad
Al igual que ocurre con el código de la aplicación, también ocurre con el código de la infraestructura que la misma entrada siempre da la misma salida. Por ejemplo, si se crean 20 clusters de Kubernetes basados en una plantilla, es seguro que estos 20 clusters también cumplen exactamente las mismas especificaciones. Mediante el uso de código infra-as, también es posible evitar que diferentes entornos que deberían ser iguales se distancien a largo plazo. Los cambios en los componentes de la infraestructura también pueden llevarse a cabo de forma rápida y fiable.
Control de versiones
El código utilizado para definir la infraestructura puede incluirse en el control de versiones, al igual que el código de la aplicación. Por ejemplo, se puede hacer un seguimiento de los cambios, se pueden revertir las acciones si se producen problemas y se puede definir la infraestructura asociada para un código de aplicación específico.
Impacto en las personas, los procesos y la tecnología
Nuevo utillaje
Dado que la infraestructura puede registrarse en archivos estructurados, también se ha hecho posible que estos archivos de código sean leídos por el software. Tanto AWS como Azure tienen su propio mecanismo de despliegue de infraestructura basado en JSON y YAML con plantillas CloudFormation y ARM. Hashicorp Terraform va un paso más allá, e incluso permite a los usuarios crear plantillas que pueden ser desplegadas en AWS, Azure y GCP. Por lo tanto, no es necesario escribir un software propio que lea el código infra-as y lo convierta en los comandos correctos para los proveedores de la Nube.
Licencias de infraestructura de pago por uso
La infraestructura se ha convertido en gran medida en virtual gracias a las capas de abstracción de los proveedores de la nube, y el uso de la infraestructura como código permite a los clientes aprovisionar infraestructura tanto a corto como a largo plazo. Las estructuras de las licencias también han cambiado; mientras que antes se cobraba un precio de compra por hardware y, además, una cuota periódica, ahora se paga por hora o por minuto. Esta forma de calcular los costes puede ser más barata o más cara según el uso. Sin embargo, cada vez es más difícil predecir los costes de la infraestructura informática. Al fin y al cabo, los costes pueden ser diferentes cada minuto.
Trabajar de forma diferente
El paso de la gestión tradicional de la infraestructura al uso de la infraestructura como código requiere un cambio de enfoque por parte del gestor. En lugar de trabajar en la propia infraestructura, es ahora el código que define esta infraestructura donde hay que trabajar. Cambiar una configuración en un servidor o abrir un puerto en un cortafuegos ya no es un problema, porque con una próxima ejecución del Gestor de Recursos todos estos cambios manuales se sobrescriben con lo que se incluye en el código de la infraestructura. Esto significa que el papel tradicional del gestor de infraestructuras tendrá que reestructurarse, o incluso desaparecer parcialmente.
El cambio a la infraestructura como código ofrece la oportunidad de pensar de forma diferente en la división entre gestión y desarrollo. Con el conjunto de habilidades necesarias para mantener el código de la infraestructura más alineado con el conjunto de habilidades de los desarrolladores de software que la gestión tradicional de la infraestructura, se hace más fácil para los equipos de desarrollo mantener también su propia infraestructura. Esto está en consonancia con la idea de DevOps, en la que la persona que construye un sistema es también responsable del trabajo operativo en ese sistema.
Cambios en la gobernanza
El ritmo de cambio más rápido y la posibilidad de descentralizar la gestión de la infraestructura plantean retos para las organizaciones que adoptan la infraestructura como código. Es posible que haya menos control sobre los componentes de la infraestructura que se instalan y se configuran correctamente. Hay que replantearse la división de responsabilidades. Si no hay un departamento central que gestione la infraestructura, ¿cómo se puede garantizar que todas las normas y requisitos (de seguridad).
Conclusión
El paso de la infraestructura física, o de la infraestructura en la nube configurada por separado, a la infraestructura como código plantea cuestiones relacionadas con los métodos de trabajo y la gobernanza. Una vez resueltas estas cuestiones, el uso de la infraestructura como código permitirá a los usuarios utilizar mejor las posibilidades de una nube (pública). Al definir qué infraestructura debe estar disponible y cómo debe configurarse, es más fácil controlar grandes cantidades de recursos. Mediante el uso de las herramientas disponibles, se puede desplegar, actualizar o derribar todo un entorno con sólo pulsar un botón.
Sin embargo, es importante tener en cuenta que el paso de una infraestructura gestionada de forma centralizada a una infraestructura establecida en código conlleva cuestiones relativas a los métodos de trabajo y la gobernanza. Si quieres ser capaz de actuar con rapidez y precisión en un entorno de nube (de gran tamaño), no puedes ignorar las ventajas de capturar la infraestructura en código.
