Bienvenidos al episodio 24 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 9 de enero de 2018.
Un viejo amigo me dijo hace mucho tiempo, "después que se aprende a usar el martillo todos los problemas se solucionan con clavos".
Y ese es precisamente uno de los problemas que he enfrentado cuando me acerqué al Cloud Computing, era un experto en martillo y mi primer acercamiento fue con un clavo por delante y después de muchos errores, de enfrentarme a pre-conceptos, de sentirme incómodo y de notar que las cosas no fluían ni quedaban como quería me he dado cuenta que en Cloud Computing hay que dejar el clavo y el martillo de lado, y apropiarse de la tecnología para usarla en forma correcta.
Es decir, con cloud computing no solo nos enfrentamos a una nueva herramienta sino que también a una nueva metodología de trabajo y hay que hacer un cambio de enfoque, un cambio de la forma que concebimos las cosas. A mi no me fue fácil y les confieso que aún tengo algún problema, pues me considero experto en el martillo y el clavo.
Entonces, en este primer podcast de 2018 te voy a contar sobre "infraestructura inmutable", un concepto que me ha ayudado mucho a hacer el cambio de mentalidad para entender y sentirme más cómodo con cloud computing.
Veamos el tema de una forma más concreta:
- ¿No te ha pasado de sentirte incómodo con el hecho que si terminas una instancia todo tu disco desaparece? ¿esto no te hace sentir que estás armando tus servidores sobre una cama de huevos?
Originalmente este fue una de mis mayores incomodidades en Cloud Computing, como que sentía todo es esfímero y solo se podía sobrevivir con una política estricta de respaldos, imágenes y snapshots. (por las dudas....)
- ¿Y no te pone nervioso saber que si tu instancia se reinicia puede tomar una IP distinta? Justamente aquello que siempre fue la manera segura de llegar a un equipo, su dirección IP, en Cloud Computing es tan esfímero como sus discos. Tus aplicaciones pueden dejar de funcionar luego de un reboot si te basas en estas IP. (hoy en día me encuentro con gente que esto no lo sabe... y ahí corre todo producción con esas IP que cambian harcodeadas)
Y claro que he leído sobre la importancia de pensar las aplicaciones con escalabilidad horizontal o sobre las ventajas de la elasticidad y el uso de los recursos a demanda, pero estaba apegado al viejo paradigma que se llama "infraestructura mutable" (digamos al martillo y al clavo) y desde ahí, todo esto me resultaba más anecdótico que práctico.
Y entonces, como te decía, fue recién cuando hice propio el concepto de "infraestructura inmutable" que di el "click" y todo se volvió más lógico y natural. Los conceptos anecdóticos se convirtieron en fantásticos features que potencian mi trabajo.
Te decía que la forma tradicional de relacionarnos con nuestra infraestructura la llamamos "infraestructura mutable"; mientras que la forma nueva, impulsada por las tecnologías emergentes como Cloud Computing, Contenedores o directamente el As A Service la llamamos "infraestructura inmutable".
¿y qué caracteriza a cada una de estos dos abordajes de la la infraestructura?
La documentación sobre infraestructura mutable es casi unánime al definirla como aquella que accedemos a los servidores por ssh para ajustes, cambios y actualizaciones.
Esto así es la característica esencial de toda una forma de pensar y posicionarse frente a la infraestructura que vamos a mantener y, podemos decir, que es lo que siempre hemos hecho.
Es decir, tenemos una máquina (real o virtual), a la que le instalamos el sistema base, le hacemos las configuraciones de seguridad, de requisitos y servicios necesarios para dejarla lista para recibir la aplicación o aplicaciones, a partir de ahí la mantenemos con mejoras, actualizaciones y cambios que sean necesarios (accediendo por SSH) y, eventualmente agregamos o desinstalamos aplicaciones que corren en ella a lo largo de su vida útil.
Por esto, se llama infraestructura mutable, pues va cambiando a lo largo de su vida útil de la infraestructura.
Por esto hay toda una suerte de conceptos y tareas que son afines y normales a la infraestructura mutable:
- hacer backup periódicos de cada servidor, o snapshots, o imágenes, pues el backup anterior no tiene la información que hemos cambiado nosotros mismos.
- el sentido de estabilización o equilibrio de un servidor, aquello que solemos definir con la frase "si funciona, no lo toques", pues justamente nuestra tarea definir y ponderar cuándo es necesario tocar un servidor.
- la alta disponibilidad por master slave o activo pasivo, pues justamente nuestra infraestructura es muy estática
- la escalabilidad vertical, agregando recursos de hardware para satisfacer los picos de consumo
- y la documetación... continuamente desajustada con la realidad, detrás de la que todos corremos, pues nuestros servidores siempre tienen algo que no está documentado (que generalmente insertamos nosotros mismos)
solo por nombrar alguna de las cosas que todos conocemos y que son afin justamente a esta forma de mantener infraestructura mutable, desde que nacen sus componentes, los ayudamos a crecer, maduran y son desafectados algun dia, pero mientras tanto son como nuestros hijos con nombre propio, como "zeus", "mickey" o "bond" y nos sentimos orgullosos de sus uptimes.
Y es adrede que acabo de comparar nuestros los servidores con seres vivos que criamos como hijos, pues justamente para entender el concepto de "infraestuctura inmutable" es precisamente la forma que tienen los sistemas biológicos de crecer, de recuperarse ante traumas o de mejorar su cuerpo y es mediante lo que se denomina "computacion natural"
Nosotros como seres humanos no crecemos haciendo cada vez mejor y más fuerte nuestras células, no Señor. Nosotros crecemos, maduramos, mantenemos nuestros sistema inmune, nos recuperamos ante enfermedades o traumas físicos directamente destruyendo componentes y reemplazándolos por nuevos que no tienen los problemas de los anteriores.
Eso es precisamente computación inmutable: los componentes de nuestra infraestructura no se mejoran o se arreglan, no se modifican. Lo que se hacemos es reemplazarlos con nuevos componentes que incorporan los arreglos o mejoras. Una vez que hemos reemplazado los componentes y todo funciona de acuerdo a los requerimientos del sistema, descartamos los componentes obsoletos.
Este reemplazo y destrucción de componentes se hace con algo tan relevante como un cambio de versión de la aplicación o la actualización del sistema, hasta con algo tan simple como actualizar un certificado digital o crear un usuario nuevo.
Entonces con infraestructura inmutable también hay un conjunto de conceptos que le son afines, como ser:
- automatización: este reemplazo de servidores enteros no se puede hacer si no es en forma automática, necesitamos de herramientas que utilicen el API de nuestro proveedor de cloud computing para pedir nuevos componentes, que luego se encarguen de todo el aprovisionamiento de configuración, de la instalación de la aplicación y del proceso de reemplazo y descarte.
- infraestructura como código: las herramientas de automatización tendrán datos completos de cómo es el estado actual de nuestra infraestructura, será nuestra documentación que obviamente podremos tener gestionada por un sistema de control de versiones.
- escalabilidad horizontal: una vez automatizado levantar un servidor o levantar cien, es cuestión de una variable, por lo que es lógico esta forma de gestionar nuestra alta disponibilidad.
- elasticidad: si tenemos automatizada la creación de nuestros servidores de cero al estado de producción con las ultimas mejoras, perfectamente podemos tener algo que esté monitoreando la carga y levante más recursos en forma automática si se requieren, o apague recursos si ya no son necesarios. (si si... como la cantidad de glóbulos blancos reaccionando ante una infección)
¿y nuestro querido ssh? ..... y nada, es lo que usamos para mantener nuestras infraestructuras mutables, de las cuales casi todos igual seguimos manteniendo.
Y si me apuras y me preguntás cómo me va con esto de la infraestructura inmutable, te tengo que confesar que no es un camino de rosas ni un tobogán a la felicidad. A mi me está resultando un trabajo de hormiga donde debo negociar con gente que tiene sistemas de virtualización y los trata bien bien mutablemente y así se sienten seguros y conformes. O también con desarrolladores que cuando entienden el concepto parece que no les aporta nada e insisten en pasar a producción la nueva versión de la aplicación, mediante un script ejecutado por SSH.
De todas formas, como te decía al principio del podcast, el concepto de "infraestructura inmutable" y también el de "computación natural" me han ayudado a entender mejor las características de cloud computing y a hacer propio esas cosas que otros flacos escriben en libros y hablan en conferencias.
Soy Rodolfo Pilas, en twitter me puedes segir por @pilasguru y te dejo un saludo; confío que este podcast te haya aportado para mejorar y, como siempre, espero tus inquietudes y sugerencias comentando en deployando.me
Hasta la próxima edición.