Cómo conseguir que la infraestructura como código sea una solución completamente madura

El número de desarrolladores nativos de la nube ha aumentado considerablemente en los últimos dos años hasta alcanzar los 6,8 millones según la Cloud Native Computing Foundation, y no es difícil entender por qué.

Los contenedores, la orquestación y la tecnología sin servidor se han combinado para transformar la forma en que funcionan. El fácil acceso a la computación, el almacenamiento y las redes en la nube a través del autoservicio ha permitido a los desarrolladores liberarse de la necesidad de solicitar recursos, lo que se traduce en una entrega de software más rápida. Los denominados desarrolladores de “alto rendimiento” pueden llevar a cabo unas 10 implementaciones de menos de una hora durante el transcurso de un día.

Pero mientras que los impedimentos para construir e implementar recursos como los servidores han desaparecido, ha surgido un nuevo desafío: aprovisionar recursos sin comprometer la eficiencia operativa.

El desarrollo y la implementación pueden implicar prácticas y atraer problemas que obstaculicen el aprovisionamiento. Los servidores implementados pueden, con el tiempo, apartarse de una configuración estándar debido al ritmo de las optimizaciones o actualizaciones. Este fenómeno, llamado deriva de configuración, dificulta la administración de actualizaciones a escala y da como resultado “esquemas de copos de nieve” que deben gestionarse individualmente. A medida que los servidores cambian, los servicios también deben gestionarse individualmente. Finalmente está el desmantelamiento, que no sólo requiere mucho tiempo y es complejo, sino también caro: si se olvida de apagar los servidores o anular los servicios recibirá una inoportuna factura de su proveedor de servicios en la nube.

Implemente la Infraestructura como código (IaC). Esto lleva las prácticas de ingeniería de software, como el control de versiones y las pruebas, a la infraestructura nativa de la nube a fin de que sea coherente con el aprovisionamiento optimizado.

Suena simple, pero surge un reto. La mayoría de las organizaciones utiliza nubes híbridas y multinubes de forma predeterminada, según el último informe sobre el estado de la nube de Flexera, disponible aquí, lo que significa que la IaC debe ser capaz de abarcar a cada proveedor y servicio. Pero, según Flexera, solo el 25% usa herramientas para gestionar la multinube. En otras palabras, están ejecutando su infraestructura y los elementos dentro de ella como una serie de islas desconectadas.

Una IaC completamente madura puede resolver esto sentando las bases para una infraestructura coherente y predecible, necesaria para aprovisionar los sistemas nativos de la nube a la escala y velocidad requeridas.

Teoría de la idempotencia

En el corazón de IaC se encuentra el principio de idempotencia. En términos prácticos, es un comando de implementación que establece el entorno de destino en la misma configuración, independientemente del estado inicial. La idempotencia se logra automáticamente configurando un objetivo existente o descartando ese objetivo y creando un entorno nuevo. Con IaC, se realizan cambios en la descripción del entorno y el modelo de configuración de versión con ese modelo ejecutado a través del canal de CI/CD.

¿Cómo funciona esto en el mundo real para los desarrolladores?

Primero, debe describir su infraestructura como un modelo declarativo. Esto definirá el estado de su sistema -de recursos como servidores- y registrará sus propiedades y herramientas para configurarlas, lo que facilitará su aprovisionamiento coherente y permitirá la reversión. Alternativamente, puede usar un modelo imperativo que defina comandos específicos y el orden en que se ejecutan para lograr el estado deseado, pero la mayoría de las herramientas de IaC (Terraform, Pulumi, CloudFoundation y Puppet) prefieren la opción declarativa.

Luego están las plantillas. Se utilizan para capturar el estado exacto de un recurso o entorno individual, como un servidor. Una herramienta declarativa usa la plantilla para procesar la lógica y las llamadas de API necesarias para configurar una máquina en la nube, la zona, el sistema operativo, el clúster, etc. Por ejemplo, una plantilla podría especificar un servidor Debian en GWC con almacenamiento, cómputo, redes y seguridad. Las plantillas, sin embargo, tienen un segundo propósito: le permiten implementar recursos a través de una GUI, lo que elimina la necesidad de trabajar en la línea de comandos o en el nivel de API. Por lo tanto, las plantillas son un paso importante para alejarse de un enfoque basado en la codificación para el aprovisionamiento que, con el tiempo, inevitablemente contribuirá a la deriva de la configuración.

Seguir la corriente del flujo de trabajo

El tercer elemento de IaC son los flujos de trabajo. Una vez que haya creado su recurso, necesita saber cómo funcionará: pruebas de tiempo de ejecución, unidad, integración y seguridad en diferentes fases a través de la construcción, la aceptación, el ensayo y la entrega. Esas fases se implementan en el canal de CI/CD y deben llevarse a cabo cuando se hayan creado las pull requests (solicitudes de incorporación de cambios) y antes del lanzamiento.

Las fases del flujo de trabajo se pueden personalizar con los eventos definidos en cada una mediante manuales y runbooks. Las mejores fuentes para crear flujos de trabajo son los puntos de referencia del sector, los proveedores de la nube o los especialistas en DevOps, los modelos de amenazas de seguridad o los códigos de prácticas y los procedimientos de su empresa.

Hay tres mejores prácticas que analizar aquí. No establezca flujos de trabajo definitivos: utilice un enfoque basado en un marco operativo que permita que los flujos de trabajo evolucionen según los requisitos cambiantes. Los flujos de trabajo también deben permitir que se conecten herramientas de diferentes proveedores. Finalmente, debe probar los flujos de trabajo para asegurarse de que aprovisionan correctamente recursos (como los servidores), y de que implementan los paquetes según lo planeado.

El elemento final de IaC es la automatización. Un motor de automatización maximizará el potencial de los flujos de trabajo y las plantillas al implementarlos según los requisitos y especificaciones del modelo de infraestructura. Sirve como un medio para la gestión y la implementación de cambios, garantizando que se aplique la configuración correcta para lograr la coherencia. También le permitirá integrarse con su canal y herramientas de CI/CD.

La automatización se puede aplicar local o globalmente. En el primer caso se ejecuta con wrapper scripts (envoltorios), en el segundo, se ejecuta en toda su infraestructura con una herramienta de orquestación como Jenkins. No todos los motores de automatización son iguales. Vienen con diferentes características y capacidades, y cada uno tendrá un atractivo (así como ramificaciones) diferentes para DevOps. Por ejemplo, algunos se pueden alojar online, otros se pueden instalar localmente y en otros ambas opciones son posibles. Otros puntos a considerar son si su motor asumirá que el entorno de implementación es el mismo que utiliza; el nivel de integración con herramientas de terceros; si asume que los plugins siguen siendo los mismos después de lanzar un cambio; y si implementa planes de cambio de manera simultánea o individual.

Conclusión

La tecnología nativa de la nube ha entrado en la corriente principal de la tecnología empresarial gracias a la flexibilidad y al poder que ha conferido a los desarrolladores. Pero debe seguir un aprovisionamiento efectivo para que alcance su potencial operativo. Aplicar las prácticas de ingeniería de software a la infraestructura nativa de la nube y, por lo tanto, hacer operativa la infraestructura como código, liberará ese potencial.