La infraestructura como código (IaC) utiliza un lenguaje de codificación descriptivo de alto nivel para automatizar el suministro de infraestructura de TI. Esta automatización elimina la necesidad de que los desarrolladores suministren y gestionen manualmente los servidores, los sistemas operativos, las conexiones de bases de datos, el almacenamiento y otros elementos de infraestructura cada vez que deseen desarrollar, probar o desplegar una aplicación de software.

En una época en la que no es raro que una empresa despliegue cientos de aplicaciones en producción todos los días —y en la que poner en marcha, desmantelar, ampliar o reducir la infraestructura en respuesta a las demandas de los desarrolladores y los usuarios es una constante—, resulta fundamental para las organizaciones automatizar la infraestructura con el fin de controlar los costes, reducir los riesgos y responder con rapidez a las nuevas oportunidades comerciales y las amenazas competitivas. La IaC posibilita esta automatización.

La IaC es también un elemento esencial de DevOps que resulta indispensable para desarrollar un ciclo de vida de entrega de software a un ritmo competitivo. Permite a los equipos de DevOps crear y versionar rápidamente la infraestructura de la misma manera que versionan el código fuente y rastrear estas versiones para evitar incoherencias entre los entornos de TI, que podrían generar problemas graves durante el despliegue.

Sai Vennam realiza un análisis más detallado de la IaC en el siguiente vídeo: “What is Infrastructure as Code?”:

El suministro de TI tradicional es un proceso laborioso y de coste elevado; requiere que personal experto realice la instalación física del hardware, la instalación y configuración del software del sistema operativo y la conexión a middleware, redes, almacenamiento, etc.

La virtualización y el desarrollo nativo en nube elimina el problema de la gestión del hardware físico, lo que permite a los desarrolladores suministrar sus propios servidores virtuales o contenedores bajo demanda. Sin embargo, aun así, el suministro de la infraestructura virtualizada desvía la atención de los desarrolladores de la codificación; estos deben repetir tareas de suministro en cada nuevo despliegue, y además no ofrece una manera fácil de rastrear los cambios en el entorno y evitar las incoherencias que afectan a los despliegues.

La infraestructura como código (IaC) es el último paso para permitir a los desarrolladores "ordenar" de manera efectiva una infraestructura completamente documentada y versionada mediante la ejecución de un script. Las ventajas son exactamente las que cabría esperar:

• Tiempo de producción/comercialización más rápido: la automatización de la IaC acelera drásticamente el proceso de suministro de infraestructura para el desarrollo, las pruebas y la producción (y para escalar o desmantelar la infraestructura de producción según sea necesario). Debido a que lo codifica y lo documenta todo, la IaC puede incluso automatizar el suministro de infraestructura existente, que de otro modo podría estar gobernada por procesos muy laboriosos (como emitir una incidencia).
  
  
• Coherencia mejorada (menos desviación de la configuración):  la desviación de la configuración se produce cuando los cambios y las actualizaciones de configuración ad hoc generan entornos de desarrollo, pruebas y despliegue que no coinciden. Esto puede provocar problemas de despliegue, vulnerabilidades de seguridad y riesgos al desarrollar aplicaciones y servicios que deben cumplir estrictos estándares de conformidad con la normativa. La IaC evita la desviación porque suministra el mismo entorno cada vez.
  
  
• Desarrollo más rápido y eficiente: al simplificar el suministro y garantizar la coherencia de la infraestructura, la IaC puede acelerar con confianza todas las fases del ciclo de vida de entrega de software. Los desarrolladores pueden suministrar rápidamente recintos de pruebas y entornos de integración continua/despliegue continuo (CI/CD). El control de calidad puede proporcionar rápidamente entornos de pruebas de fidelidad total. Las operaciones pueden suministrar rápidamente la infraestructura para obtener seguridad y realizar pruebas de aceptación del usuario. Cuando el código pasa las pruebas, la aplicación y la infraestructura de producción en la que se ejecuta se pueden desplegar en un solo paso.
  
  
• Protección contra el abandono: para maximizar la eficiencia en las organizaciones sin IaC, el suministro se suele delegar a unos pocos ingenieros cualificados o profesionales de TI. Si uno de estos especialistas deja la organización, quedan otros para retomar el proceso. La IaC garantiza que la inteligencia de suministro permanezca siempre en la organización.
  
  
• Costes más bajos y ROI mejorado: además de reducir drásticamente el tiempo, esfuerzo y las habilidades especializadas que hacen falta para suministrar y escalar la infraestructura, la IaC permite que las organizaciones aprovechen al máximo la estructura de costes basada en el consumo de la computación en la nube.  Así mismo, permite a los desarrolladores dedicar menos tiempo a trabajos mecánicos y más al desarrollo de soluciones de software innovadoras e indispensables.

Una de las decisiones más importantes que se deben tomar a la hora de automatizar la infraestructura con Infraestructura como código (IaC) y elegir una solución de IaC es si se quiere establecer una infraestructura mutable o inmutable. 

La infraestructura mutable es una infraestructura que se puede modificar o actualizar una vez suministrada inicialmente. La infraestructura mutable proporciona a los equipos de desarrollo la flexibilidad necesaria para realizar personalizaciones de servidor ad hoc para, por ejemplo, adaptarse mejor a los requisitos de desarrollo o aplicación o responder a un problema de seguridad emergente. No obstante, también desvirtúa una de las ventajas principales de la IaC, la capacidad de mantener la coherencia entre despliegues o dentro de las versiones, y puede dificultar mucho más el seguimiento de la versión de la infraestructura.

Por estas razones, la mayoría de las IaC se implementan como infraestructura inmutable; infraestructura que no puede modificarse una vez suministrada inicialmente. Si es necesario modificar la infraestructura inmutable, debe reemplazarse con una nueva infraestructura. Debido a que la nueva infraestructura se puede poner en marcha rápidamente en la nube, específicamente con IaC, la infraestructura inmutable es mucho más factible y práctica de lo que parece.

La infraestructura inmutable eleva el nivel lógico de la IaC y lo hace, básicamente, reforzándola para garantizar aún más las ventajas que aporta. Prácticamente elimina la desviación de la configuración y facilita aún más mantener la coherencia entre el entorno de pruebas y el de despliegue. También facilita el mantenimiento y el seguimiento de las versiones de la infraestructura, además de garantizar la reversión fiable a cualquier versión, cuando sea necesario.

Al elegir una solución de IaC, también es importante comprender la diferencia entre un enfoque declarativo o imperativo en torno a la automatización de la infraestructura.

En la mayoría de las organizaciones, el enfoque declarativo —también conocido como enfoque funcional— es la mejor opción. En el enfoque declarativo, es el usuario quien especifica el estado final deseado de la infraestructura que desea suministrar, y el software de IaC se encarga del resto: pone en marcha la máquina virtual (VM) o contenedor, instala y configura el software necesario, resuelve las interdependencias del sistema y del software y gestiona el control de versiones. La principal desventaja del enfoque declarativo es que, por lo general, hace falta que un administrador cualificado lo instale y lo gestione, y estos administradores suelen especializarse en su solución preferida.

En el enfoque imperativo, también conocido como enfoque procedimental, la solución ayuda a preparar scripts de automatización que suministran su infraestructura paso a paso. Aunque este enfoque puede ser más difícil de gestionar a medida que se escala, puede ser más fácil de entender para el personal administrativo existente, que puede aprovechar los scripts de configuración que ya tiene implementados.

Elegir un enfoque declarativo o imperativo es similar a usar un GPS o seguir instrucciones paso a paso. Con un GPS, el usuario indica una dirección y el GPS hace el resto, trazando la ruta más rápida y evitando el tráfico, pero probablemente haría falta un experto para explicarle al usuario por qué se han tomado esas decisiones. Las instrucciones paso a paso se basan en la experiencia personal; el proveedor conoce la ruta y por qué la eligió, pero si el usuario encuentra obstáculos o quiere optimizar la ruta, debe llamar para pedir ayuda o hacer el trabajo por sí mismo.

Si bien hay muchas herramientas de IaC de código abierto disponibles, las herramientas adoptadas con mayor frecuencia son Ansible y Terraform:

¿Qué es Ansible?

Ansible (enlace externo a ibm.com) es un proyecto comunitario de código abierto patrocinado por Red Hat que está diseñado para ayudar a las organizaciones a automatizar el suministro, la gestión de la configuración y el despliegue de aplicaciones. Ansible es una herramienta de automatización declarativa que le permite crear "guías de referencia" (escritas en el lenguaje de configuración YAML) para especificar el estado deseado para su infraestructura y luego realizar el suministro para el usuario. Ansible es una opción popular para automatizar el suministro de contenedores de Docker y despliegues de Kubernetes. 

¿Qué es Terraform?

Terraform es otra herramienta de orquestación de infraestructura y suministro declarativo que permite a los ingenieros automatizar el suministro de todos los aspectos de la infraestructura local y basada en la nube de su empresa.

Terraform funciona con todos los principales proveedores de nube y le permite automatizar la creación de recursos en varios proveedores en paralelo, independientemente de dónde se encuentren los servidores físicos, los servidores DNS o las bases de datos. También puede suministrar aplicaciones escritas en cualquier lenguaje.

A diferencia de Ansible, Terraform no ofrece capacidades de gestión de la configuración, pero funciona junto con las herramientas de gestión de la configuración (por ejemplo, Cloud Formation) para suministrar automáticamente la infraestructura en el estado descrito por los archivos de configuración y para cambiar automáticamente el suministro de actualizaciones cuando sea necesario en respuesta a los cambios de configuración.

Para obtener un análisis más detallado para seleccionar una herramienta de IaC, consulte “Infraestructura como código: ¿Chef, Ansible, Puppet, o Terraform?”