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 empezar a investigar hablando con los programadores. Y la respuesta típica es, a mí me funciona en mi local. Y eso era algo que me molestaba tanto.
Juan (00:14)
Somos buenos, abandonos la mano los desarrolladores. Somos expertos.
Douglas (00:17)
Exacto. Exacto.
Y a veces, por nuestra parte, somos muy buenos culpando al desarrollador. Y ningún extremo es realmente bueno.
Juan (00:25)
mmm
Bienvenidos sean todos a este nuevo episodio de Dev & Ops este es nuestro segundo episodio y este va a ser un episodio muy interesante ya que vamos a hablar un poco sobre el nombre del podcast un poco aclaran unas cuestiones de lo que es Dev Ops en el episodio anterior habíamos hablado que nuestro podcast es un juego de palabras entre Dev & Ops porque de mi lado yo estoy
más afianzado y un poco más relacionado con la parte de desarrollo developer y Douglas aquí es el experto en la parte de Operation Teams y todo eso. ¿Cómo estás Douglas?
Douglas (01:14)
Muy bien Juan, muchas gracias. Realmente emocionado por, en primer lugar, continuar con esta faena, continuar con esta... con esta reto que nos hemos puesto, ¿verdad? Ya en el episodio 2 y realmente entrando en materia de un solo y de golpe, ¿verdad? En lo que tiene que ver con la cultura, con este conocimiento, ya la experiencia en particular, lo que es DevOps. Entonces, totalmente...
emocionado por darle viaje.
Juan (01:47)
Excelente, excelente, me gusta eso. Y bien, me gustaría que empecemos, empecemos un poco con este episodio porque en este episodio vamos a hablar sobre DevOps, ya que creo que es uno de esos puestos, una de esas palabras que hemos escuchado mucho, pero estoy seguro que habemos muchos que no estamos tan al tanto de qué es lo que realmente es. Me gustaría empezar yo a hablarte desde mi perspectiva que es DevOps.
cómo lo he visto yo y luego podrías continuar vos y corregirme en todo lo que estoy mal y que probablemente sea todo lo que esté equivocado. Entonces vamos a empezar. Para mí DevOps. Bueno, de hecho voy a dar un poco de contexto. Para mí DevOps antes era más como como un puesto de trabajo y es una persona que se encarga de manejar lo que son
las aplicaciones que uno está desarrollando. Entonces, para mí, yo desarrollo mi aplicación y la envío al servidor y el DevOps se encarga de hacer que funcione de alguna forma. Pero actualmente voy a mencionar que hoy por hoy para mí DevOps es más que una persona, es una metodología, una forma de trabajar donde en teoría uno como desarrollador
debería entender todo el proceso, todo el proceso desde el desarrollo, testeo y despliegue de la aplicación, ya sea un REST API, una aplicación móvil y deberíamos estar un poco más involucrados en todo esto. Entonces DevOps como que para mí abarca todos estos procesos que es desarrollo, testeo, el despliegue de la aplicación y si hay algún error pues...
de bogearlo y volver a empezar. Entonces no sé si me podrías ahí corregir en algunas cosas que tal vez estoy mal.
Douglas (03:54)
Fijate Juan, que no hay como tal mucho que corregir. Esa ha tu experiencia personal alrededor de DevOps, desde tu introducción a este mundo, desde cómo primero te enfrentaste al concepto, a la palabra, las primeras impresiones que tuviste. Y me gustó algo que dijiste al principio respecto a DevOps y que es como una palabra conocida. O sea, le hice como un buzzword, una pala...
famosa y típica y a cualquier conversación con respecto a tecnología, respecto a desarrollo, a cualquier conversación, si le agregas la palabra DevOps, esa persona inmediatamente suena como que ya es más interesante, como que se la sabe todas. Esos son los buzzwords. Muchas veces no sabemos lo que significa, ¿verdad?
Pero me gusta eso. Mira, definitivamente siempre hay una verdad absoluta, pero también está tu verdad y mi verdad. Para mí DevOps y si me remonto a antes de DevOps, ¿verdad? Y tal vez esto para generar contexto y que se pueda entender de dónde nace, ¿verdad? Y de nuevo, esto es una experiencia personal.
Juan (05:08)
jajaja
Douglas (05:12)
la historia de DevOps y padres y todo eso está en internet. Nos metemos hoy en día al pregunta hachatgpt y te dice.
Pero para mí antes era yo la persona en infraestructura que se encargaba de instalar un servidor, se instalaba de configurar, de establecer la seguridad en el sistema operativo, de configurar el servidor web y el servidor de aplicaciones para que tenga un buen rendimiento, buen performance y venir y publicar las aplicaciones que hacían los programadores, ¿verdad? Pero una vez que el programador terminaba y decía, estoy listo para publicar,
Juan (05:46)
mmm
Douglas (05:51)
Todo eso se volvía mi problema, que la aplicación estuviera bien, ¿verdad? Se volvía mi problema y tratar de solucionar problemas porque el rendimiento es bajo, porque es talento, porque se cae cada media hora. Y empezar a investigar hablando con los programadores. Y la respuesta típica es, a mí me funciona en mi local. Y eso era algo que me molestaba tanto.
Juan (06:22)
Somos buenos, abandonos la mano los desarrolladores. Somos expertos.
Douglas (06:25)
Exacto. Exacto.
Y a veces, por nuestra parte, somos muy buenos culpando al desarrollador. Y ningún extremo es realmente bueno.
Juan (06:32)
mmm
Douglas (06:35)
Ningún extremo es realmente bueno. Pero en un momento donde hasta los gerentes y los ejecutivos empiezan a apuntar a la gente de infraestructura, a la gente de sistemas, ¿por qué la aplicación está caída? ¿Por qué el sitio web está dando este error?
porque la aplicación está lenta y no tener idea de qué está pasando con la aplicación como tal, ¿verdad? A mí el web server solo me tira un código 500 que falló el application server.
el application server solo metida que no inicia, verdad, y no hay login específico para la aplicación, no hay error handling, no hay absolutamente nada y todo se volvió mi problema y tenía que empezar, aunque yo no programo, a ir viendo que fue lo último que se publicó, que fue lo último que cambió y buscar demostrar al programador, mirá ve, esto probablemente es lo que hizo que fallara. Entonces...
cuando yo ya hacía eso, entonces ya venía y reportaba, no miren, es un error de código, ya se lo tiré al developer y ahora soy yo el que empieza a lavarse las manos. Ahora soy yo el...
Juan (07:51)
Sí,
se vuelve una papa caliente, cada quien se trata de salvar. Y creo que eso a veces es por... A veces considero que no es culpa de uno como tal, aunque sí, pero también viene a raíz de cierta cultura empresarial. A veces llegamos a un lugar y de cierta manera la misma empresa te empieza a moldar de esa forma y esas cosas pasan.
Douglas (08:17)
Sí, y pasa porque agarramos las mañas malas, como dicen. Pasa porque vemos a otros hacerlo y no necesariamente nos tomamos el tiempo para identificar si es lo correcto o no. Cuando aparecía un programador que tenía interés en que las cosas funcionaran bien, entonces luego nosotros los de sistemas o los de operaciones, los de infraestructura, no queríamos darle acceso porque entonces es mi mundo, es mi área.
Entonces yo no sé qué relajo me voy a hacer en los servidores. Y comenzábamos con eso, ¿verdad? Y tal vez era alguien que pudo haber apoyado más, ¿verdad? Y si yo iba a sugerirle luego al programador, mira, ve, trata de usar sesiones, trata de implementar algo como CouchDB, ¿verdad? O como Redis, o trata de usar sesiones en Cookie para que evitemos sticky sessions en un load balancer.
para que no vayan todas las sesiones al mismo servidor, si se balancea es mejor, entonces cuando intentaba darle ese tipo de consejos o tips al programador, era él el que se ponía por esa parte como que resentido, verdad, o cuidadoso, no te metas, yo sé lo que programa. Entonces eso Juan, es mi experiencia previo a DevOps. DevOps nace de esa necesidad.
alguien en la empresa, porque nace diferente en cada empresa y en cada persona, por eso no estamos enfocándonos en el origen como tal. Pero cuando alguien en la empresa viene y dice, yo puedo poner a trabajar a estas personas juntas y que compartan responsabilidad y que compartan el trabajo para que en lugar de pelear entre ellos y en lugar de echarse la culpa entre ellos,
ambos sean responsables de igual manera para todos. Y ahí comienza DevOps, en realidad la forma más práctica de hacerlo es una cultura donde el programador tiene una mente y una conciencia de configurar el proceso de cuál va a ser el rendimiento y el performance de su aplicación, de configurar los diferentes pruebas y test que van a correr, de configurar el CI-CD pipeline.
cómo se va a buildear la aplicación, cómo se va a testear de manera automática, cómo se va a publicar de manera automática. El developer tiene la responsabilidad de asegurarse de manejar los logs y los errores correctos para que se puedan publicar. Incluso el developer tiene la capacidad de definir, quiero que se levanten tantas instancias del front-end.
y menos instancia del backend, ya sean contenedores o ya sean máquinas virtuales, el developer se encarga de tener ese performance, pero colabora con el de operaciones, con el de infraestructura, para encontrar un número correcto. Por su parte, el de infraestructura se encarga de brindarle al developer todas las herramientas necesarias para que él pueda cumplir con su trabajo.
se encarga de darle el acceso correcto y tener listo el CI-CD pipeline y tener los runners donde van a correr esos procesos para bildear. Se encarga de tenerlos listos, se encarga de tener listos los cluster de manera que los archivos de configuración que él mande con cuántas instancias quiere levantar se transformen en infraestructura a las instancias que él quería, ¿verdad? Él facilita acceso inmediato a logs, acceso a correr comandos en ambientes de desarrollo, en ambientes
Juan (11:47)
mmm
Douglas (11:56)
de prueba, en ambientes de pre-producción, y empieza esa colaboración donde uno empodera al otro, el de operaciones empodera al developer para que él pueda realizar ese tipo de operaciones.
y el developer empodera al de operaciones para que entienda la aplicación, inclusive entender el modelo de negocios, ¿verdad? Eso es tan importante, inclusive entender el modelo de negocios. No mirar es que esto es sobre turismo. Entonces el cliente necesita... Las personas que más entran a su hotel son personas mayores de edad. Eso te da una perspectiva diferente, ya sabes que son personas que tal vez tienen menos experiencia.
con ciertas cosas y no le dan clic una vez al botón, dan clic seis veces, verdad? Y entonces eso, Juan, en mi experiencia, manera personal, así se vivió para mí DevOps.
Juan (12:54)
que interesante porque me llamó la atención cuando mencionabas que esa era tu experiencia antes de DevOps pero creo que estoy seguro que en algunos lugares eso es DevOps para algunas empresas lo que vos hacías y es que, o sea, creo que va a depender, como vos mencionabas, de la empresa y cómo ellos van evolucionando y a medida van creciendo en número de personas
también se empiezan porque también creo que es cabe recalcar que a veces esto surge de algunas de alguna parte buena que se va medio desviando por ejemplo el hecho de no tener tanto acceso a ciertas cosas puede ser porque en el pasado algunos desarrolladores hicieron muchos problemas entonces empezó a limitar eso lo mismo pasa con las bases de datos a veces no se les da acceso
y no es hasta que ya empezamos a ver que el desarrollador puede tener estas responsabilidades siempre y cuando se manejen de manera correcta o sea supongo que se le puede dar diferentes accesos, diferentes niveles de permiso para que pueda hacer lo que necesita hacer sin estropear lo otro pero sí es muy interesante cómo todo se va dando y
y como lo que es DevOps es muy difícil porque al final del día es cambiar lo que mencionabas es tu... una cultura y eso es un poco difícil de hacer
No sé, ¿qué recomendaciones consideras que podría tener alguien que dice, en mi empresa podríamos hacer esto o en mi grupo de trabajo podríamos hacer eso? Pero cómo podríamos iniciar? Si ya tenemos algo establecido y es muy rígido, ¿cómo lo podemos empezar a cambiar?
Douglas (14:51)
Fíjate que me parece muy interesante y definitivamente tengo un par de consejos basados en éxitos y en fracasos, ¿verdad? En prueba y error. Lo primero es realmente DevOps no es un puesto de trabajo, no es un puesto. Y aquí no quiero extremizar.
Y poner a pelear y si estás buscando trabajo y encontrás una plaza que dice Ingeniero DevOps o DevOps Engineer y decir no, ahí no aplico porque DevOps es una cultura, no es un puesto, no hagamos eso. Ya como mencionamos al principio es un buzzword, si en ninguna empresa quieres un Ingeniero DevOps, aplica para Ingeniero DevOps. Y cuando te pregunten ¿qué sos? Soy un Ingeniero DevOps porque ese es el puesto que te dieron en tu empresa, ¿verdad?
Juan (15:33)
mmm
No estás mintiendo.
Douglas (15:44)
No estaría mintiendo, correcto.
Siempre y cuando vos sepas la diferencia, siempre y cuando vos entendas que porque tenés ese título DevOps, realmente que DevOps se desarrolle, se lleve a la práctica, sea un éxito, no es 100 % tu responsabilidad, ¿verdad? Entonces eso es lo primero, no es un puesto.
Lo segundo, y esto tiene que ver un poco con lo que mencionaba de que tal vez hay un programador que se le dio acceso y creó un problema en producción, ¿verdad? O había un, o a un, alguien de operaciones se le dio acceso a monitorear cosas de la aplicación y interpretó mal el error y implementaron una solución que no era. Cuando ese tipo de cosas ocurren, realmente no debemos...
ver como culpable al ingeniero que se equivocó. Cuando ese tipo de cosas ocurren, en realidad viene de la cultura o viene de la gerencia. Porque si yo no tengo la capacidad de que me pongas a monitorear... Yo soy el de operaciones, si no tengo la capacidad y el conocimiento suficiente para intentar monitorear las métricas de tu operación, no me pongas a hacerlo.
me pongas a hacerlo porque voy a hacer algo equivocado. Tenés que entrenarme primero, asegurarte de que entiendo y luego me pones a hacer el trabajo. Lo mismo por parte del equipo de Ops. Si un developer no entiende bien qué es un cluster y qué es contracorrer en un solo servidor...
Juan (17:02)
Mm-hmm.
Douglas (17:26)
no se le puede dar ese tipo de acceso, pero viene de la cultura, ¿verdad? Viene del jefe en un equipo de fútbol, cuando hay errores grandes y escuchamos a los periodistas que piden que rodea la cabeza del técnico, nadie dice el defensa que se dejó Charlo Golez o el delantero que falló tres frente al Marco, los periodistas y los críticos dicen despidan al entrenador, no que quiero culpar a los gerentes, solamente quiero decir nosotros como individuos parte del flujo y
Juan (17:38)
mmm
Douglas (17:55)
y el ciclo de vida de una aplicación, evitemos culpar al compañero cuando se den estas cosas, por el contrario, busquemos colaborar, busquemos preparar al otro y empoderarlo porque eso me va dar a mí libertad.
obviamente necesitamos que la otra persona tenga el carácter, el deseo, la intención y voluntad de hacerlo. Si te quiero empoderar a hacerlo para darte acceso a los servidores y que puedas vos mismo monitorear y recibir la información que necesitas, pero no tenés ganas...
Juan (18:20)
Sí.
Douglas (18:33)
y solamente si buscas hacerte loco como decimos no va a funcionar, verdad. Pero es importante que cuando se den esos errores no culpemos, Sin embargo estemos ahí para apoyar, verdad. Y lo siguiente va de la mano, ¿si?
Juan (18:52)
que eso
también va ligado no solo en la cultura empresarial, considero que también va ligado a nuestra cultura, o sea, de nuestro pueblo, por decirlo así. Creo que se da mucho en Latinoamérica, donde buscamos un culpable y no buscamos apoyar, como decías. Ok, sí, se equivocó, pero pues ahora hay que arreglarlo entre todos.
Entonces a veces va ahí un poco de la mano. Que hay que cambiarlo.
Douglas (19:17)
Sí.
No, muy real.
Hay que cambiarlo. Por eso estamos tratando de hablar estas cosas porque buscamos un culpable, aun cuando se que yo soy el culpable. Busco, si puedo echarle la culpa a otro, lo voy a buscar. Y realmente no es la mentalidad adecuada. Y esto me lleva al siguiente consejo que es, no ser egoísta y compartir. Compartir el conocimiento.
Esto viene hasta con otras personas en mi mismo puesto, un programador senior con un programador junior. Usualmente se es egoísta, se piensa que no le voy a enseñar y comienzo a recordar a mí me tomó tantos años llegar a este nivel, a mí nadie me ayudó. A mí cuando yo empecé no había internet, tenía que buscar en libros y una vez fui donde un maestro y me cerró la puerta en la cara y empezamos a recordar esas cosas y creemos que porque esa fue mi experiencia.
tiene que ser la experiencia de todos o porque aún dentro de la empresa yo empecé desde abajo y cuando yo entraba aquí me miraban mal verdad y este no va a venir solo a hacer las cosas es la experiencia equivocada tanto con gente de nuestra misma área como con gente de las otras áreas verdad compartir el conocimiento documentar todo muy bien todo bien documentado querés evitar que el que preguntando cada
ahora el junior o querés evitar que se esté preguntando todos los días el de operaciones cómo hacer algo documentarlo documentarlo bien claro que sea fácil de seguir y mandarlo a la documentación mirabe para la próxima aquí está ve aquí encontrás esto aquí encontrar los otros lo otro y le haces un demo verdad entonces no ser egoísta hay una tecnología que no le entiende bien algo que yo hice bastante pero bastante al principio fue
Fui un evangelista de Docker cuando empezamos con esto de implementar cultura DevOps, ¿verdad? Y cuando tuve la experiencia de comenzar a transicionar sistemas y aplicaciones de monolítico a microservicios o servicios y implementar la cultura DevOps, fui un evangelista de Docker, ¿verdad? Con gente de operaciones y sistemas que estaban acostumbrados a trabajar con.
solamente en servidores físicos y con programadores. Entender cómo dockerizar tu aplicación, cómo usas batch scripting para hacer un entry point efectivo, cómo orquestrarlo, cómo con Docker Compose puedes levantar tu local más fácil. Y yo daba workshops y abría las puertas para que el que quisiera llegar a donde mí preguntara porque necesitamos que la otra persona
tenga ese nivel mínimo requerido para que DevOps pueda ser una realidad. Si yo me cierro y no busco enseñar lo que le falta al otro, entonces en mi empresa, en mi puesto de trabajo no va llegar a ser una realidad la cultura DevOps, por ende yo estoy perdiendo meses o años de poner en mi currículum experiencia.
DevOps y no nos damos cuenta pero realmente me estoy afectando a mí mismo. ese tipo de cosas, Juan, son las que nos llevan a que implementar esa cultura sea algo digerible y una vez que está implementada comencemos a ver los beneficios por montón.
Juan (22:59)
Sí, qué curioso, Este, cómo a veces el egoísmo hace que tropecemos nosotros mismos, tanto para nosotros como nivel personal como para la empresa o nuestra, porque a veces incluso es nuestra, puede ser una empresa, un emprendimiento, un, perdón, un startup. Entonces sí, creo que a veces eso...
es muy importante. Hay muchas personas que tienen la mentalidad o no sé, cultura, no sé cómo llamarlo, de decir hey, sí, está bien que compartas, pero no compartas todo porque a vos también te costó. Y a mí en lo personal me cuesta mucho coincidir con eso. Sí entiendo el por qué lo dicen, pero también creo que hay mucho beneficio en que todos crezcamos al mismo tiempo. O sea, el hecho de que
mi compañero crezca no significa que yo me voy a quedar abajo, al contrario en el mejor de los casos los dos vamos a seguir creciendo porque él también me va a compartir cosas y así, es una una rueda, es una rueda. Sí, yo recuerdo mucho cuando estuvimos en este proyecto de microservicios, vos eras de los que más hablaba sobre Docker y cómo
cómo empezar a implementarlo. Yo en ese entonces sí utilizaba Docker, pero muy poco y era más para mis cosas. sea, recuerdo que la primera vez que yo utilicé Docker fue para poder levantar el servidor de una base de datos de SQL Server. Sí, SQL Server. Y porque me di cuenta que no había una versión para Mac y
y yo llegué a Mac y era porque no tampoco tenía experiencia en Mac entonces cómo instaló esto no me daba cuenta y buscando en internet alguien mencionó pues con Docker y para mí eso fue me voló la cabeza poder utilizar algo que no estaba para Mac pero lo estaba utilizando y sí realmente Docker ha venido a mejorar mucho nuestras vidas en general estaba pensando por ejemplo
recordando muchas de esas cosas y basado en lo que estabas hablando creo que ese podría ser un buen punto de partida para cambiar tal vez una estructura que ya está muy rígida y empezar a dar un poco sobre DevOps sería simplemente el hecho de compartir conocimiento tratar de estandarizar muchos procesos también basándome en lo que decías, de evitar
preguntas recurrentes que no es que a uno le incomode responder sino que a veces se puede pues acortar tiempo, si ya está la respuesta solo está al alcance de todos no sé, ¿qué otras cosas consideras que sean importantes? bueno empiezo yo te podría decir, creo que algo que ayuda mucho a cambiar este chip es el hecho de que los desarrolladores entiendan que
que si algo falla en la aplicación, si yo estoy desarrollando una aplicación y falla, es mi responsabilidad. No es porque ahora está en el servidor de Douglas, ahora es responsabilidad de Douglas. Douglas me proveyó el entorno, pero la aplicación digamos que es mía. Entonces es importante que yo agregue todos los logs necesarios, documentación por todos lados, configuraciones, archivos de configuración, porque es mi responsabilidad.
no sé qué opinas de eso, aspecto de compartir la responsabilidad en estos sistemas.
Douglas (26:55)
Es clave, es un punto clave el adueñarme, como se dice en inglés, el ownership de la aplicación. Pues esperas que la contraparte haga lo mismo. Si yo soy de operaciones, espero que el developer haga lo mismo y un desarrollador espera que el de operaciones haga lo mismo. Pero el adueñarme de la aplicación y verlo como mi responsabilidad, mi reto,
es importante. Eso nos va a llevar, Juana, no solo a colaborar mejor, pero nos va a a crecer como profesionales. Ayer mencionaba yo que un profesional en esta industria de tecnología, de desarrollo de aplicaciones...
tiene que entender muy bien la capa que está arriba de él y la capa que está abajo de él, entenderla decentemente, no tiene que hacer un experto, ¿verdad? En el caso mío como alguien de operaciones necesito entender la capa de abajo que sería tal vez si lo vamos desde la nube tal vez la parte de, dependiendo en qué puesto estás, la parte del hardware, ¿verdad?
si estás en un área de nube o si estás en un área donde solo manejan los servidores, entonces la capa de abajo sería el networking, la red.
Juan (28:17)
Si
Douglas (28:18)
Y en mi caso la capa de arriba son las aplicaciones. Y alguien de operaciones tiene bastantes aplicaciones, bastantes tipos de aplicaciones. Tiene aplicaciones web, tiene aplicaciones móviles, tiene servidores de correo electrónico, tiene diferentes servicios, ¿verdad? Tiene bases de datos, diferentes tipos de bases de datos, bases de datos SQL, bases de datos no SQL, ¿verdad?
entender esa capa de arriba muy bien y la capa de abajo como ahora me estoy adueñando de esto me lleva a buscar a estudiar a entender para poder colaborar con la otra persona en el caso de un developer si es un developer backend tiene que entender muy bien la capa de abajo puede ser para la base de datos puede ser para ver el servidor entender linux o windows y corren windows verdad por entender el servidor entender que es un cluster
entender qué son los diferentes servicios que hay debajo y la capa de arriba entenderla para un backend sería tal vez el frontend verdad pero también puede ser un poco más arriba el CDN, DNS entonces como yo estoy dueño de eso y tengo que tratar de encontrar una solución
y tengo que intentar colaborar de manera efectiva con mi contraparte, ya sea la contraparte de un desarrollador o la contraparte de alguien de operaciones, me lleva a estudiar eso, me lleva a mejorar, me lleva a entender para que cuando él me explique, haremos el mismo idioma, ¿verdad?
o cuando yo le explique, podamos estar hablando del mismo idioma y ahí yo crecí y me volví de alguien simple en mi puesto a alguien más proeficiente y más activo. me mencionaste en el último episodio que vos comenzaste con HTML y CSS y te sentías bien empezando a darle estilos a las páginas y luego descubriste JavaScript.
si vos te hubieras quedado con HTML y CSS, hoy no estuvieras haciendo microservicios en GoLang. Entonces eso es muy importante, y eso sería tal vez la siguiente parte para lograr implementar esta cultura DevOps y es entender bien...
que está arriba y que está abajo de mí para poder colaborar, tengamos esa meta en mente, para poder colaborar y de esa manera, como vos dijiste, adueñarme de la aplicación, del servicio, del sistema que sea que estoy publicando, adueñarme de él, volverme responsable y hacerlo de manera efectiva.
Juan (30:59)
Sí, y creo que a veces estoy seguro que si alguien que nos está escuchando y trabaja de esta forma, de esta forma que tiene muchas barreras, pues uno como que se acomoda, pero créame que cuando empezás a tener esta mentalidad y empezás como...
me dice Douglas a doñarte de tu aplicación es algo que no sé es como revelador de cierta manera porque yo recuerdo que cuando empecé a trabajar de esa forma donde ahora yo podía ir al servidor y buscar los logs que me interesaban yo podía ejecutar los queries de los bases de datos que yo necesitaba sin tener que ir por pasar por un dba sin tener que pasar por un o una persona que me dé ok aquí están los logs
eso incrementa la productividad de una manera increíble y se vuelve algo que no solamente incrementa tu productividad sino que también incrementa también tu tu entendimiento de la aplicación como tal en un todo
El hecho de poder configurar un compose file y poder configurar que tengo varios servicios y estos se van a conectar mediante esta red dentro de Docker o dentro de Kubernetes o dentro de cualquier cosa. Es muy gratificante lograr ese tipo de cosas.
Y luego la comunicación entre todos se vuelve mucho más fluida porque todos entienden todo. En teoría tanto las personas que están encargadas de los entornos de desarrollo, del entorno de producción van a poder entender si algo sale mal. Porque al final del día no solo se trata de que la aplicación va a estar corriendo y ya todos ahí terminó todo.
algo va a salir mal. Entonces es necesario prepararnos y poder y saber qué, qué tocar, qué leer, qué revisar si algo sale mal. Entonces yo eso lo recomiendo encarecidamente que traten de adueñarse más de sus aplicaciones, de sus sistemas que están desarrollando, porque al final del día eso no trae más que beneficios tanto para uno a nivel personal como para todo el equipo. Y
Y bueno hablando del equipo creo que incluso uno podría incluir aquí a los project managers y a las personas de mayor nivel en la jerarquía porque sí es importante que también entiendan como... dependiendo del puesto obviamente van a haber ciertos filtros no vamos a hablar de una manera tan técnica pero sí es necesario que entiendan lo básico y qué está sucediendo.
que sepan que hay una base datos mínimo. Sí, es importante poder compartir todo esto con el equipo entero. En ese caso, Douglas, ¿cómo se divide? En este caso, creo que la responsabilidad recae. Podríamos dividirlo así, El entorno es, digamos, del equipo de Operations.
y todo el funcionamiento de la aplicación recae sobre el desarrollador o consideras que al final del día es parte de todos, todos tienen la misma responsabilidad.
Douglas (34:34)
interesante y tal vez se puede volver si no se implementa de forma correcta o si no se piensa de forma correcta se puede volver una paradoja porque hemos estado hablando de ambas contrapartes, abreñarnos y colaborar ambas contrapartes, sentirnos responsables de hacer que la capa de arriba y la capa de abajo funcione, verdad, pero ahora vamos a hablar de...
¿Quién es responsable de qué? Entonces se vuelve paradoja. Entonces, ¿qué estás diciendo? ¿Qué estás hablando? ¿Vamos a colaborar o no vamos a colaborar? Y es un balance, es un balance. ¿Quién es responsable de que el código tenga un rendimiento óptimo y acepte la mayor cantidad de peticiones y el mayor tráfico con recursos mínimos? El que sabe programar.
Juan (35:03)
Sí.
Douglas (35:31)
Yo no lo puedo hacer por el programador. ¿Quién es responsable de que la infraestructura, los servicios y sistemas tengan alta disponibilidad, sepan autosanarse, autohilling? Cuando hay un error, alerten a las personas correctas y se generen los procesos y automatizaciones necesarias al momento de diferentes inconvenientes, el que sabe hacer infraestructura.
el programador no lo puede hacer. Entonces, el experto en su área es el responsable de que se haga. Pero, ¿cómo a pesar de que existen estas responsabilidades marcadas puede existir siempre colaboración? ¿Y cómo a pesar de que vos como desarrollador sos el 100 % responsable del código que se escribe en la aplicación?
porque yo no tengo tu nivel para programar, ¿cómo a pesar de eso yo me vuelvo... yo lo siento que también es mío? Es con algo que te mencionaba al inicio y es con sugerencias, es con decirte, hey Juan, fíjate que la aplicación se siente lenta. ¿Qué te parece si yo levanto un servidor de Redis? ¿Y vos cachás ahí las sesiones?
Y vos puedes decirme, no Douglas, que cachar es complicado. Fíjate que estaba viendo este plugin que lo hace, o estaba viendo este servicio. ¿Qué te parece? Entonces, tanto yo meterme a la aplicación, buscar hacerlo, como vos ser receptivo y decir, aunque la forma en cómo aplicarlo por completo no sirva a la que yo te dije.
pero te cae el daime como dicen, sí, hay que implementar algo, una capa intermedia que cachee los requests. Buena idea, Douglas, fíjate que mi Rave no va a ser Redis, va a ser Memcache, va a ser Couchbase. Entonces, por mientras y te preparando un cluster, yo voy a ir haciendo acá. Entonces, aunque vos sos el 100 % responsable, no yo, aunque yo no voy a escribir ese código.
esa colaboración nos permitió hacerlo. Lo mismo por tu cuenta, ¿verdad? Tal vez vos sos el que identificaste que está lento y tal vez vos sos el que identificaste que podemos poner un clúster de Redis en medio y me puedes decir tú, la fea te que estoy viendo que podemos cachar con Redis.
vos podés levantar un cluster. Mirad, yo estoy viendo que la infraestructura, pero tenés que asegurarte de que tenga alta disponibilidad, que tenga, el endpoint tenga esta seguridad. Ahí, buena idea, fíjate, dale. Entonces, aunque está marcada la responsabilidad, eso es lo que nos lleva a colaborar. Pero para yo poder sugerirte algo.
y lo estoy repitiendo bastantes veces porque es tan importante. Tengo que entender más allá de solo lo que hago y tengo que sentirme responsable y dueño y crearlo y cuidar la aplicación como que si fuese mía. Entonces, las responsabilidades están marcadas, pero estando tan marcado, la colaboración tiene que ser abierta y no hay excusa alguna.
Juan (38:42)
O sea, en resumen podríamos decir entonces que cada quien juega en su lado, pero al final del día, así como hay un defensa y hay un delantero, ambos juegan para el mismo equipo. Todos tienen que aportar.
Douglas (38:55)
Exacto.
Juan (38:57)
Excelente. Me gusta mucho este tema de DevOps, creo que es algo que no se aplica tanto como uno quisiera. Me gustaría que habláramos un poco también algunos consejos. Quiero ponerte aquí un poco difícil. No sé, tal vez alguna experiencia que hayas tenido.
Douglas (39:21)
A ver.
Juan (39:23)
o algo que digas ok iniciando como DevOps yo me tope con esto y creo que esto es algo importante entonces bueno para no tal vez no ponerte la tan difícil voy a iniciar yo con un consejo que considero yo desde el lado de como desarrollador entonces yo creo que para iniciar en todo esto algo que es muy importante es siempre tener en mente el
el tema de monitoreo porque una aplicación no se puede mejorar, no se puede optimizar si no sabemos cómo monitorearla. es importante. Ya sea cuando es back end, considero que es mucho más fácil porque uno empieza a poner muchos logs y estos logs uno los puede recolectar con diferentes servicios que existen y eso me permite a mí poder tener una idea de qué está pasando porque
Si bien la aplicación se comporta de una forma en mi computadora, ya cuando está en un servidor de producción que tiene una carga diferente, está con procesos en el background diferentes, pues a veces se va a comportar de otra forma. Entonces, digamos que para iniciar, yo considero que es tener eso en mente, el monitoreo de una aplicación, ya sea con logs, ya sea con alertas, ya sea con...
con metadata dentro de campos que se guardan en la base de datos, no sé, hay muchas opciones, hay muchos métodos que se pueden hacer, pero es importante tener una idea de cómo se está desarrollando, comportando la aplicación en el servidor. Entonces, de mi lado, para los programadores, yo diría que ese puede ser un punto para tomar en cuenta cuando estamos tratando de, no sé cómo llamarlo, transicionar a...
a una cultura DevOps para tratar de adueñarnos de la aplicación. De tu lado de infraestructura no sé si consideras hay algo que tal vez no se hace tanto y consideras que puede ser algo bueno, un tip.
Douglas (41:32)
Fíjate que se me vienen varias cosas a la mente y voy a comenzar con un consejo que es más de cultura que técnico. Y de nuevo, suena paradójico, pero hay que usar un poco de sentido común y mantener un balance. El primer consejo es descartar al que no quiere. Te vas a topar con personas que simplemente no...
Juan (41:55)
Wow.
Douglas (41:59)
tienen las ganas porque están acostumbrados, porque llevan años haciendo las cosas de la misma manera y les funciona.
les decís que va esto va a ser más rápido, va a facilitar esto y no quieren, no quieren, verdad. Me topé con tanta gente que simplemente por razones ya sea de egoísmo, ya sea por falta de visión, llamalo como querrás, hubieron diferentes ejemplos de personas que no querían, verdad.
y estuve ahí al inicio, estuve intentando convencer, estuve tratando de ser útil para ellos, estuve tratando de colaborar y luego de un tiempo descubrí que ese tiempo lo estaba invirtiendo mal, ¿verdad? Seamos, no seamos egoístas, compartamos el conocimiento todo, no nos quedemos con nada, que la empresa, no es que porque soy el único que hago algo, no me van a despedir.
me van a despedir, ¿verdad? Pero el que no tiene las ganas, no invertamos tiempo, eso nos va atrasar en llegar al nivel que queremos llegar. Entonces, ese sería mi primer consejo cultural, ¿verdad? Sí, sí, pero hay que ser tajante. Le damos el tiempo a la persona, cuando identificamos que no quiere, no quiere, ¿verdad?
Juan (43:13)
fuerte
Sí, wow.
Douglas (43:25)
Sí, el consejo técnico sería para las personas de operaciones automatizar lo más que puedas. Automatizar lo más que puedas y realmente yo te voy a decir algo, no solo los de operaciones, para todos, vos sos un developer, que para correr tu ambiente local...
necesitas borrar los archivos temporales, borrar el node models y cualquier otra dependencia, luego necesitas detener el contenedor de Docker y luego volver a correr Docker ComposeUp, ¿verdad? Entonces cualquiera dice, eso me toma 40 segundos, ¿ok? Haces cambios y otra vez a los tres minutos a volver a ejecutar esos 40 segundos de cambios, ¿verdad?
y volvés a hacer algo a los 10 minutos y volvés a ejecutar eso. Te topaste con que estás repitiendo los mismos pasos, estás repitiendo más de dos o tres pasos bien seguido, automatizálo. Créate un script que lo ejecutés y lo haga. Créate un makefile para que le das make clean o make restart, como lo querrás llamar. ¿Verdad? Hace lo que te sea más fácil para automatizar ese proceso.
y en la parte de operaciones es tan clave, tan crítico ver que estamos repitiendo un proceso para publicar, para jalar logs, estamos repitiendo un proceso para lo que sea que queramos jalar métricas y conectarnos a lo que sea y lo estamos haciendo varias veces, automatizémoslo.
Comenzá con un simple bash script, eso es lo que tienes a tu alcance. Aunque al final del día el bash script lo tengas que correr manual. Bueno, te ahorraste los 12, 15 comandos que corrías en un solo comando. El siguiente día o el siguiente mes o a la siguiente oportunidad que tengas el tiempo de dedicarle, ves cómo lo implementas en un pipeline, ¿verdad? Pero no hagas procesos repetitivos. Y eso fue otro reto con el que me encontré. Toparme con personas que.
toparme con personas que pasaban toda la noche, displegando aplicaciones, porque era bien tedioso hacerlo, cuando si le dedicabas tiempo se podía automatizar y se podía hacer rápido, ¿verdad? Entonces, automatizar, eso te va a quitar tiempo para enfocarlo en cosas más importantes. No vas a ganar nada con repetir el mismo proceso.
500 veces, no ganas más conocimiento, ganas más... tal vez aprendiste a escribir medio segundo más rápido y ese fue tu gran logro, entonces no ganas nada con eso. Dedicávele el tiempo, automatizálo para que después en lugar de repetir el mismo proceso 500 veces lo corras hasta llegar al punto de que se genere manual, perdón automático y no manual y ese tiempo lo invertís en otras áreas y si vas creciendo, vas creciendo, vas creciendo.
pero automatizar, comenzar como puedas, comenzar con la habilidad que tengas, bashcrit si te sabes python usa python, si quieres usar Jenkins o un pipeline, lo que se te ocurra, pero comenzar a automatizar todo lo que tenga dos o tres pasos o más repetidos.
Juan (46:48)
Excelente, excelente. Bueno, me agrada mucho. Creo que con esto podemos ir cerrando el episodio de hoy. Creo que han sido unos consejos muy, buenos. Bastante fuerte, pero tenés toda la razón. Al que no ayuda, pues que no estorbe. Entonces, estoy muy, muy contento.
contento con el contenido de hoy Douglas, espero que a las personas les haya sido igual de interesante y que puedan ellos también tomar estos consejos, estas experiencias para que puedan mejorar su ambiente y su experiencia de trabajo porque al final del día todo esto lo que nos ayuda es a poder disfrutar nuestro trabajo y no tener que gastar tanto tiempo en diferentes problemas y tener que
ir a trabajar un domingo cuando no queremos. Todo esto ayuda a que podamos realmente vivir y trabajar de una mejor manera. Entonces, no sé si quisieras algunas últimas palabras Douglas para el episodio de hoy.
Douglas (47:58)
No realmente contento, de igual manera muy contento. Vamos a tocar más temas a detalle, futuro, tanto en parte cultural, o parte técnica, o diferentes tecnologías. Pero me gustó lo que dijiste, se trata de disfrutar lo que hacemos.
Se trata de que nos genere esa satisfacción personal. Todos necesitamos un trabajo, necesitamos comer, todos necesitamos proveer para nuestras familias o para pagar nuestros estudios o cualquiera que sea la situación individual de cada persona. Pero disfrutemos el trabajo, ¿verdad? Y de eso se trata. No se van a arrepentir.
Juan (48:42)
estoy totalmente de acuerdo. Muy bien, con eso cerramos y entonces nos vemos el siguiente episodio donde vamos a hablar de muchos otros temas muy interesantes de todo este mundo de tecnología. que esto ha sido Dev & Ops por el día de hoy. Nos vemos en la próxima.