El manejo de infrastructura como código es relativamente simple cuando la infraestructura es Kubenernetes, pero cuando no es así la cuestión se puede tornar más compleja.

El proyecto en el que estoy trabajando actualmente no utiliza Kubernetes, sino servidores (VMs) con CentOS 7. El front (ember.js) es servido desde un Web Server Apache y el back (java) corre en un Wildfly (jboss). Por otro lado tenemos un SQL Server (el setup de la instancia está fuera de nuestro alcance, pero nosotros nos encargamos de manejar el esquema de datos)

Para manejar todo esto tenemos:

• Scripts para levantar la VM en la plataforma de VMWare
• Scripts Ansible para aprovisionar las VMs instalando y configurando Apache, Wildfly, Java, etc
• Scripts flyway para evolucionar el esquema de base de datos

Estos scripts los utilizamos para administrar 4 ambientes:

• Desarrollo / Integración
• Demo
• Test / Homologación
• Producción

Adicionalmente a estos ambientes compartidos cada developer tiene una VM (vagrant) local en su máquina de desarrollo, que también es aprovisionada con los mencionados scritps. Este me parece que es un punto central en un esquema de infraestructura mutable: cada developer tiene en su máquina un ambiente para probar que tiene el mismo runtime que el ambiente productivo. Esto no es menor ni tampoco muy común, ya que en general el ambiente del developer tiene un sistema operativo desktop mientras que el resto de los ambientes tiene un sistema operativo server.

De esta forma, más allá de tener versionada la infraestructura, tenemos ambientes uniformes.