Exploración de la implementación del entorno

Completado

Supongamos que alguna vez ha recibido una llamada de soporte técnico de emergencia en mitad de la noche debido a que un servidor se ha bloqueado.

En ese caso, sabe el esfuerzo que supone buscar en varias hojas de cálculo, o incluso en la memoria, para acceder a los pasos manuales de configuración de una máquina nueva.

Además, también existe la dificultad de mantener la coherencia entre los entornos de desarrollo y producción.

Una manera más fácil de eliminar la posibilidad de que se produzcan errores humanos al inicializar máquinas es usar la infraestructura como código.

Implementación manual frente a infraestructura como código

Una analogía común para comprender las diferencias entre la implementación manual y la infraestructura como código es la distinción entre tener mascotas y tener ganado.

Cuando se tienen mascotas, todas ellas tienen un nombre y las cuida como si fueran personas. Si algo le sucede a una de ellas, lo normal es preocuparse mucho.

Si tiene un rebaño de ganado, es posible que les haya puesto nombre, pero lo contempla como su rebaño.

En términos de infraestructura, puede haber implicaciones graves con un enfoque de implementación manual si una sola máquina se bloquea y necesita reemplazarla (mascotas).

Si adopta la infraestructura como un enfoque de código, puede aprovisionar más fácilmente otra máquina sin que afecte negativamente a toda la infraestructura (ganado) en caso de que una sola máquina deje de responder.

Implementación de la infraestructura como código

Con la infraestructura como código, se captura el entorno (o entornos) en un archivo de texto (script o definición).

El archivo puede incluir cualquier red, servidor y otros recursos de proceso.

Puede comprobar el script o el archivo de definición en el control de versiones y, después, usarlo como origen para actualizar los entornos existentes o crear otros.

Por ejemplo, puede agregar un servidor nuevo editando el archivo de texto y ejecutando la canalización de versión en lugar de hacerlo de forma remota en el entorno y aprovisionando manualmente un servidor nuevo.

En la tabla siguiente se enumeran las diferencias significativas entre la implementación manual y la infraestructura como código.

Implementación manual Infraestructura como código
Servidores de Snowflake. Un servidor coherente entre entornos.
Los pasos de implementación varían según el entorno. Los entornos se crean o escalan fácilmente.
Más pasos de comprobación y más procesos manuales elaborados. Creación totalmente automatizada de actualizaciones del entorno.
Mayor documentación para tener en cuenta las diferencias. Transición a una infraestructura inmutable.
Implementación los fines de semana para permitir tiempo de recuperación de errores. Uso de implementaciones azul-verde.
Ritmo de lanzamientos más lento para minimizar los problemas y los puentes festivos. Tratamiento de los servidores como ganado, no como mascotas.

Ventajas de la infraestructura como código

En la lista siguiente se muestran las ventajas de la infraestructura como código:

  • Promueve la auditoría facilitando el seguimiento de lo que se implementó, cuándo se implementó y cómo. (En otras palabras, mejora la rastreabilidad).
  • Proporciona entornos coherentes de una versión a otra.
  • Mayor coherencia entre entornos de desarrollo, prueba y producción.
  • Automatiza los procesos de escalabilidad vertical y horizontal.
  • Permite controlar la versión de las configuraciones.
  • Proporciona capacidades de revisión del código y de pruebas unitarias para permitir administrar los cambios en la infraestructura.
  • Usa procesos de servicio inmutables, lo que significa que, si se necesita un cambio en un entorno, se implementa un nuevo servicio y se quita el anterior; es decir, no se actualiza.
  • Permite implementaciones azul-verde. Esta metodología de versiones minimiza el tiempo de inactividad donde existen dos entornos idénticos: uno está activo y el otro no. Las actualizaciones se aplican al servidor que no está activo. Cuando se comprueban y completan las pruebas, se intercambian con los distintos servidores activos. Se convierte en el nuevo entorno activo y el anterior ya no es el activo.
  • Trata la infraestructura como un recurso flexible que se puede aprovisionar, desaprovisionar y volver a aprovisionar cuando sea necesario.