Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
Y así comenzó.
de que usaron Terraform para crear infraestructura y luego configuraciones. Pero fue creciendo y le fue agregando más y ahora es bien complicado. Toca correr Terraform dos veces mínimo. Se corre una vez y se usan los flags de target. Y le decís, targetíame solo estos módulos que son los que van a levantar la infraestructura primero. Porque si lo querés correr de un solo...
Cuando Terraform quiera correr y quiera crear un recurso dentro de Kubernetes, como es un clóset de Kubernetes que todavía no existe, no se puede conectar a él y no puede validarse el recurso existe o no. Porque recordemos que Terraform trabaja con Desired State. Y antes de correr, va a ver cuál es el estado actual, lo compara contra el Desired State y hace los cambios. Pero ¿cómo puede hacer eso con un clóset de Kubernetes que todavía no existe?
Hola a todos y bienvenidos nuevamente a Dev & Ops. Este es su podcast favorito en el cual hablamos de tecnología, desarrollo, DevOps y su cultura en general. Y como es costumbre, acompañado de mi buen amigo y co-host, Juan Ramos, a quien le doy la bienvenida. Juan, ¿qué tal?
Juan (01:11)
Hola Douglas, muy bien, me encuentro muy contento de estar aquí en una nueva plática con vos. Siempre es interesante y ojalá que también sea interesante para los que nos escuchan, las personas que siempre nos están apoyando con un like, con una compartida, un comentario, eso nos ayuda mucho y bueno estamos muy agradecidos por eso. Así que bueno, estoy aquí dispuesto a todo, Douglas.
Douglas (01:37)
Listo, listo, me gusta bastante. Y definitivamente, pues esas son las cosas que nos motivan y nos llevan a crear este contenido donde esperamos generar valor para aquellas personas que nos ven y nos escuchan, ya sea alguien junior o que recién quiere comenzar en tecnología, ya sea en desarrollo, en el área de infraestructura, para que sepa implementar la cultura DevOps, o alguien ya con mucha experiencia que pueda, tal vez, aprender o sentirse identificado con algo e incluso también
en lo que son los comentarios en las diferentes plataformas, proveyendo valor para otros, ya sea afirmando que han tenido experiencias similares o cómo ellos han evitado problemas que tal vez acá contamos nosotros.
Juan (02:20)
Fíjate que eso es algo
que me gustaría definitivamente agradecer a las personas que nos ayudan a comentar He revisado a veces en ciertos shorts o clips que hemos lanzado Alguien hace alguna pregunta y veo la pregunta entonces ok voy a tratar de responderle pero veo que tiene una respuesta y cuando veo la respuesta es alguien que se ha tomado el tiempo y le ha explicado de manera muy amable y eso la verdad es que
lo agradecemos mucho porque realmente esa es la intención, que haya una comunidad donde las personas puedan compartir y hacer preguntas.
Douglas (02:59)
Sí, no,
creo que estoy con vos en eso, Juan. A mí me alegra también mucho ver que esa comunidad que estamos formando, uno va creciendo, semana a semana va creciendo cada vez más. Y dos, pues, está teniendo esa interacción y esa intención de buscar ayudar a los demás. Eventualmente, Juan, creo que vamos a tener que crear nuestro Discord para que exista una interacción un poco más fluida en ese sentido. Pero bueno, en eso estamos creciendo y le damos gracias.
Juan (03:21)
Sí.
Douglas (03:29)
adiós por ello y le agradecemos a ustedes también por todo su apoyo y creo considero que en ese sentido el tema que vamos a tocar hoy tiene justo esa esa sustancia ese ese efecto que es muy interesante y beneficioso para juniors y personas que vienen comenzando como también para personas senior
que tal vez no lo han implementado a gran escala o simplemente van a tener muchas experiencias y cosas que contar en la sección de comentarios. es que hoy vamos a hablar de Infrastructure as Code o infraestructura como código y Configuration Management, que son dos herramientas que a veces se confunden, pero en realidad se complementan, Infrastructure as Code y Configuration Management, ¿verdad?
ya sea un junior que apenas comienza, que acaba de levantar su primer servidor, su primera instancia, o un senior que lleva años administrando infraestructura, ¿verdad? Este nos compete a todos. Entonces, Juan, como programador, vos, ¿qué te suena Infrastructure as Code y Configuration Management? ¿Cuál ha sido tu experiencia o exposición en este sentido? Y quiero anticiparte, antes de que nos respondas o antes de darte la palabra, que definitivamente como programador,
Espero que sea poca tu exposición. Sin embargo, yo no lo digo como algo malo. Obviamente tenemos roles y funciones diferentes. Pero parte del motivo por el cual queremos tocar esto es que también llegue al oído de los programadores este tema y que lo entiendan un poco. Es bueno entendernos unos con los otros para que la colaboración sea más fluida, ¿verdad? Entonces, ¿a qué te suene? ¿Cuál ha sido tu exposición a estas dos herramientas? Juan.
Juan (05:14)
Bien, en efecto no he estado tan expuesto a este tema de manera directa, ¿no? Sí he escuchado, obviamente lo he escuchado el tema y he visto muy por encima de qué trata, aunque probablemente tal vez haya visto algo que esté incorrecto, no lo sé. Pero he visto que hay varias herramientas al respecto. Pero yo creería, si lo tuviera que decir de manera...
muy simple que es para mi yo diría que infrastructure as code es el hecho de poder crear una infraestructura eso podría ser una máquina virtual o una instancia de una computadora con sus recursos ya sea número de cpus cantidad de memoria ram disco duro todo esto definido mediante un lenguaje de un código y este código puede ser
bueno, cualquier código, cualquier lenguaje y aquí lo definimos y eso nos permite tener, diría yo que algo número uno más fácil de manejar más poder hacer estas tareas repetitivas de estar levantando o quitando instancias y es fácil no de poder escalar y cosas así aunque no estoy muy al tanto de cómo escala realmente pero eso es lo que se dice y configuration management
bueno solo por la palabra yo diría que es como donde tenemos uno levanta los recursos y el otro en el otro manejamos o guardamos las configuraciones del servidor o de las aplicaciones que vamos a correr en el servidor o la instancia y se me viene a la mente porque no tengo muchas más referencias directas pero se me viene a la mente como por ejemplo con docker swarm docker swarm puede tener la
las configuraciones los config files creo que se le llama de los contenedores algo así lo visualiza en mi mente pero estoy seguro que las herramientas que utilizas obviamente son mucho más avanzadas pero digamos que de manera muy simple algo así es lo que lo que entiendo yo cuando escucho esas palabras
Douglas (07:36)
No, fíjate que
no estás alejado de la realidad o del entendimiento en ese tema, realmente que estás bastante cerca, bastante cerca. Y yo creo que si querés comencemos como definiéndolo bien. Y como siempre hacemos aquí en Deben Ops, normalmente, aunque depende del tema, pero normalmente no nos vamos a la definición de los libros, sino que una definición práctica basada en nuestras experiencias.
Juan (07:41)
No,
alegra.
Douglas (08:04)
Comencemos definiendo Infrastructure as Code y Configuration Management aclarando antes de dar las definiciones, que a veces se olvida o ni siquiera se estima el hecho de que cuando trabajamos con infraestructura y con configuración de aplicaciones y servicios, es bastante esta infraestructura y es bastante estos servicios.
no es poco realmente, ahorita dijiste levantar infraestructura, una instancia, cuanto CPU, cuanta memoria, y yo sé que no tenés, no es tu intención desestimar la cantidad de trabajo, simplemente es desconocimiento porque tú varias otra vez, no hay nada malo.
porque esa tu área es otra y tienes que enfocarte en otras cosas. Yo no conozco profundidad tu área, Y de eso se trata el asunto. Pero en realidad hay mucho más infraestructura que crear. que crear la VPC, que es la red, diferentes networks privados, públicos. Hay que crear los balancers, hay que crear políticas de seguridad y hay otro montón de infraestructura, buckets, volúmenes, gateways, etcétera, etcétera. Y por eso la necesidad
necesidades de este tipo de herramientas, igual cuando configuramos dentro de un servidor, de un solo servidor para Configuration Management, son bastantes las cosas que se tienen que configurar y darle mantenimiento, los paquetes del sistema operativo, los servicios corriendo en él, qué editor de texto por defecto.
que es seguridad o políticas de seguridad, si tenés el IP Table, survival corriendo, si tenés algo como C-Linux corriendo, los servicios, NGINX, todos los virtual host, configuración por defecto, si tenés o PHP o otro servicio corriendo, sea, aún dentro de un solo servidor es bastante lo que se configure y administra y por eso nacen estas necesidades. Y ya vamos a hablar un poquito del antes y después de estas herramientas, pero para...
Juan (10:07)
hay ocasiones donde realmente
necesitas cambiar el editor por defecto donde instalas BIM en vez de nano
Douglas (10:15)
Sí, hay una preferencia normalmente. A veces el editor por defecto es VI y querés nano, o a veces es nano y querés VI. No comprendo a los que quieren nano en lugar de VI, pero no los critico. Cada quien tiene su preferencia. Pero sí, definitivamente te aseguras de normalmente definir el editor de texto por defecto. A veces el mensaje que te parece cuando te lo guías a un servidor...
el que se le conoce como a Message of the Day, normalmente también ahí le agrega ciertas cosas, el Sudoers, los permisos de Sudo, los usuarios, los grupos, o sea, de nuevo, dentro de un solo servidor es bastante lo que hay que configurar, imaginate si sos responsable de cinco servidores o de diez o de 200, ¿verdad? Entonces, por ahí va el tema, por ahí va el asunto.
Juan (11:06)
Sí.
Douglas (11:10)
Entonces, centremos la definición, infraestructura as code, infraestructura como código, eso es lo que significa en español, básicamente es el despliegue y mantenimiento de la infraestructura con código, tal cual lo dijiste vos, despliegue y mantenimiento, importante la palabra mantenimiento, infraestructura con código, Este puede ser infraestructura en la nube, infraestructura en...
data center, híbrido, etcétera. Pero esto nos da las bondades del manejo de código para nuestra infraestructura. Bondades como control de versiones, el poder ver un commit, hacer un historial, bondades como pull request, que alguien te revise y te apruebe antes de implementar los cambios en la infraestructura. Bondades como un rollback.
fácilmente todo lo que trae el desarrollo de código implementado en despliegue y mantenimiento de infraestructura eso es básicamente herramientas comunes de infraestructura as code terraform creo que es la más popular sin embargo está pulumi, verdad terraform tiene su propio hcl, propio lenguaje, pulumi te permite usar el lenguaje que ya conoces como programador
Y eso es una gran ventaja para los programadores. También hay herramientas como Crossplane que corren en Kubernetes. Y son herramientas, son tendencias más recientes. Me encanta Crossplane a mí en lo personal porque funciona por medio de Kubernetes. Y también está en herramientas como CloudFormation, pero esto es nativo de AWS. Solo te crea recursos dentro de AWS, es nativo de ellos.
Entonces eso es Infrastructure as Code.
Juan (13:00)
Sí, siempre estar con
un vendor locking muy fuerte siempre como que genera un poco de rechazo en la mayoría de las empresas. A menos que realmente sepas que de aquí a 20 años yo voy a seguir en AWS y listo.
Douglas (13:17)
Sí,
y bueno, lo vamos a ahundar un poquito más adelante, Juan, pero más allá del vendor locking porque igual si usas Terraform o si usas Pulumio Crossframe y trabajas en AWS, tienes que crear recursos dentro de ellos y no vas a agarrar tal cual el mismo código y crear recursos en Azure o en Google Cloud. Siempre va a ser diferente.
Juan (13:38)
siempre cambia, ok.
Douglas (13:39)
Pero con
CloudFormation solo puedes crear recursos dentro de AWS. No puedes crear recursos de DNS en Cloudflare o en otro DNS, o no puedes crear recursos en Kubernetes, solo dentro de lo que es AWS. Ahí vamos a detallar un poquito más adelante. Ahora, Configuration Management.
Juan (13:58)
Mhmm.
Douglas (14:02)
bien similar a lo que vos dijiste, gestiona la configuración de sistemas, servicios, aplicaciones, ya corriendo en diferentes clusters o servidores. De nuevo, nos permite la bondad del código, lo mismo que ya mencionábamos, code review, pull request, rollbacks, etcétera. Esa parte de manejar todas estas configuraciones como código.
trae una de beneficios increíbles al flujo de trabajo y a la administración y mantenimiento de las configuraciones y de la infraestructura. Herramientas comunes, Chef, Puppet, Ansible son como el top tres en ese sentido dentro de lo que es el mundo de sistemas en ese sentido. Yo en lo personal comencé con Puppet cuando...
y luego con Ansible, cada uno tiene sus pros y sus contras, sus beneficios. Puppet me gusta que él está corriendo constantemente y si alguien hace un cambio manual, Puppet lo va a volver a poner como estaba. pues Ansible es como más ligero a la hora de implementarlo, no ocupa instalar un agente en cada servidor, no ocupa tener un servidor central o un master que esté corriendo.
pero bueno, alguien puede hacer un cambio y si no volves a correr Ansible, ese cambio no se revierte. Y es que aquí Juan ambos, y esto quiero mencionarlo ahorita que di la definición de ambos, ambos tienen una bondad que es que trabajan en base al estado deseado de lo que querés, se conoce como desire state. Vos lo que definís en infraestructuras code para la infraestructura o en configuration management es...
el estado deseado que busquen, vos decís para infraestructuras code quiero tres VMs con tanto disco duro, con tanto memoria, tanto de CPU, quiero que estén en la red privada, quiero que se expongan por medio de un load balancer y básicamente lo que estás haciendo es decir yo quiero que esto esté.
No le digo cómo lo va a hacer. No le aplico lógica, no le digo que ocupa un if statement y que el if va a ver si hace esto, aquí voy a hacer un for loop que haga lo otro, no. Yo le doy el estado deseado y cada vez que corra a Infrastructure as Code, la herramienta que sea que utilice, va a ver qué estado quiero y ese va a aplicar. Y lo mismo con Configuration Management. Yo le digo, quiero que esta es la lista de paquetes que quiero que esté instalado en el sistema operativo. Este es el editor por defecto, este servicio quiero que esté instalado. Así quiero que se configure en Ginet.
y le digo cuál es el estado que quiero sin darle lógica sólo le doy el estado que quiero y cada vez que corre él se encarga de poner ese desired state o el estado deseado por eso el formato Jamal es el que gobierna el que sobresale en este tipo de infra cuando sobre todo es configuration management
en infraestructuras code también se puede, Jamal se usa, CloudFormation usa Jamal por ejemplo, ya lo que es CloudFormation tiene su propio lenguaje, pero Jamal sobresale porque te permite, es fácil, con tabulación es decir cuál es el estado deseado que quiero, ¿verdad?
Juan (17:23)
que mucha
gente hoy en día habla bastante sobre en vez de Jamel utilizan Tommel creo que se pronuncia no estoy seguro cuáles eran las ventajas pero si he visto en internet como que hay un movimiento en contra de Jamel actualmente
Douglas (17:40)
Sí, normalmente ese movimiento
no va para infraestructuras code porque Jamut es fácil como... Tienes una jerarquía fácil. Solo tabulas, vos decís quiero una VM y tabulas y dentro de la tabulación le decís cuánto de memoria, cuánto de CPU.
Juan (17:50)
Sí.
Douglas (17:59)
cuanto de disco tabular dentro de disco y le decís que querés qué tipo de disco si es SSD, dependiendo de donde trabajes, no sea solo vas tabulando y vas creando una jerarquía fácil de entender y de interpretar pero pues independiente de mente de eso ambos tanto infrastructure as code como configuration management destacan porque le definimos el estado deseado que queremos para la infraestructura y él corre y él el él en su back-end
dependiendo qué proveedor y cómo se conecta él es el que hace la lógica que tenga que hacer nosotros lo definimos ese estado entonces no sé juan si es así como lo entendías un poco tenías una idea diferente de cada una de ellas yo sé que ya no diste un poco pero ahorita que lo que lo estoy mencionando si en efecto era por ahí que sentías que ibas
Juan (18:32)
Sí.
eeee
un poco, un poco, si ya con esto ya me queda un poco más claro cuáles son las diferencias porque como que al inicio suena como similar pero ya con tu explicación ya me queda más claro eso que mencionas de buscar el estado deseado es muy ventajoso no solo para los que están configurando los sistemas, la infraestructura en general sino también para los desarrolladores te expongo mi caso
y es que a veces más que todo en el ambiente de el ambiente de testing en el ambiente de testing uno lo que busca es romper la aplicación y cambiar cosas y ver qué pasa entonces es muy fácil ir por ejemplo de un ejemplo rápido entro algo cd cambio las variables de entorno si no me equivoco algo cd puede volver a refrescar las variables que desea porque son las que están
configuradas en el repositorio una vez que se refresque con un nuevo PR, un nuevo push pero eso a lo que me da la ventaja que me da es que yo puedo cambiar y hacer cosas y revisar en los logs ok ahora voy a testear esto cambio esta variable cambio esta otra parte esta otra partecita se la quito y yo sé que en el una vez que se vuelva hacer un PR o que vuelva correr el proceso todo vuelve a estar como debería estar entonces eso a uno de como developer
te da una gran ventaja porque te permite eso, romper la aplicación o cambios muy simples a veces tenemos seteado un nivel de lock muy no sé cómo llamarlo, alto o bajo pero no vemos todo voy, lo cambio y ahora me muestra todos los locks y en lo que termino de hacer el testeo vuelvo a hacer un nuevo PR y ya se revirtió el cambio, que de la configuración así que si definitivamente
son tecnologías que con el tiempo han venido a suplir estas necesidades muy puntuales.
Douglas (20:55)
Sí, me gusta
eso que estás diciendo porque en efecto esa es una bondad en el caso de los programadores cuando se trata del desire state o el estado deseado es que cuando ven este código es como fácil interpretar que se va a hacer y te permite...
luego fácil adaptarte porque dijiste algo muy importante, CD que es como la evolución de infraestructuras code y configuration management, ya esto es GitOps, se le conoce como GitOps, que son operaciones en base a Git porque tenés que hacer un push a un...
y viene Argo CD y mira cuál es el estado deseado. entender eso conceptualmente como programador te permite configurar esas cosas porque de eso se trata. Argo CD funciona también en base al estado deseado. Los manifiestos en Kubernetes o un Helm Chart es exactamente lo mismo. El Docker Compose.
es exactamente lo mismo, es el estado deseado, ¿cuántos servicios, cuántas cosas? Entonces, es importante que el developer entienda estos conceptos porque le va a facilitar su trabajo, de nuevo, aunque no sea responsable y no lo tiene que entender a profundidad exactamente, pero me gusta lo que está diciendo porque eso es una bondad para los developers, entenderlo, No tienen que administrarlo como tal. Bueno, quisiera ahora, Juan,
tocar un poquito de historia, un poquito de historia, pero no historia de la computación y comenzar a contar de cuando alguien comenzó, que la locura de Babash y cómo él crearon todo lo que tiene que ver con la computación hoy en día, sino que historia de nosotros, los que trabajamos en infraestructura, los que trabajamos en sistema.
Juan (22:28)
Ok, ok. Me gusta.
Douglas (22:52)
historia nuestra de los sysadmin de cómo se hacían las cosas antes de infraestructuras code y configuration management porque no han existido siempre, Las empresas grandes siempre han buscado implementar automatización lo más que se puede, procesos repetibles lo más que se pueda, pero no existían ese tipo de herramientas antes de ninguna manera. Entonces... ⁓
¿Cómo se manejaba la configuración antes de infraestructuras, código y configuración management? Pues uno, casi todo se configuraba a mano.
casi todo se hacía a mano, una cosa a la vez, un cambio a vez. Y se usaba mucho bash scripting. Con bash se usaba bastante scripts para crear los VMs o scripts para configurar los servidores, scripts para configurar servicios. Y había que estar copiando esos scripts en los servidores y estarlos ejecutando. Y si fallaba, luego el script era bien complicado porque tal vez
script corrió hasta la mitad y si te falló tenías que corregir el problema y no puedes sólo volver a correr el script desde el principio, toca correrlo desde donde quedó porque si lo corres desde el principio te va a generar un problema entonces se usaba bastante scripting, había bastante una falta de consistencia grande entre servidores de una misma aplicación por ejemplo vos tenés un cluster para una aplicación y tenías cuatro web servers
y aunque los configurabas con scripts te topabas con que querías incrementar el tamaño de headers que aguantaba Apache porque antes era Apache también, incluso querías incrementar eso y bueno te decías, ya está y te lo entrego y decías, ⁓ si está bien pero comenzabas a probar y mirabas que, fíjate que me falla de manera intermitente a veces funciona, a veces no, ¿qué será? y comienzas a ver y era que en uno de los servers no se hizo
porque tal vez sí me conecté al server, sí lo iba a hacer, pero creí que guardé la configuración y no la guardé. O sí guardé la configuración pero olvidé reiniciar el servicio, entonces no tomó la nueva configuración. Entonces había una cantidad de inconsistencias de manera constante. O sea, lo que era constante era la inconsistencia, ¿verdad? Pasaba todo el tiempo, definitivamente, porque es era propenso al error humano.
super propenso el error humano porque todo se tenía que hacer a mano y de nuevo aún en empresas grandes, a mí no me tocó llegar hasta ahí quiero mencionarlo, quiero aclararlo pero una empresa grandes utilizaban scripting o utilizaban Python, Python era bastante usado para esto llamaban los APIs de diferentes servicios internos o externos para
crear esta infraestructura o manejar estas configuraciones y lo hacían como de una mejor manera. Pero siempre son procesos de cierta manera manuales. Estar corriendo el script, estar viendo el resultado de ese script de nuevo, si fallaba a mitad de camino, no podías correrlo del inicio porque no podías repetir el mismo comando una y otra vez. Por ejemplo, para manejar asignos de configuración se usaba el comando set.
que SED lo que hace es que encuentra las instancias de una palabra o de una frase en un archivo y lo reemplaza por otro, ¿verdad? Y si yo vuelvo a correr SED otra vez después de hacer el reemplazo, me puede reemplazar algo que yo no quería que lo hiciera. me explico, era bien tedioso, era bien complicado. Y de las cosas más críticas que ocurrían, el antes del infrastructure as code y configuration management,
era que se dependía bastante de una persona o de algunas cuantas personas que eran el sabelotodo porque son los que configuraron la mayoría de lo que está, son los que entienden mejor la infraestructura y se dependía demasiado de ellos porque no había un registro de cómo se implementó, qué cambios hicieron, no hay un repositorio para ir a ver el historial, no había ni siquiera muy buena documentación.
Juan (27:09)
Ellos eran el chapdpt
de la empresa, que si quería saber algo a ellos le preguntaban.
Douglas (27:12)
y sí porque eran
eso, en los modelos ellos eran los únicos que se entrenaron con todo lo que había, ¿no? Y ellos te pueden decir, no es un problema de NGINX, no te contaron de que tienen por ahí escondido un archivo de configuración que no lo está leyendo, o no te contaron que copiaban un certificado de ese cell de manera manual, o sea, dependía de esta persona bastante.
porque no había como que un lugar central para hacerlo, verdad. Y por eso te digo hablar un poco de historia porque a mí me resulta chistoso cuando estaba recordando estas situaciones preparando este contenido de hoy que el antes de la infraestructura Scott casi suena como decir antes de Cristo. es, verdad? Partió la historia prácticamente para nosotros de sistema.
Juan (27:52)
y se escucha tan lejano
para muchos
Douglas (27:58)
se escucha alejando para muchos o se escucha como que nunca ocurrió, tal vez para los más nuevos. Me recuerda a un video que vi en Ticto recientemente que un padre le dice a la hija que subiera el vidrio de la puerta de un carro, pero el vidrio era manual. Entonces la niña se dijo, era una niña como de ocho años y ella llegó como confiada porque desde que largo vio dijo, yo sé qué es esto y al amanecía del...
Juan (28:02)
No.
Douglas (28:25)
le giraba la perilla porque esa amanecía es para que cuando le dé vuelta a toda la manivela gire con voz pero ella giraba la perilla así según ella si iba a subir el vidrio como la del volumen le daba y ella queda y no paró de hacerle para un lado para el otro y es jurada que así era pero no es culpa de las generaciones nuevas no pero pero si quiero que se pongan a pensar un poquito
Juan (28:27)
Sí.
como la de volumen
No,
Douglas (28:49)
los beneficios que traen y cómo era antes entonces, ¿verdad? Y realmente era bien complejo. Entonces no sé, Juan, en tu caso en particular, obviamente yo sé que vos no eras encargado o nunca has sido encargado de infraestructura, pero no sé si te tocó a verte afectado por este antes de infraestructuras, coding, configuration, management, ya sea porque tus aplicaciones de repente...
corrian en servidores o ambientes inconsistentes o ya sea porque tardaban en entregarte un ambiente porque como se hacía todo a manos tardaba en darte un nuevo ambiente o un nuevo cambio no sé si en alguna razón te viste afectado por estas situaciones
Juan (29:28)
No recuerdo algo en específico al momento de estar en una empresa, pero sí me había afectado directamente en ciertos proyectos que tuve que configurar en los diferentes servicios que te dan máquinas virtuales y te dan tu servidor. Y sí me pasó en varias ocasiones donde configuraba todo y tocaba algo que ni siquiera entendía qué es lo que
me tocó hacer eso incluso a veces configuraba los servidores y funcionaban pero ya no recordaba por qué funcionaban ya no recordaba qué es lo que había hecho realmente no tenía un punto de referencia al que podía ir y revisar a ok está configurado así así así y bueno eso sí sí me pasó pero bueno eran eran proyectos muy pequeños para uno que otro cliente que tuve al inicio y pasé
⁓ pero bueno, en una empresa, realmente no recuerdo algo en este momento porque en cierto momento, como que pasé muy rápido a...
de contenedores al menos en un aspecto profesional en una empresa entonces como que me salvé un poco de esa parte si en cierto momento recuerdo bueno de hecho recuerdo que con vos tuvimos un proyectito que estaba hecho en Node.js y vos me ayudabas a bueno vos lo manejabas no del lado de operaciones pero como ya tenías mucha experiencia no recuerdo como un problema tan grande
Douglas (31:20)
Sí.
Juan (31:42)
grande, de ese tipo. Pero bueno, sí lo viví de primera mano el hecho de tener que volver a hacer todo desde cero, una y otra vez, en aquellos entonces.
Douglas (31:54)
Sí, bueno
con este proyecto que decís ya utilizábamos Puppet para el Configuration Management, había menos problemas y justo eso que acabas de dar como ejemplo de que en tus proyectos personales te topaste con estas situaciones de tener que repetir todo y comenzar de cero a mano es una de grandes bondades y usando eso como continuidad me gustaría que continuemos con la historia entonces a la...
ya la llegada de la infraestructura as code y configuration management o el después de, si lo queremos poner desde un punto de vista histórico, en el calendario el después de infraestructura as code, IAC y ICM, configuration management. Pero el después Juan, bueno, facilitó el trabajo para los sysadmin. Sysadmin era mayormente el rol en ese momento, en su momento.
Juan (32:32)
de IAC
Sí.
Douglas (32:50)
pero facilito el trabajo para los sysadmin. Esta bondad de usar el código para manejar la infraestructura y las configuraciones realmente que cambiaron muchas cosas. Cambiaron, cambió bastante la práctica de code review y pull request y todo ese tipo de cosas, cambió bastante. Esto de trabajar con un estado deseado.
el de desire state, el de trabajar con esa mentalidad.
era más práctico, era más fácil enfocarse en eso que el estar viendo cómo administrar bastantes servidores a la vez. Obviamente el tiempo, porque también facilitó los procesos para el departamento. No solo hizo la vida más fácil al sysadmin como tal, a cada sysadmin, pero el departamento se benefició de los procesos, los ambientes se entregaban más rápidos o los ambientes se hacían también más rápidos, más seguros. Era mucho más consistente.
mucho más consistente porque tenías algo ejecutándose, asegurándose de levantar lo mismo siempre. Igual en infraestructuras code, si vos vas a crear una instancia o una VM, porque en ese momento trabajábamos on-prem y aunque...
en lo que yo estuve en esta empresa anterior donde vos y yo nos conocimos, usamos infraestructuras code como tal, ya para el final cuando yo iba salir porque implementamos tantas cosas, ¿no? Pero ya para entregar una VM como creas tus propios módulos para crear instancias o crear VMs, esos módulos ya traen esa configuración por defecto que crees y por proyectos solo te aseguras de personalizar las cosas que ocupas personalizar. Entonces había una consistencia.
en todas las partes de la infraestructura y en todo lo que tenía que ver con las configuraciones. Y también, Juan, aquí va de la mano con lo que vos decías, facilitó el proceso de disaster recovery. Para quienes no sepan, disaster recovery es un plan de qué hacer si para alguien que corre en data center, si diferentes escenarios de desastre, si se me arruina un servidor, entonces tenemos un escenario de desastre, cómo hacer para...
ver o incluso continuar trabajando si es posible, si se me daña un rack por completo, tener un escenario de cómo reaccionar y cómo restaurar tus servicios y cómo continuar trabajando en base a ello, si el data center por completos agarra fuego ¿verdad? ¿Cuál es el plan de desastre alrededor de ello? Una empresa grande, estable, a veces no puede permitirse estar...
sin sus servicios corriendo. Entonces, facilitó el proceso de Disaster Recovery porque como tenía este código repetible fácilmente, era mucho más rápido y mucho más consistente de ser necesario en el peor escenario donde todo se destruye, comenzar en otro data center y volver a levantar los servicios.
ejecutando tu código de nuevo. no digo que no sería doloroso o tedioso un escenario así, porque sí lo sería, pero imagínate que tuvieras que hacer lo que vos nos acabas de contar. Tener que volver a hacer 300 máquinas virtuales o 15, 20 clóset de Kubernetes o más, de cero a mano, uno por uno. eso sí sería un dolor de cabeza terrible.
Juan (36:24)
Sí,
no se lo desea a nadie.
Douglas (36:25)
Sí,
sí, sí. Entonces, facilitó el proceso de disaster recovery, la planeación como tal, porque idealmente tenías que trabajar en un plan de disaster recovery y luego tenías que, esto son cosas de best practices, son mejores prácticas en IT, poner a prueba, mínimo una vez al año.
tu plan de disaster recovery. Entonces imagínate tener que probar un disaster recovery creando máquinas virtuales una por una, ¿verdad? Era un trabajo bien duro. Y ya cuando tenías infraestructuras Codic, Affiliation Management, era muchísimo más rápido hacerlo. Entonces esas de las cosas, beneficios que trajo. Y yo creo que con esto del disaster recovery, como para dar un ejemplo,
Juan (36:56)
Sí.
Douglas (37:15)
a las personas que vienen entrando a estos conceptos. Y infraestructuras code y configuration management sería como el caso de cocinar con receta contra cocinar de ojo, ¿verdad? Así como que la señora, ¿va? Tienen un ojo, bueno, ellas al tanteo le dicen aquí en la región donde yo vivo, ¿va? Le dicen al tanteo.
Juan (37:33)
Sí.
y le echa ahí un poquito
de tal y un tanto de tal
Douglas (37:42)
Ajá, echele una pizca de sal
y pero vos mirás que le eche un montón y si yo quiero hacer lo mismo a mí me queda salado, ella le quedó bien rico, verdad, o lo que para mí no quedó salado, para vos si se siente salado porque así es cocinar al tanteo, cocinar al ojo, pero si tenés una receta que te dice tanto gramos de sal, tantos cucharadas de esto, vas a tener un resultado más consistente.
Juan (37:47)
Sí.
Sí.
Douglas (38:07)
Entonces, ese es el mejor ejemplo fuera de tecnología que les quiero dar, que les puedo dar, perdón, para que se hagan la idea de por qué hay consistencia ya con infraestructuras code y configuration management y por qué antes de ello no lo había a pesar de que se trabajaba mucho en buscar automatizar con scripting, con código, etcétera. Ahora, Juan, aquí es donde quiero tu perspectiva si lo queremos ver de esa manera, ¿verdad? Y es que...
en la historia implementar prácticas de desarrollo de código en el área de infraestructura en el área de sistemas ha traído bastantes beneficios recientemente así se origina srb por ejemplo verdad o sea google intencionalmente creó un puesto que va a utilizar prácticas de desarrollo de código para administrar infraestructura
recientemente fue así. Configuration Management y Infrastructure Transcode fueron como que las primeras soluciones que crearon un cambio disruptivo en la industria, son prácticas, porque permiten implementar estas prácticas de desarrollo de software en el manejo y configuración de infraestructura.
Y eso es algo bien interesante, fíjate, el cambio que ha tenido la industria implementando esas prácticas que son de desarrollo de código y esto es un... por si no lo habían visto de esa manera tanto developers como gente de infraestructura, eso es una realidad. El desarrollo de código ha sido tan sólido y tan bueno.
Juan (39:23)
Sí.
Douglas (39:43)
y ha mejorado a lo largo del tiempo que le hemos copiado esas cosas en el área de infraestructura, ¿verdad? Entonces, desde tu perspectiva como de velo, pero Juan, no sé si eso es algo que vos habías notado, si has captado esa evolución trabajando porque de nuevo yo sé que no ha sido tu responsabilidad manejar la infraestructura, pero si has trabajado de cerca, bueno es más, por eso nos conocimos y llegamos a trabajar también, ¿no? Porque vos has estado en esa parte. Entonces, no sé si eso es algo que vos habías notado, Juan.
Juan (39:48)
mmm mmm
Douglas (40:11)
y que lo has visto evolucionar a lo largo de los años y tu experiencia.
Juan (40:16)
pues te diré que bueno.
algo que yo noto mucho, sí claro, la evolución del lenguaje mismo ayuda a estas herramientas y bueno lo que se me viene a la mente con lo que estás hablando o lo que he recordado en este momento es como por ejemplo Go ha ayudado mucho a diferentes herramientas que tratan de solucionar muchas de estas cosas, aún cuando no son tal vez directamente infraestróficas
y yo reviso en cada actualización que se está haciendo y reviso los release notes veo que están introduciendo lenguaje que están arreglando y empezó a notar como estas herramientas que tienen que ver más con el hardware y
y todo esto se ven beneficiadas realmente hay una intención por parte del equipo de darles mucha ventaja a todo este grupo de personas que están desarrollando herramientas y soluciones que se aprovechan del lenguaje para llegar a un nivel más óptimo más óptimo, mayor estabilidad y más fácil también, más fácil de usar por ejemplo
lo mencionaste si no me equivoco
utiliza diferentes lenguajes de programación para poder hacer esto y vas a utilizar uno en el que te sientas cómodo claro pero también un lenguaje que a medida ha ido evolucionando te permita realizar estas tareas de manera más fácil o incluso más óptimas vas buscando un balance así que sí no no es algo que lo había notado tan directamente pero pero
si a medida he visto estas herramientas y veo lo que hacen con los lenguajes definitivamente empiezas a hacer una correlación de cómo se ven beneficiados con algo que creeríamos que es sólo para crear aplicaciones, página web, aplicaciones de escritorio también está este otro sector que definitivamente se ve beneficiado que bueno creo que es una consecuencia de cómo
actualmente cuando hablamos de programación lo que se nos viene a la mente en su gran mayoría es programación web ha sido un auge muy grande que ha tenido y creo que bueno de hecho ya tuvimos una plática en cierto momento con Douglas lo pueden ir a ver en el canal donde hablamos de por qué los se inclinan más a programación los ingenieros y específicamente programación web pero creo que debido a eso a veces olvidamos ⁓
que programación o programar involucra muchas cosas y uno de los aspectos más grandes es eso, involucrarte con el hardware o la virtualización directamente. Así que es interesante cómo los lenguajes van evolucionando y te van dando estas ventajas a un departamento que tal vez no lo pensarías de primera mano, no lo verías.
Douglas (43:48)
Sí, sí, sí, sí. No, y yo creo que el mensaje aquí con esto, Juan, porque bueno, los hechos hablan por sí solo y está demostrado que esta práctica de desarrollo de software y la evolución del código ha traído beneficio a la parte de infraestructura, y los hechos hablan, es que desde que alguien comienza con un script para automatizar cosas, un script como tal, si bien es cierto, es una secuencia de comandos, pero un script es un principio de código.
usas validaciones, usas un if, usas loops, usas bloques de código, usas funciones en un bash script para ejecutar procesos. aún cuando hacemos un bash script, estamos implementando una práctica de desarrollo para automatizar infraestructura de cierta manera. como que el mensaje aquí es que entendamos y que veamos cómo es el complemento y cómo es realidad.
Juan (44:14)
Sí.
Sí.
Douglas (44:41)
los programadores que destacan son programadores que...
han buscado entender la parte de infraestructura y han podido crear ese tipo de herramientas de la misma manera que los de infraestructura que destacan son los que han buscado entender la parte del código porque son los que pueden ser más eficientes. eso es como un mensaje ahí para que no seamos cerrados y tal vez por eso Pulumi recibe un poco de hate de cierta parte de la comunidad de infraestructura porque sí, porque Pulumi al usar código ellos usan la bandera de que podés
Juan (45:09)
En serio.
Douglas (45:15)
utilizar lógica para crear infraestructura, de que vos puedes venir y decir si tal cosa existe, entonces créame esto, pero si no existe no lo hagas, porque usas un lenguaje de programación y los puritanos de la área de, y no lo digo esto con intención de hate, pero pues cuando digo los puritanos son personas que creen que no podemos salirnos de lo mismo, dicen hey, pero el infraestructuras code es un desire state.
no tengo que aplicarle lógica, entonces ya no es infrastructure as code porque no es desire state, pero es código y es para crear infraestructura y mantenerla, parece que sigue siendo infrastructure as code.
Juan (45:53)
Para mi es muy ventajoso. tengo un, yo a medida que pasado el tiempo en mi trabajo, he desarrollado un CLI. Que bueno, es como baby steps, podríamos decir. Es un CLI que me permite levantar diferentes instancias de todo el stack que yo necesito para trabajar. Mi stack involucra muchas cosas. Levanto todo el sistema de monitoreo, toda la parte de colas.
bases de datos, diferentes bases de datos, diferentes servicios, etcétera, etcétera. Un servidor de archivos, tengo un...
no se como seria la palabra pero es como la version de un S3 dentro de mi local levanto muchas cosas es normal pero no me gusta manejarlo mediante BashScript y tampoco mediante el Makefile no porque no sirvan claro que funcionan y son muy beneficiosos son muy fáciles pero mediante código y en este caso lo hice en Go principalmente para entender algunas cosas la ventaja que
yo veo como programador es que me permite ver tipos de datos, me permite crear funciones de manera más elegible para mí, puedo crear diferentes paquetes y puedo hacer importaciones, puedo tratarlo como un código y eso me permite hacer pequeñas partes de código con lógica, por ejemplo puedo hacer de
que
si yo le paso una variable, me va a levantar todas las instancias, si le paso otra, va a levantar una instancia en específico, eso es algo básico, ¿no? Pero también puedo pasarles ciertos valores para indicarle, si tengo este valor, entonces voy a ir a buscar a este directorio y en este directorio voy a hacer esta otra cosa. Y me permite hacerlo dentro de un lenguaje que, número uno, yo entiendo, pero más allá de eso, es un lenguaje que me permite estructurarlo de una manera más simple.
⁓ más fácil y me permite agregarle más cosas a medida va pasando el tiempo me permite irlo modificando etcétera etcétera y bueno eso es lo que yo imagino con las herramientas que están hechas específicamente para infrastructure as code que te dan estas ventajas de lenguaje como tal con bash script si bien lo haces pues dependiendo de lo que necesites tal vez no lo necesitas pero
puede que en un momento necesites tener estas bondades que te da el lenguaje y pues ahí es donde va a brillar, creo yo.
Douglas (48:43)
Sí, y con ⁓
numérico, etcétera. Pero como que la mayor división que ha habido es que herramientas como Pulumi, que tienen su audiencia pues, pero herramientas como Pulumi te hacen que vos pensés en la lógica para crear los recursos, mientras que herramientas como Terraform, CloudFormation, el mismo Crossplane, vos solamente definís el estado deseado.
que hay diferencias, Pero es que ahí depende de la herramienta. Mira, te voy a decir mi opinión al respecto y las personas que nos ven y nos escuchan desde ya tiempo saben que aquí en DevOps nos caracterizamos por tener mente abierta, ¿no? Tenemos una opinión, supuesto, tenemos una opinión, tenemos preferencias, claro que sí, pero tenemos una mente abierta, ¿no? Entonces, mi punto de vista al respecto es que cada herramienta te da...
pros y contras, bondades diferentes. Yo saqué un certificado, Juan, de Puppet, porque yo te mencioné que empecé con Puppet. Este certificado lo recibí presencial y el instructor, alguien que por cierto era un guru en Puppet en su momento, Larry... Danusa, algo así, no me acuerdo, el apellido era un poco raro. Pero este chavo, Gary...
él dijo, comenzó diciendo, levanten la mano, quienes programan. Varios levantaron la mano, yo levanté la mano y programaba mis cositas. Entonces él dijo, lo primero que quiero que hagan es que agarren todo lo que saben de programación, sobre todo programación orientada a los objetos, y lo tiren a la basura. Para Popet, dijo él, para Popet, no para su vida. Y mí me causó gracia, pero es que para Popet tiene sentido.
porque POPit es el estado deseado y si vos querés afrontarlo como programación te va ir mal con POPit con esa herramienta ahora esa lógica siempre ocurre Juan yo no la manejo, yo no me encargo el backend de POPit va a hacer esas validaciones va a ver si el recurso existe, si no existe y va a hacer cambios y va a ser un, si le pedí varios va a ser un for o un while o lo que sea que va a hacer en el backend
Lo mismo con Terraform, yo configuro un estado deseado, pero Terraform es una herramienta que está para eso. En el backend, Terraform va a ser su lógica. Mientras que Pulumi sí está hecho con la intención de que developers manejen su infraestructura como código, por las bondades que tiene, pero Pulumi sí te deja que vos trabajes la lógica. Entonces, depende de la herramienta. Al final el concepto de infraestructura as code es tener tu infraestructura en código.
Juan (51:03)
Sí.
Douglas (51:33)
Entonces, por ahí va el asunto, pero si, dependiendo que herramienta manejes, no vas a usarlo como programación y no te vas a preocupar por lógica. Y consideremos de nuevo las personas que ya tenemos bastante tiempo de infraestructura, que son las que a veces nos volvemos cerradas, antes lo hacíamos, antes de estas herramientas, antes nos tocaba hacer Varscripts o en Python y crear lógica, llamar API, antes nos tocaba hacerlo para tener infraestructuras code.
y validar y crear la instancia y no volverlo a crear y entonces hoy en día no nos volvamos cerrados en ese sentido porque cada herramienta va a tener su bondad, en fin. ⁓
Juan (52:16)
y con eso
solo me gustaría como añadir Douglas que como 10 de CIS cada herramienta tiene sus pro y contras entonces vale la pena dedicarle un tiempo a investigar cada una de ellas y ver cual es la que se acopla mas a lo que necesitamos de hecho la primera vez que vi o escuché sobre Pulumi fue en el trabajo el CTO llegó y nos dijo hey esta herramienta y la he estado probando y dijo creo que para no
nuestro caso nos va a bien por esto, esto y esto. Entonces no es algo que empezaron a utilizar, no lo utilizaron porque sí, sino como, ⁓ nos va a dar una ventaja por esto o otro, porque en nuestro está que en nuestro caso de uso cae bien, puede ser utilizado, pero puede ser que no para otra empresa no vaya a ser tan útil, entonces va a ser más útil otra herramienta.
Así que por si alguien está escuchando que estamos hablando o estás mencionando muchas opciones, porque hay bastantes opciones, pues siempre vale la pena investigar cada una de ellas y ver cuál se acopla mejor ⁓ a cada área, a cada empresa y proyecto.
Douglas (53:34)
Así es,
sí, no muy de acuerdo con vos en ese sentido Juan. Siempre aquí en este espacio animamos a los profesionales a que tengan mente abierta y busquen la herramienta correcta y no guiarnos por preferencias solo porque sí, verdad, entonces muy de acuerdo con vos en ese sentido. Y si te parece para continuar entonces con el tema Juan, me gustaría que entonces ahorita entremos a ver cómo se complementan infraestructuras code.
y Configuration Management porque ya aclaramos que no son lo mismo. No tienen como que la misma funcionalidad, pero si se complementan al final para que pueda tener todo en código a nivel de sistemas, a nivel de infraestructura, ocupas el Infrastructure as Code y ocupas el Configuration Management. ¿Verdad? ¿Y cómo se complementan? Yo creo que la respuesta es bien sencilla, Juan, y es que con Infrastructure as Code desplegas la infraestructura.
ya sea on-prem, o sea en tu propio data center, crear máquinas virtuales, crear storage, crear recursos de firewall, que sea que necesites, Con infraestructuras code crear infraestructura también puede ser en cloud o híbrido.
Pero con infraestructuras code, creas esa infraestructura, corres tu Terraform, corres tu Pulumi, corres tu Crossplane, levantas infraestructura, luego con Configuration Management.
configurás esos servicios, configurás el sistema operativo, configurás NGINX, configurás tu web server, configurás incluso servicios, si tenés servidores de correo, bases de datos, Redis, Memcache, lo que sea, servicios que sean, los configurás entonces luego con Configuration Management. Esa es la manera simple en que se complementa, ¿verdad? Tan sencillo como eso. Ejemplos, bueno.
digamos que usamos uso terraform para levantar el cluster web, verdad, me va a crear, digamos que es en AWS, va a crear el VPC, me va a crear los subnets, me va a crear IAM policies, roles, si todo lo necesario, va a crear el loudscaling group para que escale.
Juan (55:38)
Ok.
Douglas (55:54)
Reduzca las instancias en tráfico, va a crear load balancers, target groups, va a crear todo con Terraform. Y luego, digamos, uso Ansible para configurar los diferentes servicios, para los paquetes base del OS, del sistema operativo, para los log files, para permisos, para reglas de sudo, para instalar PHP y Nginx, para configurar Nginx, los diferentes permisos, diferentes directorios, los diferentes endpoints, para configurar PHP, memoria y recursos.
Y de esa manera es un ejemplo práctico de cómo se complementarían los dos. O lo podemos llevar a Kubernetes. Con Terraform creo el clúster de EKS. De nuevo, va a crear todo, VPC, las políticas, todo lo que necesita Kubernetes, los diferentes permisos, lo voy a crear con Terraform. Y luego usando Ansible puedo configurar los servicios básicos del clúster.
como instalar cluster autoscaler, external DNS, ingress, manager. También aquí se pudiera usar y de hecho es mejor o más deseado en Kubernetes hoy en día usar algo como GitOps, Argo CD como vos decías y también las otras herramientas que existen para GitOps pero ya luego poniéndolos en ese sentido esa es la manera en que se complementan.
Y es que me ha tocado, fíjate Juan, interactuar con infraestructura que fue creada con Ansible. Porque yo te mencionaba que Ansible te permite crear una instancia de instituto, permite crear estas políticas, te permite crear los recursos que querrás en AWS, en diferentes nubes, te permite incluso interactuar con VMware y crear una VM, porque existen todas estas cosas. Pero fueron creadas.
Juan (57:47)
O se podría tener solamente
Ansible para hacer todo. En teoría.
Douglas (57:51)
Sí, sí,
sí, podrás tener solamente Ansible para hacer todo y lo puedes hacer, pero no es para eso la herramienta. Es más lenta, se queda esperando a que el recurso se cree y luego cuando querés hacer un cambio lo tenés que volver a correr y por ejemplo si tenés Ansible al mismo tiempo que está creando configuración, hago un cambio de configuración, pero Ansible notó que incrementaste el...
el disco duro y lo va a querer revertir porque como es el mismo rom para infraestructura y para configuración entonces empieza a volverse tedioso verdad sí exacto así lo pudiera ejemplificar si querés no porque como mismo rom que eres cambiar infraestructura y cambiar configuración pero cuando esto lo estoy cambiando infraestructura va a querer tocar configuración verdad
Juan (58:31)
Es juez y parte.
Sí.
Douglas (58:47)
Idealmente no deberías de cambiar infraestructura ni configuración fuera de tu automatización, idealmente no querés hacer eso, pero a veces pasa, entonces se vuelve conflictivo, se vuelve tedioso y de hecho, continuando con experiencias propias, hoy en día en la actualidad, en field, lo que antes era Tendop, ahora nos llamamos field, por eso no se alcanza a ver creo la F en mi camisa porque es field.
Juan (59:14)
Ok, ok,
sí.
Douglas (59:16)
¿Verdad? Se crea, fíjate, lo que es la infraestructura para hosting mayormente de sitios WordPress y que corren en Kubernetes, se crea con Terraform.
pero también con Terraform se crean, se instalan estos paquetes base en Kubernetes que te mencionaba de Ingress, de Cert Manager y todas estas cosas se hacen con Terraform y eso nos ha traído una de problemas, eso algo que ya estaba ahí desde que yo llegué, es algo que heredamos, ¿no? No, no, no fue mi culpa. Comprendo como inició.
Juan (59:48)
No fuiste vos.
Douglas (59:58)
Y es que por eso tienen esta funcionalidad tanto Ansible que te deja crear instancias como Terraform que te deja crear configuraciones, manejar configuraciones. es que a veces ocupas crear la infraestructura y configurar una cosita. Y lo haces de un solo. O a veces con Ansible, por ejemplo, aplicar una configuración y crear un recurso. Y lo creas de un solo. O sea, como que por ahí nace el propósito de estas cosas. Y así comenzó.
de que usaron Terraform para crear infraestructura y luego configuraciones. Pero fue creciendo y le fue agregando más y ahora es bien complicado. Toca correr Terraform dos veces mínimo. Se corre una vez y se usa como creas módulos. Se corre una vez y se usan los flags de target. Y le decís, targetíame solo estos módulos que son los que van a levantar la infraestructura primero. Porque si lo querés correr de un solo...
Cuando Terraform quiera correr y quiera crear un recurso dentro de Kubernetes, como es un clóset de Kubernetes que todavía no existe, no se puede conectar a él y no puede validarse el recurso existe o no. Porque recordemos que Terraform trabaja con Desired State. Y antes de correr, va a ver cuál es el estado actual, lo compara contra el Desired State y hace los cambios. Pero ¿cómo puede hacer eso con un clóset de Kubernetes que todavía no existe?
Juan (1:01:16)
Ok
Douglas (1:01:20)
porque lo estoy corriendo por primera vez, entonces hay que correrlo en dos fases mínimos usando Target y nos ha generado uno de problemas y complicaciones, ¿verdad? Y estamos, de hecho, ya es un esfuerzo que ya lleva su buen tiempo, estamos actualmente y recientemente lo estamos atacando con mayor intención de cambiar eso, ¿verdad? Y estamos analizando si movemos la parte de configuración a algo como Argo CD, ¿verdad?
Juan (1:01:20)
No,
Ok
Douglas (1:01:48)
o que otras herramientas utilizamos en ese sentido, pero aún en la actualidad me topo con eso y son ejemplos, esos Juan, en mi experiencia han sido ejemplos de implementaciones erróneas. Comenzaron con una buena intención tal vez, pero no se ejecutaron bien, ¿verdad? Y la manera correcta es que se complementen. Y este es el mensaje que quiero transmitir.
con Infrastructure as Code, desplegamos y mantenemos infraestructura y con Configuration Management nos encargamos de toda la parte de la configuración. Entonces, ahorita hay que escuchar los conceptos, que incluso un par de experiencias mías, no sé si te ha tocado ver eso como mal implementado, mal utilizado de alguna manera en tu experiencia, tanto en sistemas o en cosas que te has querido involucrar, o si no...
pues tal vez qué pensamiento querés compartir en este sentido.
Juan (1:02:43)
pues más que todo...
como que me relaciono en el aspecto que es similar a cuando configuras mal tu código de programación, la base del código por ejemplo, a mi me gusta mucho este concepto de manejarlo por capas una capa de repositorio, una capa de business y otra capa de presentación claro que lo puedes hacer en un solo archivo, en un solo directorio y ahí tenes todos los archivos y el mismo archivo
se conecta a base de datos y ese mismo archivito también te devuelve la petición o la respuesta a HLTP pero con el tiempo se vuelve muy tedioso hacer cambios es un poco más lento en hacer cada uno los procesos porque está haciendo todo el solito entonces sí puedo entender el porqué no es recomendable utilizarlo para lo mismo pero supongo que también se debe a que te brinda esta ventaja
y como lo mencionabas tal vez la intención original detrás de la herramienta era bueno vas a poder levantar estas un servicio por aquí una configuración por allá tal vez no esperaban que la gente lo utilizara para todo pero bueno si te dan la oportunidad de hacerlo alguien lo va a hacer así de simple
Douglas (1:04:07)
Sí, sí, sí, cuando si das la opción así no va a faltar quién es de nosotros lo hacemos mal.
Juan (1:04:14)
sí sí
sí sin embargo me quedé con una con una duda Douglas en el configuration manager o management allí también guardas contraseñas y información sensitiva o esto debería estar en otro lado me refiero por ejemplo a las el usuario contraseña para la base de datos y otros servicios
Douglas (1:04:41)
No, la respuesta es no y la forma
más fácil en que te puedo responder a vos como programador es, de la misma manera que trabajas con información sensitiva en código, de esa misma manera trabajamos nosotros. Se usan secrets, se usan bolts para...
ir a leer esos secrets y correrlos Ansible tiene su propio sistema de secrets y quieres usar el de ellos que lo que hace es que te crea un hash inmenso le usa un key que obviamente es un key privado para para encriptarlo y genera un hash inmenso que solo con ese key lo puedes utilizar de lo contrario no se va a decodificar y entonces lo puedes subir a tu código sin problema
porque incluso claro porque te agarra todo entonces es un hash enorme o puedes usar conectarte a otros bolts de hecho terraform este hash corpse que son los que crean de empresa que crea terraform tienen uno de los secret manager de los más grandes utilizados porque para lo mismo es para que ahí guardes tu secrets y ahí se conecta para crear ese tipo de cosas
Juan (1:05:49)
Mm-hmm.
⁓
Douglas (1:05:53)
Entonces,
de nuevo, lo mismo que en código, nunca metes en el código y comitías un token, lo puedes hacer, o puedes crear la variable token, igual, y pones el token y lo comitías al código, pero eso sería la peor práctica, lo mismo lo pudieras hacer si quieres en configuration management, pero existen estas otras herramientas que lo hacen. Y fíjate que para poner en ejemplo...
Lo que vos dijiste de usar mal una herramienta con otra, a mí es que se me ha venido a la mente siempre cuando empiezo a usar mal Configuration Management y Infrastructure as Code. En desarrollo se me viene, por ejemplo, solo porque la base de datos, digamos, MySQL, MariaDB, te permiten hacer lógica a nivel de la base de datos, no necesariamente es el lugar correcto para hacerlo, ¿no? Porque entonces, baja ma...
Juan (1:06:44)
Ok.
Sí.
Douglas (1:06:49)
la base de datos si lo pones a hacer una lógica muy grande e incluso si lo vas a hacer así hay que usar esto el proceder y cosas cosas así verdad o sólo porque en el front end puedes hacer un cálculo de algo y vos decís a no lo voy a hacer en el servidor que lo haga el cliente pero probablemente va ser muy vulnerable porque tal vez vas a guardar algo en el front end entonces sólo porque es posible hacerlo ahí
Juan (1:06:58)
Sí.
Douglas (1:07:14)
no necesariamente es la mejor opción. La herramienta se creó para hacer cosas más simples o más sencillas y entonces hay que saber usar la herramienta correcta para cada cosa. Ese sería el mejor ejemplo que yo le pudiera dar a desarrolladores de una forma incorrecta de utilizar infraestructuras code para manejar configuraciones o una forma incorrecta de manejar configuration management para manejar infraestructura.
Juan (1:07:41)
muy cierto, eso de utilizar la base de datos así sí, me ha pasado, lo he vivido y no es bonito.
Douglas (1:07:51)
Sí, no es bonito, igual yo he visto casos de personas que han corrido reportes directos en la base de datos de producción y ha sido un caos. Ya cuando las recuerdo, nunca fui yo gracias a Dios, pero ya cuando las recuerdo son historias un poco, son chistosas, pero en el momento realmente era bien caótico. Sí, sí, sí, Pero bien, yo creo que avancemos Juan y ahora quisiera tocar...
Juan (1:08:03)
jajaja
No eran chistosos.
Douglas (1:08:21)
errores comunes al momento de pensar o trabajar con infraestructuras code y configuration management a la hora de quererlo implementar. Y quiero comenzar diciendo que un error común es pensar que sólo son para empresas grandes o equipos grandes.
creemos de que no, en este, nosotros somos un equipo de dos programadores y uno de sistemas y solo manejamos seis servidorcitos y no, nosotros no lo ocupamos, no encaja para nosotros o más bien nos genera un atraso porque de aquí que lo implementemos mejor voy a enfocar en el código, en crear un nuevo feature, verdad, y eso te parece cierto hasta que ocurra lo que vos dijiste Juan que...
perdemos la configuración por completo y ni siquiera me acuerdo cuál era la configuración que funcionó, ¿verdad? Entonces no es solo para empresas grandes o equipos grandes.
Juan (1:09:18)
incluso si solamente
tengo un servidor, ¿lo recomendarías?
Douglas (1:09:24)
Si nunca vas a tener más de un solo servidor, no. O sea, si vos estás convencido que nunca vas a tener más de un solo servidor, no. Si vas a tener un solo servidor y puede que tal vez tengas más, todavía no. Porque a ese punto sí te va a tomar tiempo.
usar el código para una sola instancia y no va a ser así, pero en el momento en que vos ya mires que vas a ocupar uno más, implementarlo, ese sería mi consejo.
Juan (1:09:59)
Pero bueno,
en teoría deberíamos tener una redundancia y al menos dos servidores.
Douglas (1:10:10)
sí es que
ese es el punto, cuando es en producción ese es el punto, igual Juan si no de nuevo si solo vas a manejar uno y tu equipo va manejar un solo servidor, pudieras hacerlo sin ello pero tenés que tener documentada la configuración porque de nuevo si lo perdés querés repetir esa configuración y qué es lo que pasa ahí mira si un día haces un cambio y se te olvidó documentarlo
Juan (1:10:24)
Ok, ok...
Sí.
Douglas (1:10:36)
ya no lo vas a replicar si ocupas replicarlo de volver a crear la instancia desde cero porque se dañó o algo mientras que con infraestructuras code tenés que hacer un commit sí o sí entonces no, ahí no hay olvido de documentación, ¿me entendés? verdad entonces es un error común yo te decía que al final infraestructuras code como tal en la empresa que vos y yo nos conocimos yo lo empecé a ya para el final y lo empecé a implementar
Juan (1:10:42)
Sí.
Douglas (1:11:05)
Y la forma en que lo empecé a implementar es que lo que yo manejaba lo hacía con infrastructure scope. Lo hacía público para que cualquiera pudiera entrarlo, pero yo lo manejaba de esa manera. Entonces sirve para todos y el beneficio es para todos. Yo he mencionado antes en otros episodios como en nuestro sitio de Ben Ops corre en un clóset de Kubernetes. ¿Verdad? Podrá parecer totalmente overkill o algo.
solución demasiado grande para lo que es, corro otras cosas en ese mismo cluster, pero el cluster lo cree con Terraform, verdad, y la configuración la manejo de cierta manera con Configuration Management, porque ahí va expandiendo y va creciendo, entonces no es sólo eso. Otro que se comete Juan, cuando se quiere implementar o cuando ya se ha implementado, sobre todo si el equipo es pequeño, es subestimar la documentación.
Juan (1:11:47)
Sí.
Douglas (1:12:01)
porque no vas a documentar la configuración, está en el código. Es como cuando haces backups para tu aplicación, vas a un backup de la base de datos o puedes hacer un backup de la configuración. Pero no haces un backup de los archivos de la aplicación porque tenés el código fuente.
Juan (1:12:05)
ok
Douglas (1:12:19)
que solo generas, haces un build y lo volvés a tener. O sea, no ocupás hacer un backup del código fuente porque el repositorio es tu backup en ese sentido. conceptualmente aplica lo mismo en Infrastructure as Code. No vas a hacer un respaldo de la configuración como tal porque es tu código. Pero sí el proceso.
Juan (1:12:21)
Sí, sí.
Douglas (1:12:42)
sí, cuál es el módulo para crear instancias de S2, qué framework interno creaste, en qué bucket guardaste el estado porque Infraestructura Code crea un estado de lo que creó y eso es lo que usa para ver.
qué hay actualmente en tu infraestructura y cuál es el último estado que él tenía y ahí hacer los cambios necesarios. Entonces, se subestima la configuración, la documentación, perdón, y que son estos procesos de cómo trabajar, de cómo colaborar. Entonces, eso es un error común que yo lo he visto y me he topado con clientes que tienen su ansible.
y me dicen ah aquí está y no hay documentación entonces hay que ir a hacerle reverse engineering a la documentación y luego querés ejecutar Ansible y te dice que va a ser una cantidad infinita de cambios y no hay documentación, un error grave ¿verdad? Otro error
Juan (1:13:33)
Yo soy la documentación.
Y es que eso pasa
en todos lados Douglas, porque obviamente del lado de programación también eso es algo con lo que uno tiene que estar peleando constantemente y me incluyo, no me gusta documentar muchas veces, pero yo le encuentro mucho valor a...
a este tipo de documentación. Incluso me gusta mucho la documentación del por qué. Por qué se hace tal cosa, por qué se hizo de esta manera en específico. Me imagino que lleva una secuencia, ¿no? A veces me imagino que debemos, te ha tocado tal vez que esto se va, que ejecutar antes de esto por x motivo. la documentación del por qué se está haciendo así es muy valiosa porque puede ser que en un futuro alguien diga, bueno,
si lo muevo aquí gano unos cuantos segundos en el tiempo de ejecución pero tal vez no sabe que tal vez gana tiempo de ejecución pero se rompe otra cosa entonces la documentación bueno eso es algo que creo que a nadie en tecnología le gusta o lo disfruta es muy raro alguien que diga así a mí me gusta documentar pero bueno es necesario hay que hacerlo en todos lados
Douglas (1:14:59)
Sí, sí, definitivamente. Y yo soy alguien que tampoco me gusta documentar, sin embargo procuro documentar todo, ¿verdad? Procuro documentar todo definitivamente. Lo que ocurre con infrastructure as code y configuration management es que se llega al punto de creer que no se necesita, sobre todo cuando no es mucho, cuando no está manejando tanto, ¿verdad? Porque creemos de que solo es de correr Terraform, solo es Terraform apply.
y ya, o solo es ansible, correr un playbook de ansible y ya estuvo. Cómo creemos que no es necesario, yo no sé si te ha pasado Juan de creer que hiciste algo pequeño, un script tal vez o algo y decís no es necesario documentarlo, es pequeño, esto es simple, verdad, y a los dos años te piden hacer un cambio y no te acordás siquiera por qué, por qué hiciste eso, Y entonces...
una vez me topé con una situación de esas y digo yo bueno hoy en día mínimo, mínimo tengo que agregar comentarios en el script de por qué hice algo y que se ejecuta primero, es la mínima documentación que puedo tener. Entonces, el error que se comete con infrastructure as code y con configuration management es llegar a decir no necesito la información, la documentación perdón, no es esa parte de decir que no la quiero hacer, es pensar que no la necesito.
y lo he visto bastantes veces pasar. Ahora, continuando con los errores comunes que visto, y esto es bien contraintuitivo, pero hay que ver de que las personas que trabajamos en infraestructura y configuraciones venimos de un trasfondo de administración de servidores y no siempre tenemos esa mentalidad.
Juan (1:16:24)
Sí, sí.
Douglas (1:16:47)
y por eso se comete este error que es no poner el código en version control. Ahí estás perdiendo todas las bondades que te crea, ¿verdad? Porque yo me acuerdo al principio cuando trabajé con Popped y me decían, me querían pasar la carpeta de su código, ¿verdad? Y bueno, ¿por qué?
Juan (1:16:54)
Ok, ok.
Douglas (1:17:10)
Y ese era el jefe que estaba comenzando implementar las cosas y la primera opción era pasar una carpeta porque nosotros los los e-summing ni siquiera teníamos acceso a los repositorios de código, ¿verdad? Y no, y como que se comenzó a querer trabajar sin verle un problema a eso, sin verle un problema de que íbamos a trabajar en código pero no teníamos un repositorio para el código, ¿verdad? Entonces, no, no...
esos errores, ¿verdad? Otro error bien...
Juan (1:17:44)
De hecho incluso, o sea,
ahorita que lo estás mencionando ni siquiera pensé que eso ocurriría, Pero ya aquí es mi mentalidad de programador que yo quiero meter todo en un... Bueno, en este caso sería Git, pero podría ser otra cosa, ¿no? En un version control. Me parece interesante y curioso, ¿no? Cómo la mentalidad cambia de un entorno a otro.
Douglas (1:18:14)
Sí, de la misma manera que cuando hablamos de serverless, yo te decía, yo no pienso en serverless porque yo tengo experiencia con infraestructura, ¿verdad? De la misma manera, cuando venimos de un trasfondo, mira, no me pasó a mí, no me pasó a mí porque yo me eduqué bastante alrededor de ello, de hecho yo fui la persona que propuso PopIt, ¿verdad? Y entonces vi que se manejaba con repositorio.
e inclusive yo ya tenía un repositorio mío para los bass groups que yo manejaba, la cantidad enorme de bass groups, yo ya los tenía en repositorio porque educándome me di cuenta que recomendaban hacerlo, verdad, entonces no me pasó a mí, pero de nuevo, si entendés que venimos, que las personas que lo trabajamos, sobre todo los que venimos de hace muchos años.
Juan (1:18:49)
ok ok
Douglas (1:19:04)
no tenemos normalmente, no acostumbramos a trabajar con repositorios y me topé con personas que te querían pasar el código de Poppet o de Ansible en una carpeta. No, fíjate que al principio te salía instalar tal herramienta y te daban un RPM para instalarlo, ¿verdad? Que RPM es un paquete para Linux o te daban un sitfile.
Juan (1:19:15)
¿Alguna cosa que ver?
Sí.
Douglas (1:19:34)
con el código de Ansible para correrlo desde el servidor. Pero hoy en día si vos ves eso, no te dan un sitfile del código de Ansible, te redireccionan al repositorio donde está Ansible. O si vas a bajar un paquete, no va a ser un sitfile que alguien subió ahí. Es un paquete que generó CI-CD en GitHub y te bajan los packages dentro de GitHub.
Juan (1:19:39)
Ok
Sí.
Claro,
Sí, sí,
Douglas (1:20:02)
Entonces,
hoy en día hay un repositorio, pero ese era un error común en su momento y es un error bien curioso, sí, no, ahí estoy de acuerdo con vos en un error bien curioso. Otro error, Juan, y este es para aún aquellas personas que tenemos bastante tiempo trabajando en ello, y a veces me he topado con personas con esa mentalidad y de nuevo es un error.
Juan (1:20:08)
Qué curioso, qué curioso.
Douglas (1:20:26)
que nos... con el que nos topamos cuando empezamos a migrar, me acuerdo yo a Puppet, es usar infrastructure as code, or configuration management, como si fuera un script y no usando módulos. Porque en Terraform y en Configuration Management puedes crear tus módulos, modularidad, para repetir y personalizar acuerdos de tu proyecto. Yo te decía. ⁓
Juan (1:20:43)
Ok
estos módulos
entiendo como que puedes hacer un import de uno a otro podría a eso te referir con módulos
Douglas (1:21:01)
Sí, sí,
un módulo tal cual como lo verías en código. Puede ser que lo importas o puede ser que lo está dentro de tu mismo repositorio y si en Terraform, por ejemplo, si vas a crear instancias de EC2 para 30 diferentes proyectos.
vos tenés un módulo que lo crea y él le asigna por... tiene por defecto los estándares de los paquetes mínimos, la versión del sistema operativo, qué llaves se sello, qué permisos... Tiene valores por defecto. Y entonces vos llamás a ese módulo para crear las instancias de tu proyecto y le personalizás los valores que querés personalizar para tu proyecto, únicamente.
tu proyecto necesita nuevos paquetes, bueno, en Terraform no sería así, pero tu proyecto necesita más discos duros, por ejemplo, y una instancia más grande, en tu proyecto personalizas eso, entonces trabajas con módulos, pero a veces se comete el error de verlo como un script, y las primeras versiones de pop que tuvimos nosotros, que no las trabajé yo porque a mí me pusieron a hacer el research.
Juan (1:21:50)
Ok.
Douglas (1:22:12)
la investigación y viendo concluimos con Puppet y yo hice un par de sugerencias pero al momento de hacer la primera implementación Abismetro co-trabajaron un proyecto de hardware y no en eso entonces la primera versión de Puppet que nosotros tuvimos era prácticamente convertir los scripts que ya teníamos al código de Puppet y eso no es la manera de trabajarlo se trabaja por módulos
Juan (1:22:35)
ok
Douglas (1:22:41)
porque tanto InfraSotoras Code como Configuration Management tienen que ser idempotentes. Creo que es la palabra en español, Juan, idempotent en inglés. Yo creo que es idempotente en español, si no me equivoco, en algún momento lo Google. Y lo que eso significa es básicamente que podés correr el mismo código y no va a estar haciendo el mismo cambio una y otra vez. Que ese es el problema que yo te decía que teníamos cuando hacíamos scripts.
Juan (1:22:50)
Creo que sí, creo que sí es.
Sí.
Douglas (1:23:11)
que corría el script y a mitad del camino cambiaba porque el sistema operativo ahora trae una versión diferente de Python, una versión diferente de un paquete, entonces lo que estaba en el script fallaba. Había que ir a cambiar el script, corregirlo, pero no lo podía volver a correr todo porque iba a volver a querer repetir tareas que podían ser dañinas. Entonces, ir en potente significa que podés volver a ejecutar todo, pero él va a hacer los cambios solo donde amerite cambiar.
porque basado de nuevo en Desired State, en un estado deseado y no en lógica, verdad. Entonces es una... y el último error que quiero dar, Juan.
Juan (1:23:45)
Mm-hmm.
pero
bueno solo quería como mencionar que el hecho de tener los módulos lo que me salta a mí como developer es que te permite como seccionar las responsabilidades de cada uno de estos módulos y así te enfocas que bueno todo lo que tenga que ver con la red de este recurso va a ir en este módulo en específico y luego la seguridad va en otro módulo o al menos eso es lo que
Douglas (1:23:53)
Sí, sí.
Juan (1:24:20)
me hace pensar al escuchar la modularización en infrastructure as code y pues veo el problema de porque si no lo haces así pues terminas con una choricera de código que eso en cualquier lado va a ser un problema luego te va a tocar hacer un cambio y te toca buscar dónde está, qué parte está mientras que al tener un módulo específico puedes ir ahí directamente
Douglas (1:24:36)
Sí.
Sí, o sea, creo que lo he dicho como es. De nuevo, es estamos trayendo estas prácticas de código a infraestructura, porque de nuevo puedes hacer el gran chorizo o el gran tamal con todo en un solo archivo en Terraform y te va funcionar. Pero qué tedioso es eso. Y para que te hagas una idea, trabajando en AWS, un módulo que crea las instancias de EC2, un módulo que te crea el VPC.
Juan (1:25:07)
Sí, va a funcionar.
Douglas (1:25:17)
puedes tener un módulo que te crea un bucket de S3, puedes tener un módulo que te crea un RDS y los tienes por separado cada uno y en tu proyecto los vas llamando uno por uno y de hecho vas más allá y por ejemplo nosotros trabajamos con galera para base de datos, verdad? entonces yo...
Juan (1:25:40)
María de Veno.
Douglas (1:25:41)
María de B, sí, María de B Galera. Yo creé un módulo de galera, ¿verdad? Antes de eso se creaba, se agarraba el módulo de Easy2 y creabas la cantidad de instancias que querías, pero yo creé un módulo de galera que todavía es más fácil, donde le decís cuántas instancias querés en...
Juan (1:25:47)
Ok
Douglas (1:26:02)
en el clúster de galera, donde le desees el disco de cada una, etcétera. Entonces él viene y crea esa cantidad de instancias que cree, les asigna los security groups para que se comuniquen entre ellos y les asigna todo. ⁓
Juan (1:26:15)
ya específico
para ese tipo de...
Douglas (1:26:17)
ya específico
para galera, entonces todavía el main file dentro de Terraform todavía se reduce menos en ese sentido, eso es la modularidad y lo mismo que aplicaría en código esto, puedes tener un responsable que solo esté creando los módulos y alguien responsable luego del proyecto.
que llamaría a estos módulos y crea la infraestructura del proyecto. Igual un módulo, lo mismo que pasaría en código, le agregaría versiones. Porque el nuevo cambio puede variar bastante y entonces rompería todo el montón de proyectos que están llamando a esos módulos. Entonces le asignaba una versión diferente para que los nuevos llamen a esta nueva versión y los proyectos más viejitos tengan tiempo de actualizarlo.
Juan (1:26:40)
Ok
Ok
Douglas (1:27:09)
implica exactamente lo mismo que en código. Entonces, de nuevo, por eso es un error trabajarlo como si fuera un script.
Juan (1:27:11)
Wow, sí.
que
aquí es cuando pensás cómo trabajábamos antes de si.
Douglas (1:27:23)
Sí, sí,
yo lo olvido por momentos, pero lo olvido de manera intencional, son heridas de guerra que a veces uno no quiere volver, no que ahora la vida sea fácil del todo, pero cuando lo comparas sí es fácil, cuando se la comparación sí es fácil realmente. Pero bien Juan, quiero dar un error común más, cuando se trabaja con Configuration Management.
Juan (1:27:39)
Sí.
No,
Douglas (1:27:52)
infrastructure as code y es que no se crea una cultura de code review y esa es otra de las grandes bondades que existen porque como hemos estado acostumbrados a que me mandan el request de crear un AVM o de crear un clóset o de crear algo entonces lo que hago es directamente venir y crearlo verdad entonces he estado acostumbrado a ello pero ahora estoy con un código
Juan (1:28:02)
Sí, lo he visto.
Douglas (1:28:21)
modular donde un cambio para mi proyecto si cambió un módulo pudiera estar afectando e impactando otro montón de proyectos el code review se vuelve necesario es una buena práctica seguir porque querés identificar no necesariamente ver que lo que yo estoy haciendo como tal está bueno está malo pero que querés ver si eso va a tener un impacto mayor escala
Juan (1:28:45)
Sí.
Douglas (1:28:45)
tanto
con Configuration Management como con infraestructuras Code. Entonces, ese es un error común en el cual yo los animo a que si están trabajando sin Code Review, que lo hagan de esa manera. Nosotros en Fuel a veces nos ocurre que hacemos cambios sin Code Review porque tal vez asignan solo un ingeniero o un System Engineer a un proyecto.
Pero aún ahí tratamos de pasarle ese code review a alguien más, aunque no está asignado al proyecto, porque lo que ocurre es que como trabajamos en base a clientes, si yo le trabajo a un cliente, luego tengo que loguear mi tiempo para ese cliente, pero como no estaba asignado, entonces a veces si me asignan un code review de ese cliente...
Voy a trabajar 15, 30 minutos en revisarlo y tengo que logearles tiempo a ese cliente. Pero aún en medio de eso, buscamos la manera de mantener esa práctica de Code Reviews. Estoy poniendo mi ejemplo porque como es una agencia digital, se vuelve retante.
pero a pesar de ello buscamos trabajar alrededor de eso, entonces no cometer ese error. no sé Juan, de estos errores que he mencionado, si algo te sobresale, yo sé que has ido opinando a medida que hablando, pero no sé si algo te destaca o si has visto otros comportamientos que te pueden parecer un error en lo que tiene que ver con infraestructuras COD y Configuration Management, partiendo de nuevo, y aquí es quiero comenzar a cambiar tu mentalidad Juan, partiendo de nuevo que al final del día es código.
solo porque no trabaja con lógicas, funciones, ifstatement, no significa que no es código. Un archivo de configuración técnicamente es código. Entonces, viéndolo como código, no sé si algo te parecido como un error o una mala práctica.
Juan (1:30:24)
Sí, sí.
es complicado porque como generalmente está separado y no me dan acceso a ver estas partes pero si veo por ejemplo lo que mencionabas del code review de hecho me sucedió una pequeña anécdota donde estábamos varios developers estábamos hablando con el sistema engineer y nos está hablando precisamente sobre algo cd y cómo podíamos hacer cambios ⁓ nos explicó aquí tenemos el repositor
si necesitan cambiar algo o alguna variable de entorno
etcétera cualquier cosa se puede hacer aquí y hicimos la pregunta creo que la inicié yo o alguien más ok y como como es él cómo hacemos un PR no o sea me refiero a cuáles son las prácticas que se suelen seguir ustedes porque eran dos dos sres como suelen hacer los PR y él dijo yo no hago PR pero se puede lo pueden hacer
nos hemos dicho, si quieren lo pueden hacer, entonces...
Douglas (1:31:37)
o sea que él comitía un
solo al main
Juan (1:31:39)
una sola
pero va relacionado con lo que decís que al ser un equipo muy pequeño y cada quien tenía su responsabilidad ya bien marcada pues sólo él tocaba esos archivos entonces supongo que lo ve innecesario pero ya cuando nos empezó a decir que ustedes lo pueden hacer entonces ya nosotros decimos bueno sí vamos a hacer PR porque es lo correcto no hasta el momento
no he necesitado hacer nada de eso pero me llama mucho la atención cómo definitivamente cambian la perspectiva de cada uno de los departamentos al momento de trabajar como decís cada son códigos es código cada una de estas pero cambia la manera en que lo trabajamos y cómo nos acercamos a ello y es interesante porque definitivamente uno
como developer suele pasar por alto estas cosas muchas veces solo nos dan ya las instancias y aquí esta el repositorio, el código y si le das al botón publish ya va a estar listo y lo vemos casi asi pero es muy interesante saber como funcionan por detras todas estas herramientas
y bueno en algún punto probablemente vaya a ser necesario y aún si no lo es no sé yo siempre bueno vos me conoces yo soy de la mentalidad que todo en la vida sirve de hecho ahorita este episodio lo he disfrutado mucho porque me recuerda a esas cuando me acercaba al departamento de ustedes y a preguntar y esto por qué está así ⁓ es que y bueno recuerdo que vos y los demás compañeros me explicaban a es que esto funciona así yo iba con una duda y me terminaban explicando
todo entonces en ese aspecto pues a mí me encanta pero pero si realmente es algo a lo que no estoy tan expuesto por eso te seré sincero me cuesta hablar un poco sobre malas prácticas o que se tiene que hacer porque no he estado tan expuesto lo que sí veo es que se siguen las lo normal
subirlo un repositorio, no subir datos sensitivos, hacer PR y todas estas cosas, ¿verdad? Pero hasta ahí ha sido hasta el momento mi acercamiento. Tal vez más adelante pueda venir más acceso, pueda pedirme un poco más de acceso para jugar un poco con estas cosas.
Douglas (1:34:22)
Sí, yo creo que el hecho, Juan, de que te estés exponiendo a esto y lo estés entendiendo eso como tales es ganancia y es lo que buscamos, el valor que buscamos generar porque la conversación, aunque va más orientada a los sysadmin, a los de operaciones, a los DevOps, hay beneficio, hay beneficio. Mencionamos ya de que para los de sistemas, no habían notado, lo beneficioso que ha sido traer esas prácticas de los desarrolladores.
sistemas verdad vea que los desarrolladores puedan ver el beneficio de entender esto no no lo van a manejar ustedes no es su responsabilidad y no hay ningún problema con ello pero el beneficio de entenderlo y con lo de con lo de los PR siempre hay PR por favor vos me preguntaste juan si solo voy a manejar un servidor siempre ocupó configuration management infrastructure class code
y ahí la respuesta es, si quieres no lo hagas y solo vas a tener uno, yo lo usaría, pero si quieres no lo hagas y vas a tener solo un servidor, pero si me vas a decir, solo yo voy a trabajar en ese repositorio, siempre haces PRs, ahí si no es negociable porque es otro el beneficio, vos mismo te hagas code review, pero los PRs te dejan ese historial de ver de manera más fácil y sencilla que se cambió.
Juan (1:35:21)
No,
Sí.
Douglas (1:35:39)
Además en el PR vas a poner qué cambios hiciste y por qué los hiciste, si te van a dar ese historial más allá de solo ver commits. Entonces me pareció graciosa la experiencia Juan, pero al mismo tiempo me da miedo de que existan, que se creen nuevos profesionales en tecnología y crean que no pueden hacer un PR por favor. Y continuando con consejos.
Juan (1:35:56)
Sí.
Douglas (1:36:03)
cerremos con consejos, si te parece, yo quiero dar varios consejos que tengo preparados obviamente desde mi experiencia y quiero darte un espacio para que como developer vos transmitas algo, de lo que has aprendido o si se te ocurrido un consejo, verdad? Pero un consejo como orientado para juniors o personas que vienen comenzando y sería que comiencen aprendiendo lo básico de Git. Lo estamos hablando es...
Juan (1:36:06)
Excelente.
Ok, ok.
Douglas (1:36:31)
Configuration Management e Infrastructure as Code, código. Van a ser códigos, se trabaja por medio de un repositorio, ya lo dijimos como uno de los errores que se comete. Entonces, si Sobian Junior se venís comenzando antes de entrar fuerte a Infrastructure as Code y Configuration Management, aprende lo básico de no toma mucho tiempo. Se aprende en dos, tres horas lo básico de Git, realmente, para trabajar en proyectos.
Juan (1:36:56)
Sí.
Douglas (1:36:59)
de infraestructuras code incluso y configuration management grandes, lo básico se aprende en 2, 3 horas, pero el impacto que le va a tener a largo plazo es bastante, entonces aprendan lo básico. Siempre consejos para personas que vienen comenzando o para juniors, esté bien importante, bien, bien importante.
Juan (1:37:09)
Sí.
Douglas (1:37:22)
de hacerlo antes de pasar a Configuration Management Infrastructure as Code entiendan bien la parte de infraestructura y entiendan bien la parte de los servicios y es que es algo tan simple como yo no puedo automatizar lo que no entiendo cómo funciona, de qué manera automatizo algo que no entiendo cómo funciona, no hay manera de hacerlo y en esto Juan lo quiero acompañar de una anécdota, verdad, en esta empresa en la que vos y yo nos conocimos
Yo estaba como sysadmin, pero luego me moví al departamento. Tenía un nombre bien raro. En algún momento lo comenté yo. Creo que fue en el episodio cuando hablo de SRE y Cloud Engineers. El departamento era conocido como middle tier, ¿verdad? Que eran las personas que trabajaban en las configuraciones. como decían que era el tier en medio de la infraestructura y de la aplicación, entonces le decían middle tier.
Juan (1:38:17)
ok
Douglas (1:38:19)
de esas locuras que habían por ahí
pero era como el departamento de SRE o de la que hoy en día le dicen DevOps de manera errónea pero que le dicen DevOps, no? cuando yo pasé de sysadmin a...
Juan (1:38:33)
a mi doctor.
Douglas (1:38:34)
a middle tier era el nombre que sería
SRE, pues contrataron a dos personas en mi lugar en SISADMEN, verdad, por gracias a Dios y toda la experiencia que yo tenía, no todo estaba bien documentado, era la misma empresa y por supuesto yo estaba a la orden si se habían dudas o preguntas, pero como estaba a medio camino este proceso de la implementación de POPPET, una de las personas que movieron al departamento era un programador.
Quiero mencionar que es un, no voy a decir su nombre, pero es un gran amigo mío, una gran persona y un programador súper inteligente, súper inteligente, alguien bien brillante, ¿verdad? Pero se cometió el error de ponerlo a trabajar.
Juan (1:39:04)
Ok
Douglas (1:39:21)
en automatizar POPET sin que todavía entendiera bien la parte de infraestructura y la parte de los servicios. Entonces cuando él diseñó la forma, él creó un montón de módulos y no es que todo el trabajo que hizo generó problemas, pero sí hubo parte del trabajo que hizo que generó problemas y no tiene que ver con su capacidad o con su inteligencia, ninguno de ellos tuvo que ver con ello, en lo absoluto, ¿verdad? Pero el problema que se generó fue que él
no le dieron el tiempo suficiente para empaparse de la parte de los servicios y de la parte de infraestructura. Ya luego de un tiempo que como que dieron un paso atrás y le dieron el tiempo para entender estas áreas, la historia fue diferente y de hecho como él venía de un trasfondo de desarrollo, lo que se logró hacer con Puppet en específico fue bastante bastante bueno.
Pero sí se cometió ese error de comenzar a trabajar antes de que él entendiera los servicios y la infraestructura. Entonces no cometamos ese error.
para los que vienen comenzando, aprendan los conceptos de infraestructura, aprendan lo básico, aprendan lo a hacer manual primero y luego pasan a ello. Y un último consejo para juniors, porque tengo unos consejos para gente tal vez más avanzada, pero un último concepto para juniors es que no tengan miedo de empezar una vez que ya estén listos. Aunque sean proyectos pequeños, aunque sean proyectos personales, no tengan miedo de ir arrancando.
Juan (1:40:44)
mmm
Douglas (1:40:57)
Vean dónde pueden ustedes, si todavía no existe y no lo han aprobado, qué proyectos pueden agarrar para ustedes ir comenzando a crear la infraestructura con Terraform, ir administrando con Ansible, con Puppet, como sea que lo quieran hacer, pero no tengan miedo de arrancar, ¿verdad? Háganlo con cautela, háganlo con cuidado, pero no tengan miedo de arrancar.
Juan (1:41:18)
se podría arrancar
con partes pequeñas de todo el sistema que ya tienen tal vez con un o dos servicios
Douglas (1:41:24)
Sí. Sí, puede
ser con un servicio pequeño, puede ser manejando Ansible para una aplicación web que tiene solo dos servidores. O sea, buscar la manera de ir comenzando, irlo documentando y no tener miedo al respecto. Porque una vez que superamos esa barrera del miedo de decir, hey, ya lo implementé acá, eso me da la confianza y me comienza a dar experiencia para...
Juan (1:41:37)
Ok
Douglas (1:41:53)
y las ideas de cómo lo implemento en grande en los demás lugares, verdad? no tengamos ese miedo, sobre todo para los juniors. Ahora, para las personas más avanzadas, los que tienen más experiencia, que ya han trabajado en Configuration Management o Infrastructure as Code, que entonces puedan enfocarse en estandarizar, pues ya no puedo hablar hoy.
Juan (1:42:19)
jajaja
Douglas (1:42:20)
en estandarizar y en módulos, verdad, porque como hablamos al principio es un error tener todo junto aunque se haga bastante y aunque te estrabajando bien y aunque parezca poco, si no estás a ese punto yo quiero consejarte que paseas a hacer módulos, que paseas a modularizar, que paseas a crear estándares y de venir y decir, hey, vamos a tener un, porque Terraform por ejemplo vos podés tener un solo archivo.
Juan (1:42:40)
jajaja
Douglas (1:42:49)
y ahí tener todo o puedes venir y decir, hey, voy a tener un archivo con main, donde voy a llamar los módulos nada más, voy a tener un archivo de providers, donde voy a manejar los diferentes providers que tiene Terraform, voy a tener un archivo diferente de outputs porque en Terraform vos puedes decirle que cree una instancia y que como output de esa instancia te diga cuál es la...
P externa que le asignó. Entonces se trabaja de esa manera, no puedes separar archivos o lo puedes poner dentro de main y vamos a crear comentarios para hacerlo, etc. Entonces si ya tienes más experiencia y no tienen esto definido, yo les aconsejo que entonces le dediquen tiempo a estandarizar y modularizar. Y un consejo final para la gente que tiene más experiencia y lo mencionamos un poquito al inicio.
Juan (1:43:22)
Ok
Douglas (1:43:41)
Terraform, le voy a hacer Terraform en este caso específico, puede ser Pulumi, puede ser Crossplane, pero Terraform o CloudFormation, si deciden usar CloudFormation no hay ningún problema, pero normalmente Terraform es el recomendado, por lo que decía al principio, puedo crear recursos fuera de AWS, puedo crear DNS records en Cloudflare o en Akamai, puedo hacer cambios si uso Akamai o...
de caché y de purgar caché etcétera puedo crear recursos en Kubernetes en otros lugares entonces para sí entonces para los para los más avanzados si no saben cuál escoger ⁓
Juan (1:44:21)
es bien completo.
Douglas (1:44:29)
sugeriría que escojan o Terraform o Pulumi o Crossplane antes de CloudFormation. Sin embargo, pues si deciden usar CloudFormation tampoco es como que haya algún problema. Pero esos son mis consejos, No sé qué consejo o pensamiento final tenéis vos.
Juan (1:44:48)
Bueno es que para los developers yo lo que recomendaría es hacer esto ¿no? tratar de hablar con alguien ya sea tu misma empresa o alguien que conoces para entender un poco mejor cómo funciona lo ideal sería dentro de tu misma empresa preguntar ok estamos utilizando nosotros infrastructure as code si es así ¿qué tecnología? ¿cómo está? estoy seguro que siempre nos van a tratar de
de hablar sobre esto y explicar donde yo estoy me lo han explicado, me lo han dicho un poco algunas cosas ya las he olvidado la verdad porque fue cuando inicie entonces y más que no estoy expuesto pues con el tiempo se lo voy olvidando pero poco a poco uno se va como acuplando y bueno como mencionaba uno al saber cómo funcionan ciertos procesos nos puede ayudar a
a mejorar la manera de cómo cambiamos configuración, cómo testamos, etcétera. Y eso nos beneficia de dos maneras, creo yo Douglas. Una es lo que acabo de decir. En mi trabajo me va ayudar a entender cómo funciona y cómo puedo trabajar yo en conjunto con ellos. Porque al saber cómo está, yo ya puedo tener una idea más clara de que mi código se va a ejecutar en una instancia que se crea de esta manera. Pero la otra que yo veo positiva,
y puede que no salte a la vista al inicio y es que en algún punto muchas veces como desarrolladores salen clientes, sale alguien que nos pide hacer una aplicación, un servicio, etc. y desde el punto de vista de programación siempre es bien fácil o bueno la mayoría de las veces decimos bueno utilizo un servicio aquí
hago el backend, el frontend o utilizo serverless pero no le digan a Douglas
y luego nos toca configurar el servidor y bueno como decía Douglas puede que tal vez puedas evitarlo pero que pasa si tenes un cliente, dos clientes, tres clientes y tal vez tenes tu trabajo principal y tenes otros trabajos por aparte que nunca esta mal siempre y cuando tengas el tiempo para ello con este tipo de herramientas estoy seguro que nos va a beneficiar mucho al entender
las al trabajar de manera freelance o todo esto nos va a beneficiar mucho siempre los por eso es que se son muy populares estas opciones como bueno como lo que es serverless como lo que son versel y todo esto porque nos quitan este este tipo de necesidades pero al entender y conocer estas herramientas pues podemos optar por otras opciones que son más baratas por ende
podríamos tener mayor beneficio. Pensando a futuro, yo creo que es muy bueno que un developer, aunque no le veamos el beneficio inmediato, a futuro yo creo que va a ser muy bueno para nosotros. Creo que para todos, para cualquier persona siempre.
Douglas (1:48:13)
sí,
entenderlo, yo tal vez ese es el enfoque que le haría a los developers porque no es su responsabilidad, pero entenderlo va a traer beneficio, me gusta el ejemplo que diste de si tienes clientes y empezás a crecer o si luego te toca llegar a un punto en el que vas a contratar gente, luego...
Juan (1:48:35)
Sí.
Sí.
Douglas (1:48:36)
entiendas esa parte te sirve. Inclusive
yo a los developers, otro motivo por el cual les puedo recomendar que les conviene entenderlo es cuando les toque arquitectar soluciones porque entender cómo se está creando la infraestructura, cómo se están manejando las configuraciones...
que no lo crean tiene un impacto en el momento de diseñar soluciones. Y una última pregunta para vos, Juan, de esto que estamos hablando de Configuration Management e Infrastructure as Code. Vos me has mencionado a mí por aparte y también lo mencionaste en un episodio anterior que has estado trabajando en tu Home Lab, ahí en casa para correr servicios. ¿Sentís que podés explorar algo de Configuration Management o Infrastructure as Code para tu Home Lab?
Juan (1:49:12)
Sí.
si me gustaría explorarlo un poco más a ver que puedo hacer bueno no se que tanto se equipara algo que estuve investigando en su momento fue la opción de crear como unas imagenes muy personalizadas para poder instalarlas en los diferentes servicios lo que pasa es que yo utilizo Raspberry Pi entonces no me permite
dentro de un Raspberry Pi tener una virtualización muy grande pero estoy en proceso de querer tener una máquina más potente y dentro de ella poder virtualizar un poco más diferentes opciones entonces ahí sí sí me gustaría poder probar este tipo de soluciones porque al final del día lo que es el home loving creo que se va se relaciona mucho con el experimentar y
y aprender. Entonces para mí esto es como mi área donde yo puedo aprender estas tecnologías que por mi perfil en el área de trabajo, en la empresa, yo no tengo acceso. Pero en mi casa yo sí tengo acceso a todo. Entonces ahí yo puedo empezar a hacer y deshacer y ahí quiero hacerlo. De hecho, he tenido pendiente desde la vez que hicimos el episodio sobre...
Douglas (1:50:36)
Claro.
Juan (1:50:50)
Cloud environments donde tenía dev, olvide el nombre específico pero cuando podemos crear estos ambientes de desarrollo en la nube. He querido hacer algo similar en un servidor que tengo pero por cuestiones de tiempo no lo he hecho así que lo he tenido pendiente. De nuevo es porque ahí me permite explorar estas cosas y tratar de ver cómo funcionan realmente.
creo que sí haría algo con infrastructure as code.
Douglas (1:51:25)
Sí,
o puedes comenzar con Configuration Management, tal vez algo como Ansible para manejar las configuraciones. Como dijiste, en tu casa,
Juan (1:51:28)
también
Douglas (1:51:34)
tenés fulsudo y tenés 777 permisos así que así que puede hacerlo. Bueno Juan realmente que he disfrutado bastante la conversación el poder transmitir estas experiencias y estos conceptos espero que hayan sido de beneficio para aquellas personas que comienzan o para quienes han tenido un poco más de experiencia y tal vez escuchar estas anécdotas les va a permitir no cometer errores que me tocó experimentar por mi cuenta y también me gustó mucho la perspectiva que nos brindaste Juan tu
Juan (1:51:36)
Sí. Sí.
Douglas (1:52:04)
de vista como developer y pues esos consejos finales que vos dices. Creo que con esto es buen punto para que concluyamos la plática no sin antes agradecer a todas las personas que nos ven y nos escuchan que llegaron hasta este punto. Esperamos que les haya sido de valor. Nos despedimos. Hasta la próxima.
Juan (1:52:25)
Nos vemos, bye.