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)
hay menos profesional que se enfoque en el área de sistemas en comparación a los profesionales que están en el área de desarrollo.
porque incluso aún en desarrollo,
yo me encuentro más desarrollador de front-end que desarrolladores de backend o desarrolladores de aplicaciones móviles. Entonces lo mismo pasa ya a una escala más grande con los profesionales en el área de infraestructura, son menos. Y a pesar de que en un equipo donde normalmente va a haber mínimo un desarrollador front-end y un desarrollador backend y tal vez un project manager, va a haber solo una persona de sistemas en ese equipo.
es menos la cantidad de gente que se necesita, por ende hay mayor demanda de trabajo
Juan (00:45)
Bienvenidos sean todos a un episodio más de nuestro podcast de DevonOps. Aquí estamos una vez más con nuestro gran amigo Douglas. Esta vez lo incluyo para todos nosotros. Ok, ya es nuestro amigo. Douglas, ¿cómo has estado? ¿Qué tal?
Douglas (01:02)
Juan,
¿qué tal? Yo muy bien, gracias a Dios. Como siempre, listo, preparado para una discusión más, esperando que la audiencia, los que nos ven y nos escuchan, puedan aprender y disfrutar este tiempo tanto como a nosotros se nos pasan estas conversaciones.
Juan (01:21)
Sí, sí, es correcto.
Desde el episodio uno lo hemos dicho que nuestra finalidad es poder ayudar un poco a la comunidad que nos ve en español porque sabemos que hay comunidades en inglés que también tienen, que comparten mucho el conocimiento. En español nosotros estamos intentando dejar nuestro granito de arena, ¿no? Y, antes de empezar me gustaría, pues, disculparme un poco si me escuchan un poco extraño. Estoy un poco, me estoy recuperando de un momento ahí de enfermedad, pero...
Douglas (01:41)
Sí.
Juan (01:53)
pues aquí estamos nuevamente tratando de apoyarnos y dejar un poco nuestro conocimiento y nuestras opiniones en estos temas.
Douglas (02:03)
Y qué bueno Juan, que pudiste hacer el sacrificio, perdón de estar, a pesar de estarte recuperando porque muy probablemente nuestra audiencia no quiere volver a escuchar otro monólogo de mi parte, pero bueno, me alegra que hayas podido estar.
Juan (02:13)
No,
No, no, gracias. La verdad es que...
Bueno, yo disfruté el episodio que grabaste solo y estoy seguro que muchos también lo disfrutaron. Pero bueno, sí. El episodio de hoy creo que sí requería que estuviéramos conectados los dos porque como probablemente ya están viendo en el título, tal vez el título va ser un poquito diferente, pero el tema que nos compete el día de hoy es cómo pasar de desarrollador a un ingeniero SRE. Y aquí vamos a hacer un poco unas cuantas aclaraciones.
con desarrollador me refiero porque no significa que un sr no es un desarrollador pero estamos como tratando de englobar las palabras que es lo primero que se te viene a la mente cuando escuchas un developer, desarrollador a mí en lo personal se me viene una persona que tiene que ver con páginas web o backend de páginas web o desarrollador de aplicaciones móviles y muchas veces no se me viene a la mente pero también
encaja una persona que hace aplicaciones para escritorio, para Windows, Entonces a eso me refiero con desarrollador. SRE por otro lado es de hecho Dulas nos habló mucho sobre el SRE y estos puestos que existen de DevOps Engineer que bueno ya lo hemos dicho en otros episodios también que la palabra DevOps ha sido un poco mal utilizada en la industria pero pues
es lo que hay entonces es a mí significa side reliability engineer y es la persona que se encarga de manejar el lar cuál sería la traducción dublas de real reliability sería como robustes
Douglas (04:08)
la disponibilidad.
Juan (04:09)
disponibilidad
gracias básicamente es la persona que se encarga de esta parte de nuestro sistema que los desarrolladores no estamos tan en contacto con ellas así que queremos tocar ese tema porque definitivamente es un área de trabajo que es muy interesante y estoy seguro que a muchas personas les llama la atención pero tal vez si solamente estamos expuestos o en su mayoría estamos
expuestos a ya sea curso sobre desarrollo web o noticias sobre desarrollo web tal vez no está tan claro cómo iniciar en esta otra en este otro departamento así que vamos a tratar de hablar sobre eso de cómo podrías por tu cuenta tratar de iniciarte en este camino y vamos a tratar de dar algunos tips yo por mí por mi parte a pesar de que soy un desarrollador
si me interesa mucho esta área y en muchos momentos, te confieso Douglas, en muchos momentos de mi vida he considerado si debería transicionar hacia esta área. Tal vez en algún punto lo haga, no estoy seguro, pero lo he considerado. Así que también es algo que me va ayudar a mí personalmente esta charla, que bueno, por eso considero que también a muchos les pago.
Primero que nada me gustaría que tal vez, ya lo has hablado Douglas en varios episodios, para que tengamos el contexto completo dentro de este video podrías hablarnos brevemente que cuáles serían las responsabilidades de un SRE a grandes rasgos, sin tanto detalle tal vez.
Douglas (06:06)
Sí, por supuesto.
En palabras simples, SRE, que nace en Google, el puesto y la cultura como tal, es básicamente un profesional que mezcla prácticas de desarrollo de software, prácticas del ciclo de vida de desarrollo de software para administrar infraestructura de aplicaciones con intención, con la mira principal.
de la disponibilidad y el rendimiento de estas aplicaciones y la integración continua con la parte del código incluyendo publicaciones automatizadas y aparte empoderando a los programadores a que puedan acceder no solo a estas publicaciones a la manera de poder desplegar estas aplicaciones sino también muy importante acceso a métricas, a logs.
porque de nuevo, el rendimiento y la alta disponibilidad es clave para este puesto. Entonces, tener acceso a estas métricas, estos logs, es súper importante. Y este puesto, en pocas palabras, se encarga de eso. Entonces, yo le agregaría, tal vez, lo que mucha gente conoce como DevOps Engineer, pero tiene ese agregado de preocuparse por el rendimiento, por ende, está muy pendiente de métricas alrededor de los diferentes sistemas, de la aplicación en sí como tal.
de cuánto la aplicación, el código de la aplicación puede manejar como métricas a nivel de servidor y servicios.
Juan (07:34)
Excelente.
OK. Entonces, en ese aspecto me gustaría cómo dar los primeros puntos que quisiera tomar, de los que quisiera hablar el día de hoy. El primer punto del que quisiera hablar Douglas es el por qué alguien podría interesarse en esta área. Y aquí voy a empezar yo, voy a empezar cuál es mi punto de vista, de por qué me parece un área muy interesante. Y es que a mí en lo personal me llama la atención el hecho de automatizar estos procesos y poder gestionar estas
aplicaciones.
y de tal manera que funcionan una vez que ya está todo configurado funcionan sin que yo tenga que intervenir tanto el hecho de poder crear soluciones que no solo me sirven a mí sino al resto del equipo eso para mí me parece muy muy interesante me gustaría saber tu opinión Douglas de ya que vos trabajas de eso qué consideras que son los puntos atractivos
activos de tu trabajo, para alguien que lo está pensando.
Douglas (08:44)
Sí,
fíjate que lo quiero abordar desde la perspectiva porque el tema está orientado a desarrolladores que quisieran transicionar, no necesariamente a personas que recién comienzan en tecnología y quieren comenzar con el área de SRE.
Juan (09:00)
Claro, porque serían los desarrolladores,
perdón que te interrumpa, son personas que ya están expuestas al mundo de tecnología, ya tienen un conocimiento probablemente, vamos a partir de un nivel junior, ya más o menos conocen los conceptos y saben que existe este trabajo, este puesto de trabajo.
Douglas (09:08)
Sí.
Así es, estamos hablando de un profesional, ya un profesional en tecnología, solo que está en la rama de desarrollo y quiere considerar o tal vez está considerando. Entonces desde esa perspectiva, uno de los puntos que pudiera ser llamativo, es probablemente un incremento salarial. Y es esto va de la mano con que no hay tanto...
Juan (09:42)
Buen punto.
Douglas (09:47)
profesional en el área de sistemas, SRE o Cloud Engineer, Systems Engineer o DevOps Engineer, se le quiera llamar dependiendo lugar o dependiendo de los roles, hay menos profesional que se enfoque en el área de sistemas en comparación a los profesionales que están en el área de desarrollo.
porque incluso aún en desarrollo, si vos ves mucho profesional nuevo, al menos en mi experiencia, platicando con mucho programador junior o con muchos jóvenes que están saliendo de la universidad, están más enfocados de hecho en front end.
Y yo me encuentro más desarrollador de front-end que desarrolladores de backend o desarrolladores de aplicaciones móviles. Entonces lo mismo pasa ya a una escala más grande con los profesionales en el área de infraestructura, son menos. Y a pesar de que en un equipo donde normalmente va a haber mínimo un desarrollador front-end y un desarrollador backend y tal vez un project manager, va a haber solo una persona de sistemas en ese equipo.
Juan (10:25)
Sí.
Douglas (10:53)
es menos la cantidad de gente que se necesita, por ende hay mayor demanda de trabajo al haber bastante oferta laboral y poca gente que está buscando el puesto, los salarios suelen ser más altos que el de un programador, entonces ese sería como un primer punto a resaltar.
Juan (11:05)
Sí.
Douglas (11:16)
Yo sé que aquí hablamos por la pasión de la tecnología, el desarrollo, esto a nosotros es una pasión nuestra, Juan, y yo sé que las personas que nos ven y nos escuchan van en esa línea, de lo contrario, no estuvieran aquí pendientes de nuestro contenido y no es inc...
Juan (11:30)
Estaré viendo TikTok de otros aspectos.
⁓
Douglas (11:37)
Exacto, exacto,
sí, sí. Entonces, y no es que quisiera deviar ese sentimiento, ese corazón de seguir apasionados por tecnología, pero al final del día necesitamos ese salario para seguir creciendo como personas y seguiríamos dentro del área de sistemas, dentro del área de tecnología, perdón. Entonces ese sería un motivo, creo yo, bueno...
grande a considerar si alguien lo está pensando. Otro motivo yo creo que sería bastante relacionado con lo que estabas diciendo y si alguien le gusta la automatización, le gusta que las cosas ocurran solas. Yo no sé si vos tuviste la oportunidad Juan de ver la película Back to the Future, Regreso al Futuro, película que fue lanzada al cine.
Juan (12:23)
Sí.
No la vi en el cine,
pero sí.
Douglas (12:28)
No, yo tampoco, porque fue lanzado al
cine justo el año en que yo nací. Entonces no podía haber ido al cine. Pero al principio de esta película se ve como el Doug Brown, el doctor que inventa la máquina del tiempo.
Juan (12:32)
⁓ es cierto, sí,
Douglas (12:42)
tiene su sistemita automático donde un reloj empuja una cosa y hace que caigan los huevos en la fridera y se batan y luego se mueve otra cosa y sale el pan tostado y otra se mueve y desenrosca la lata de comida del perro y aquel gran movimiento ahí, ¿verdad? Y yo recuerdo pequeño, sin relacionarlo con tecnología, pero yo recuerdo pequeño, eso fue algo que me cautivó mucho.
Juan (12:49)
Sí, sí.
Sí.
Douglas (13:07)
Y ⁓ yo quería ingeniar cosas similares. Pues, una satisfacción similar.
se siente cuando has automatizado algo, algo tan sencillo como un commit a un repositorio y que ejecuta diferentes pruebas y que actúa de manera autónoma, voy a decirlo, está obviamente preprogramado o preescripteado, pero actúa de manera autónoma si encuentro un error notificar a diferentes personas por diferentes canales, si no encuentro un error.
pasar a hacer un build, publicar a diferentes lugares, mandar un reporte de cuánto hizo y ver esa maquinita funcionar y operar que una cosa, exacto, que una cosa empuja a la otra, genera esa satisfacción.
Juan (13:48)
todo ese flujo de cómo va pasando.
Douglas (13:56)
Entonces, si te gusta esa parte donde las cosas se automatizan y quedan corriendo basado en interacciones de usuarios o de otros ingenieros, es otro, este es el lugar perfecto, este es el área perfecta para este tipo de profesionales.
Juan (14:14)
Sí, uno se puede dar gusto en ese aspecto. Últimamente he estado viendo Noah en profundidad.
pero he estado viendo que hablan mucho sobre esta nueva herramienta, bueno no sé cómo categorizarla pero se llama 8N8 creo que es N8N, correcto, N8N sí y veo cómo automatizan un montón de cosas y eso está más bonito porque como tiene una parte visual donde se mira de cómo se van entrelazando todas las tareas me llama la atención eso y se puede relacionar mucho con
Douglas (14:29)
N8N Sí, en el ojo
Juan (14:52)
cómo funciona ese aspecto del SRE de ese departamento.
Douglas (14:56)
De hecho, eso es un muy buen ejemplo,
para quienes han tenido la oportunidad de ver esta herramienta. Esto es un muy buen ejemplo. Esta herramienta, aunque puede hacer cosas técnicas y profundas, es más utilizada para operaciones de editoriales o de contenido en redes sociales, SEO y cosas similares porque reacciona tal vez a un comentario en redes sociales y basado en ese comentario compara contra una base de datos del usuario y se da este tipo de interacciones.
aunque puede hacer de nuevo automatizaciones de infraestructura, lo que ocurre es que quien necesita automatizaciones de infraestructura normalmente tiene la capacidad de hacerlas en código y no lo va a utilizar. No es hate contra la herramienta, de hecho es buenísima y es muy recomendada. Pero lo que quiero resaltar aquí es que hizo el ejemplo perfecto.
Juan (15:42)
No es nada.
Douglas (15:46)
en esa herramienta se mira cómo se mueve todo y genera esa satisfacción cuando ya se logra crear tu flujo de trabajo en esta herramienta y luego te sentir bien de que estás enfocado en otras cosas porque las horas que le dedicaste a esto siguen funcionando día a día, veces hora a hora o minuto a minuto sin que vos tengas que intervenir y de nuevo esa es la satisfacción que genera este tipo de automatizaciones.
Juan (16:14)
es correcto, sí. Bueno, antes de continuar con...
el tema principal de cómo transicionar, me gustaría dar otro punto que me parece interesante del por qué puede ser atractivo para un desarrollador y es que si ya un desarrollador ya ha notado que no te gusta mucho interactuar con el cliente, con el PM y tener que trabajar con tantos features que están saliendo continuamente y este tipo de trabajo que se da
de
personas, no digo eso. Pero sí representa un cambio de aires con respecto a cómo con el tipo de personas que vas a interactuar. bueno, eso lo que yo recuerdo, Lula, es que nos has comentado que en ciertos momentos te toca interactuar con otro tipo de clientes y con personal de tu equipo. Pero imagino que las pláticas siempre van más orientadas a un aspecto más técnico.
o me equivoco o si te toca hacer otro tipo de charlas y meetings.
Douglas (17:55)
Fíjate que sí
Juan, la verdad es que sí, voy a tener que discrepar un poco y creo que tenés 100 % razón en el sentido de que es un cambio de aire, eso sí, por supuesto, porque tal vez la conversación se va a comenzar desde un ángulo diferente, pero cualquier profesional dedicado y que busca hacer las cosas bien,
Juan (18:00)
Ok, ok.
Douglas (18:23)
está obligado de manera general a entender la parte del cliente. de hecho, para darte un ejemplo sencillo, de hecho si estás monitoreando una aplicación y estoy recibiendo logs del front-end y me topo con que están atacando un formulario porque no tenía captcha o...
alguna validación para evitar que los bots lo ataquen. entonces, de ese punto en adelante toca reportar a alguien que está ese formulario, por qué está ese formulario, desde cuándo está, porque también quiere saber. Esto es algo que recién publicaron o que recién encontraron para exploit, para vulnerable, y tal vez ya días está corriendo. Entonces, comenzás con esa integración y a veces...
Por esa interacción me tocó saber algo de Frontend, donde tal vez el ingeniero de Backend nunca hubiese tenido que relacionarse con eso porque no está preocupado por los logs del Frontend, mientras que el de SRE sí. Y aparte, de hecho, Juan sí toca interactuar con clientes o usuarios finales y la conversación suele ser un poco más compleja porque...
Juan (19:16)
Ok, ok.
Douglas (19:38)
los aspectos en la parte de sistemas suelen ser más técnicos.
para el usuario final porque son conceptos que conocen o escuchan menos. Un usuario final está bastante expuesto a lo que es un front-end y sabe lo que es un text box, un botón, un drop-down, sabe lo que es un pop-up. ese tipo de cosas y conceptos es más fácil para ellos, aunque son técnicos, porque están expuestos a ellos constantemente. Pero a conceptos de redes, de servidores, a conceptos de...
paquetes, de conexiones, timeouts, ese tipo de cosas no están expuestos en su día a día y se vuelve más complejo para ellos y de hecho es más retante poder comunicarte con la gente no técnica para explicar lo que ocurrió en un lenguaje que puedan entenderlo, verdad, porque eso es un reto que tenemos todas las personas que trabajamos en tecnología o los programadores. Entonces, yo no lo aconsejaría ⁓
para alejarse de tener que platicar con clientes o con PMs porque de hecho la conversación se vuelven un poco más tediosas y complejas. Pero sí lo puedo aconsejar definitivamente si quieres cambiar de aires y no interactuar con con las mismas personas de la misma manera. A veces son un programador de front-end y alguien está usando un dispositivo en una resolución...
que nadie nunca había descubierto porque tal vez él le dio resized y quedó en una resolución random ahí y está fallando, está recibiendo ese tipo de reportes constantemente que son tediosos para ajustar un textito y querés cambiar a que la conversación suela ser por lo menos más interesante con problemas más retantes. Entonces por ahí sí definitivamente lo recomendaría.
Juan (21:12)
jajaja
¡Qué excelente!
Bueno, entonces me agrada mucho porque desde mi punto de vista pensaba que era el contrario. sea, sí sabía que interactuabas con tus otros compañeros, pero no tenía la idea de qué tanto. Y yo creo que tal vez muchas personas tal vez tenían el mismo mito o pensaban que el mito de que no está más recluido en tu esquina pensaban que era cierto. Qué bueno que lo hayas desmentido entonces. Al menos así, si alguien lo estaba pensando por
ese mismo motivo al menos ya puede reconsiderarlo. Sí, sí, sí. Qué bueno. Entonces, bueno, vamos a ver si podemos desmentir otras dudas más adelante. Pasemos entonces, Douglas, a las habilidades que consideramos que sean más importantes conocer para tratar de ir transicionando a este otro departamento.
Douglas (22:09)
que reconsidieras.
Juan (22:35)
y claro, hay muchos tutoriales y cursos en línea de cómo entrenarnos en esta área pero digamos que vamos, yo lo estoy orientando Douglas, lo estoy pensando mejor dicho para alguien que quiere empezar a investigar ciertos temas a ver si le interesa y el primero que se me viene a la mente Douglas es conocer sobre sistemas operativos y más
precisamente sobre linux probablemente ese sería un buen punto de partida saber cómo funciona linux como las diferentes distribuciones que existen cómo gestionarlo no cómo actualizar un sistema sin que sin afectar a lo que está corriendo creo que tal vez por ahí podríamos empezar doblas con linux
Douglas (23:30)
Fíjate que es el
punto de partida más común, Sin embargo, yo lo voy a poner en segundo lugar. Yo lo voy a poner en un segundo lugar y lo vamos a abordar un poco a profundidad, pero antes me gustaría mencionar lo que en mi opinión es el primer lugar, que sí es un aspecto técnico.
Juan (23:37)
interesante.
Douglas (23:51)
aunque a veces puede ser una habilidad blanda, yo considero que sí es un aspecto técnico. Y el primer punto sería, y de nuevo, estoy pensando de programadores que están transicionando a este rol. Si fuese alguien que recién comienza en tecnología, lo orientamos primero a sistemas operativos. Pero para un programador que se viene orientando a este rol, lo primero sería adquirir la mentalidad de ingeniero.
Juan (24:06)
Sí, sí,
Douglas (24:21)
recordemos que el ingeniero es aquel que ingine soluciones, ¿verdad? Y alguien podrá decirme, pero yo soy un software developer y nosotros somos ingenieros en desarrollo. La realidad es que no todos. Hay mucho programador que lo único que hace es codificar.
Juan (24:24)
serás ingenia.
Douglas (24:43)
Y realmente eso no es ingeniería. No estoy desmeritando a nadie, no estoy criticando a nadie, solo estoy poniendo realidades en la mesa. Hay mucho programador, ya sea backend o frontend, que solo es programador y recibe tickets y comienza a codificar lo que le pidieron que haga. Sobre todo más en backend, frontend pasa muchas veces, pero también pasa en backend. Necesitamos...
Juan (25:09)
solo
la gente del front end siempre se queja que le tiramos mucho mucho hate los de back end y los de sr e les tiran de la de front end
Douglas (25:19)
Sí,
pero es que Fiat es Juan y no es tirar hate por tirar hate, nada por el estilo. Realmente es que en front-end hay una gran gama de arquitectura y de ingeniería para hacerlo eficiente, rápido, porque es el que va correr del lado del cliente y querés que sea lo más rápido, liviano posible, a la vez seguro, que no tenga vulnerabilidades. Entonces, ahí hay una gran gama de arquitectura e ingeniería.
Juan (25:24)
Si yo no le estiro hate
Douglas (25:49)
Sin embargo, de nuevo, cuando un programador le gusta el código y no la parte de ingeniería, no gusta solamente estar codificando. Entonces, en los puestos de SRE, en estos roles de sistemas, casi que no hay soluciones que requieran solo ejecutar algo. Si vos abrís cualquier buscador de trabajos,
ya sea en LinkedIn o en cualquiera de estos puestos o sitios famosos para buscar trabajo de tecnología, te vas a topar con muy poquitos puestos en sistemas junior. Muy poquitos puestos, si no es que no hay del todo. Porque en realidad en estos puestos, en este rol, te toca estar ingeniando soluciones por pequeñas que parezcan. Te llenan con un reto, fíjate que...
ocupo un pipeline que saque un commit de otro repositorio y que lo valide contra otro repositorio y ya comienzan con aquellas peticiones que hubo que dar. y este tipo que estaba fumando cuando se le ocurrió algo así. Y comenzar por ver y definir y a veces toca decir, mira, ve lo que estás pidiendo.
no tiene mucho sentido porque existe una forma más fácil de hacerlo y empezás a mostrarle y estás ingeniando la respuesta o a veces toca ingeniarle lo que él está pidiendo. Entonces casi no hay trabajos repetitivos por más que en tu empresa existan estándares y flujos ya definidos, toca estar ingeniando, adaptando, toca estar pendiente de que se cumplan las cosas para levantar la bandera roja si alguien no está siguiendo lo que se está siguiendo.
Juan (27:38)
⁓ O sea, Douglas, si soy una persona o un desarrollador que...
Douglas (27:38)
Normalmente.
Juan (27:46)
que dependo mucho de librerías de terceros o de soluciones que ya han sido implementadas o de que ya esté algo establecido entonces ahí tengo que reconsiderar mi forma de trabajar para poder pasar a SRE o mejor dicho alguien que es así se las va ver muy difícil al momento de pasar a un puesto de SRE
No está listo.
Douglas (28:16)
Si yo diría que no está listo para hacer esa transición
y más que yo lo pondría más que tal vez buscar no utilizar librerías de terceros o cosas por el estilo serían más estos programadores aunque sean seniors que pero que dependen del arquitecto que está diseñando y está diciendo qué hacer y son de estas personas que dicen tal vez por comodidad tal vez porque ya tienen mucho tiempo y no quieren hacerlo o tal vez porque sólo le gusta codificar de nuevo
programador y yo los entiendo pero sólo le gusta codificar sólo están esperando que se le asigne la tarea de qué va a hacer al final del día este programador es de nuevo para todos los que nos ven y nos escuchan no estirar no estirar no hay ningún problema con ello cada quien tiene lo que le gusta hacer pero estos programadores al final del día se sienten bien de la solución que codificaron pero realmente están codificando la idea de otro
le dieron vida, fueron buenos, fueron inteligentes, supieron hacer código eficiente, todo eso muy bueno, pero en realidad...
es ir un poquito más allá y tener esa mentalidad de ingeniar, arquitectar soluciones, ¿verdad? Porque de nuevo, ya en los puestos de SRE, en los puestos de sistemas, los puestos junior que existen, en su gran mayoría, un junior SRE, un junior DevOps engineer, porque los he visto, los puestos, en realidad lo que son...
Juan (29:46)
Sí, sí.
Douglas (29:49)
son realmente support engineers que están haciendo trabajos de mantenimiento.
para diferentes sistemas, trabajo de actualizar sistemas, actualizar versiones, estar manteniendo ciertos servicios que requieren actualizar código en Terraform para hacer la actualización o estar manteniendo al día la versión de Python y la versión de sistema operativo, o estar haciendo ese tipo de tareas tediosas, pero en realidad, y como necesitan conocer de Terraform, de Ansible o de algunas herramientas de DevOps o de SRE,
Por eso es que les dicen junior SRE o junior DevOps engineer, pero en realidad son support engineers que usan esas herramientas para hacer su trabajo. Entonces, para resumirlo Juan, yo sí lo creo, sí lo creo, que cualquier desarrollador que quisiera transicionar a los...
y los roles de SRE que comiencen con una mentalidad de ingeniería. De hecho, el ingeniero está en el título, Site Reliability Engineer, mientras que no siempre en los puestos de desarrollador incluye la palabra ingeniero. Entonces, yo comenzaría por ahí.
Juan (30:58)
Sí.
Ok, interesante. Lo primero entonces sería cambiar nuestra mentalidad, tratar de... ¿Considerarías entonces que alguien que le gusta arquitectar, digamos, la aplicación entera, tal vez ahí ya está un poco más orientado a este paso, Alguien que no depende tanto de que se lo den ya hecho, ya masticado.
Douglas (31:28)
Sí.
Sí, es que este
tipo de programadores, Juan, vos los ves y destacan porque se topan con un problema y ven que las pruebas del código, toca estar ejecutando cinco comandos para hacer las pruebas y te fijas que ellos cuando le están haciendo code review en su commit, subieron un script para automatizar ese proceso en su local. O tal vez ves que mínimo está en el gitignore.
Juan (31:57)
Sí.
Douglas (32:02)
un script que no sabes que tiene y es porque él en su local tiene ese script para estar ejecutando ciertas cosas. Entonces son personas que no están conformes con cosas pequeñitas que ven que se pueden pulir o se pueden perfeccionar para automatizar las cosas, para hacerlo mejor. O sea desde ahí lo ves a este tipo de programadores y ya serían como ingenieros web, ingenieros de desarrollo y sería por la mentalidad.
Juan (32:28)
interesante. Sí, por ahí he escuchado, hay personas que comentan, ¿no? Que es muy fácil triunfar en tecnología y más que todo en el desarrollo de aplicaciones siendo alguien, palabras fuertes, ¿no? Pero siendo alguien mediocre. Es muy fácil que te vaya bien económicamente y hagas una carrera, pero realmente nunca sobresalís.
Douglas (32:47)
Sí.
Juan (32:58)
complicado pero pues si creo que tenés razón eso pasa pero bueno
Douglas (33:04)
Sí.
Juan (33:08)
digamos que ya hemos tenido como un momento de reflexión sobre nuestra forma de trabajar y sí es alguien que está cambiando su mentalidad. gustaría también como que mencionamos qué habilidades pueden ser necesarias que mejoren, ¿no? Porque de nuevo desde mi punto de vista Douglas, uno como desarrollador normalmente no se expone a las herramientas y conocimientos que son
queridos ahí a veces es un poco difícil encontrar como como una lista de que se necesita sin antes haber pagado un curso verdad sin antes haber pagado algo entonces me gustaría como que dieramos una tal vez una pequeña lista antes de tal vez entrar en cosas un poco más complejas y más específicas que tal vez vos conoces yo tengo una lista aquí de que yo creo que es necesario
que probablemente conozcamos para poder empezar a transicionar. bueno, yo lo menciono como transicionar, hoy en día eso puede sonar un poco extraño, pero como para tratar de cambiar de puesto.
Douglas (34:21)
Sí.
Juan (34:22)
yo te mencionaba Linux y me dijiste que sí pero tal vez en segundo lugar entonces es necesario profundizar en Linux luego también yo creo que sería necesario Douglas aprender mucho sobre contenedores y contenerización o consideras que no es necesario algo tan profundo en ese tema en específico
Douglas (34:51)
Sí, no. Sí es importante, sí es necesario y sí es de la base porque la mayoría de servicios hoy en día son publicados y desplegados a contenedores. por esa parte sí. Igual no sé la lista completa que tenés, pero en sistemas operativos a mí me gustaría agregar que más allá de solo entender... Y de nuevo, Linux sería el más recomendado.
Juan (35:01)
están contundentes.
Mm-hmm.
Douglas (35:18)
por supuesto, pero más allá de solo entender y saber utilizarlo y distribuciones, etcétera, los diferentes servicios a nivel de sistema operativo, cómo funciona un sistema operativo de manera en general, su interacción con la memoria, con el CPU, entender cosas, Juan, como por ejemplo cada vez que escribís al disco duro trabaja el CPU.
cada escritura en el disco trabaja el CPU o cuando cargas algo en memoria que va a leer del disco duro lo carga en memoria RAM. Ese tipo de cosas que parecen pequeñas te permiten identificar soluciones porque si algo va a estar leyendo o escribiendo bastante en disco duro no solo ocupas un disco duro rápido eficiente, también vas a ocupar suficiente CPU.
Juan (35:54)
Sí.
Douglas (36:09)
para que pueda hacerse cargo de la lectura y escritura del disco duro y dependiendo cuánto memoria, cuántos objetos vas a estar cargando, esa cantidad de memoria.
Entonces parecen cosas pequeñas, pero entender ese tipo de interacciones es importante a nivel de sistemas operativos. Cómo funcionan los file systems o los diferentes servicios, protocolos que corren en un sistema operativo desde tal vez servicios comunes como web servers, a servidores de correo electrónico, a cosas como...
Juan (36:28)
Sí.
Douglas (36:44)
las sesiones remotas de manera segura, SSH, SFTP, intercambio de archivos, servicios como NTP, monitoreo y todo este tipo de servicios y protocolos que existen a nivel de servidor realmente es más profundo de lo que parece. Entonces no es con intención de desanimar a nadie porque en realidad que en poco tiempo y con dedicación se puede adquirir este nivel necesario.
y requiere de que estemos probando cosas, requiere de que estemos haciendo nuestro propio HomeLab y aunque sea innecesario levantar un servidor de correo local para enviar un correo a mi propia cuenta, aunque me va a llegar a spam porque no es un correo real, probar este tipo de cosas, diferentes comandos, llamar a un webhook por...
Juan (37:29)
Sí.
Douglas (37:36)
CURL y diferentes tipos de tareas al igual de sistema operativo. Entonces no quiero desanimar, solamente tampoco quiero vender humo y decir con que sepan algunos cuantos comandos en Linux y le entiendan un poquito ya van a estar listos. Sistemas operativos es un tema más profundo de lo que parece.
Juan (37:53)
Sí.
Sí, qué bueno que lo aclaraste porque obviamente a eso me refería con englobar sistemas operativos, tal vez solo decir a conocer Linux tal vez se escucha muy...
Como que es fácil y no es que sea tan complicado, no es ingeniería espacial, ¿no? Pero sí tienen muchas cosas y en cada una de ellas podemos profundizar mucho. Que eso es otra cuestión, ¿no Douglas? ¿Hasta qué punto es necesario profundizar en cada uno de los temas? Tal vez yo tengo la forma de abordar las cosas que voy aprendiendo y ya lo hemos hablado antes también.
que a medida lo que voy necesitando eso lo que voy desarrollando y en ese punto es donde voy profundizando hasta donde necesito y en el tema de Linux se puede profundizar mucho en cada uno de los temas lo que es System D por eso tiene mucha tela que cortar y bueno va a depender de que tanto lo necesitamos, verdad? cada uno de los comandos
y herramientas que existen son bien complejas cuando ya las vemos a profundidad pero sí
Douglas (39:17)
Sí, y es por eso, Juan, tal
vez para aclarar, cuando yo mencionaba los requerimientos para un SRE, cuando discutía ese tema, hablaba de algo que menciona el propio libro de Google, que no es que lo dice como que de manera textual, solo un sysandling puede ser SRE, pero sí lo menciona y sí lo dice de que...
El mejor candidato que es el que la tiene más fácil es un sysadmin que aprende a codificar y esto habla no de que no pueda un programador transicionar a SRE, sino que habla qué tareas se hace más dentro del rol. El rol tiene mayores tareas de lo que comúnmente era para un sysadmin antes que lo que es para un developer, aunque incluye prácticas de desarrollo y hay que programar porque hay que programar sí o sí.
las tareas de sysadmin son más profundas, entonces un programador tiene más tela que cortar para llegar a lo que se necesita de conocimiento mínimo a nivel de sysadmin para el puesto de desarrollar que lo que tiene un sysadmin, la tela que tiene que cortar para aprender lo mínimo de desarrollo.
Entonces, sí que sepan las personas de desarrollo que tienen interés en esta área que sí tienen bastantes pasos que dar. De nuevo, no con intención de desanimar a nadie. Conozco varios, cierto. Bueno, mi hermano, lo conocés? Él era un desarrollador, de hecho, y siguiendo muchas de estas cosas que estamos hablando, el transición no.
Juan (40:51)
Sí.
Douglas (40:58)
estos puestos de SRI que es a lo que él se dedica por ya no sé cuántos años ya. Entonces de qué es posible, definitivamente, entonces solamente no quiero vender falsas expectativas, eso es todo.
Juan (41:11)
Claro, claro, sí, no estamos diciendo que con un curso de dos horas ya estamos listos. por eso me gusta que vayas aclarando estos puntos porque siempre es necesario tener los pies en la tierra con las cosas que queremos hacer. Y más si una persona está pensando en cambiar de rubro, bueno, no de rubro como tal, diría, pero sí de departamento, un rol exacto. Es importante tener en cuenta esto.
Douglas (41:35)
de rol.
Juan (41:41)
porque no cualquier empresa también te va a permitir cambiar una vez, dos veces, tres veces te pasaste de Serena, gustó, luego te pasas a Frontend luego a Mobile y es como, no estás contento con nada
Douglas (41:52)
Sí, sí, ahí
ya es otro problema.
Juan (41:58)
ya es otro problema,
no? así que sí, es importante, definitivamente estoy seguro que hay muchas personas que les interesa y se puede, se puede hacer bien, entonces hemos dicho Douglas Linux contenedores con los contenedores supongo yo que el enfoque principal debería ser Docker y Kubernetes o me paso por alto algo más
Douglas (42:28)
Docker en general, sea, Docker es el más usado en realidad entender cómo funcionan los contenedores, si es importante, que en realidad funcionan al nivel de kernel de Linux, incluso Containerd y hay otro tipo de tecnología, pero Docker en general entender cómo funciona, adoptar, perdón, contenedores en general y entender cómo funciona. Adoptar Docker es la manera más fácil y no hay ningún problema con ello, de hecho...
si quieren comenzar así, pero si entender un poquito más cómo funcionan al nivel de kernel, cómo en realidad está empaquetando diferentes, encerrando diferentes servicios y paquetes, pero cómo si yo desde un servidor que tiene...
contenedores corriendo en él. Si yo listo los procesos en el servidor en sí, yo voy a ver los procesos de todos los contenedores que están corriendo. Me van a aparecer, perdón, como si fueran servicios locales corriendo en el servidor, porque al final eso está al nivel del kernel. Pero si corro los servicios dentro de un contenedor, solo voy a ver lo que en ese contenedor se está ejecutando, que no debería ser más de uno o dos servicios que estén corriendo. Pero entonces, de nuevo.
Juan (43:40)
te odio.
Douglas (43:43)
Comenzar con Docker me parece perfecto, muy bien. Y no es que tienen que conocer todos los detalles técnicos a nivel de kernel, cómo funciona, pero sí entender de esa manera general quién realmente es un contenedor, qué usuario están corriendo, cómo poder asegurar los diferentes procesos que están corriendo para que tal vez alguien, gana acceso a un contenedor, no vaya a ganar acceso privilegiado dentro del sistema y cosas como esas.
Juan (44:08)
Excelente, Bien.
Los otros dos puntos, te los adelanto de un solo. Creo que sería necesario también ir profundizando o ir investigando sobre lo que son los diferentes proveedores de las diferentes plataformas que existen hoy en día. Y también pues ir profundizando en cómo es el ciclo de vida de la aplicación que vayamos a manejar. Como los proveedores me refiero a AWS, Azure,
Google Cloud y cualquier otro que exista por ahí, esos tres son los que veo siempre, entonces son los que toman relevancia y obviamente por encima siempre está AWS, todo el mundo está en AWS. A nivel de oferta y demanda pues es la apuesta más segura, aprender sobre AWS, no es la única, existen otras. Entonces yo creo que tal vez esa sería algo
que necesitaríamos aprender los desarrolladores para poder manejar estas aplicaciones y los sistemas que vayamos a manejar dentro de una empresa. ¿O crees que sería necesario o crees que no tengan tanta relevancia al final del día?
Douglas (45:32)
No, hecho yo los incluiría, Por supuesto, lo único es que yo agregaría uno antes. En la parte de antes de entrar a proveedores de nube, yo agregaría conocimientos generalizados de virtualización y de networking, de redes. Porque recordemos que la nube...
Juan (45:40)
Ok.
Douglas (45:55)
pues sí son servidores físicos reales. No vamos a ser nosotros quienes se encargan de estar administrando el servidor físico como tal y tenerle que cambiar discos duros al servidor físico o montar nuevos servidores y conectarlos a la red y al poder, pero al final del día son servidores reales.
Juan (46:14)
si en vez de ir y
sacar el disco duro yo voy y digo ahora quiero uno de mayor potencia de mayor capacidad y le doy un botón ahí
Douglas (46:22)
Y aún
dentro de eso vas a tener diferentes tipos de discos, verdad? Es que es un disco SSD, un disco más rápido, que son IOPS y ese tipo de conceptos que vienen de conocer un poco de cómo funciona el hardware en general, cómo funciona la virtualización de manera general en un servidor, porque aquí estamos hablando de una capa diferente, no son contenedores, sino que la virtualización es crear máquinas virtuales.
Juan (46:25)
Sí, sí.
Douglas (46:50)
y ahí sí corren de manera separada dentro del sistema operativo, cómo se conectan a disco duro y ese tipo de cosas. Y también los conceptos de networking son sumamente importantes porque entender que es una red...
Juan (46:53)
Mm-hmm.
Douglas (47:08)
que son las villains, que normalmente, por ejemplo, dentro de AWS se conocen como subnet, cómo interactúan unas con otras, cómo hay redes privadas, cómo hay redes públicas. El routing, importantísimo, cómo se rutea las conexiones entre diferentes villains, porque tenemos equipos que tienen diferentes rangos de IPs y aún así pueden interactuar unos con otros de manera segura, que son los firewalls.
cómo protegen o cómo liberan acceso, cosas como lo que son un NAT, que es Network AdWords Translation, convertir una IP privada a un rango de IP pública y de manera general cómo funcionan ese tipo de cosas. Entonces, yo menciono esto, Juan, porque normalmente, de nuevo, se vende la idea. En tanto tiempo aprendes AWS o en tanto tiempo aprendes Azure.
Juan (47:40)
Sí.
Douglas (48:01)
En realidad estos conceptos tienen que venir agregados a esto para poder entenderlo. Es como para ser un programador eficiente y si quiero desarrollar cosas en blockchain o con una complejidad más elevada necesito saber de algoritmos y de diferentes técnicas para poder desarrollarlo y entenderlo. Lo mismo aplica acá.
Entonces conceptos de virtualización general y conceptos de networking son importantes porque aún más allá de eso, una vez que maneje eso, ya mencionamos contenedores, luego nos va tocar en la nube.
trabajar con administrador de contenedores. Se nos agregan más otras cosas. Se nos van a agregar load balancers, API getways, se nos van a agregar servicios de mensajería, de colas, y dependiendo que estamos construyendo hay una infinidad de servicios dentro de la nube. Entonces, sin estos conceptos básicos...
no lo vamos a lograr captar. Nos va a parecer fácil entrar al dashboard de EasyTube y levantar una instancia y decir, esto no es tan complicado. Pero realmente, arquitectar soluciones complejas, aparte de saber ahorrar costos en la nube, porque la nube es bien cara, ¿cómo lo hago con la menor cantidad de recursos posibles, siempre siendo óptimo? Y empezar a sumar todas esas cosas, y realmente sí es complejo. Y la gente se termina desanimando cuando llega...
Juan (49:23)
Sí.
Douglas (49:34)
a este tipo de retos, cuando el reto implica entender más de networking o cuando el reto implica entender más de sistemas operativos y cuando me refiero a esto, me refiero a programadores, de nuevo que los he visto, conozco a dos, que pasaron de programadores a la parte de infraestructura, verdad, y los dos que conozco, los dos recuerdo que venían a mí al principio cuando tenían este tipo de retos, entonces yo le agregaría esa parte Juan, para mí es vital.
Ese es un no negociable entender lo básico de virtualización y de redes.
Juan (50:08)
O sea que...
como para ir resumiendo, o sea, no para ir resumiendo, lo que voy captando de tus consejos Douglas, es que lo importante entonces es ir entendiendo todos estos conceptos, incluso a nivel de un servidor físico, por decirlo así. Y ya cuando tenemos estos conceptos de redes, el sistema operativo, cómo funcionan, cómo se interconectan, eso luego lo podríamos ir
trasladando a cualquier una de estos diferentes proveedores que existen ya sea Azure, AWS o Google, Google Cloud porque en sí estos conceptos no van a cambiar lo que va a cambiar es la manera en que se configuran en estas otras, en estas plataformas que ellos tienen verdad porque la IP pública, la IP privada y la bilans eso se mantiene lo que cambia es como el dashboard que te presenta cada uno de ellos
Douglas (51:06)
Sí, de alguna
manera. De alguna manera. La parte aquí, Juan, es de que este tipo de principios y conceptos nos llevan... Porque conceptualmente la nube es lo mismo. Aunque se administre diferente, aunque se administre completamente diferente, y aunque yo no necesariamente tenga que ir a crear una red dentro de la nube, el concepto de red...
El concepto de networking es el mismo, no importa donde estés. Ese concepto está aplicado ahorita en la casa de cualquier persona que nos está viendo escuchando que su celular o su laptop está conectada al wifi. Ese wifi está creando una red local. Ese está creando a tu celular, a tu laptop, a tu televisor, a tu bombillo inteligente. Él está signando una IP y está creando una red interna.
Juan (51:35)
Sí.
Douglas (51:58)
el router en tu casa y el del router de tu casa hacia el proveedor de internet se está creando una red one se está conectando a una red abierta que interactúa con tu proveedor de internet entonces explico esto porque los conceptos de redes son los mismos no importa como yo interactúe con ellos dependiendo del escenario en el que estoy entonces en la nube no van a cambiar
Juan (52:19)
Sí.
Douglas (52:22)
sino que se van a hacer como más complejos tal vez porque me va a tocar interactuar mucho más con ellos mayor responsabilidad entonces es ahí donde tiene sentido hacerlo alguien puede decirme yo no aprendido todo eso ya estoy haciendo cosas en la nube no está bien pero a medida entre a la complejidad te va tocar ir dando pasos atrás
Juan (52:28)
mayor responsabilidad.
Douglas (52:45)
Si querías arquitectar soluciones completas, va a tocar dar pasos atrás para poder ver y entender que son estas cosas para luego implementarlas. Mucha gente comienza, como se dice, de atrás para adelante. Se van al final, hacen un par de cositas, pero al toparse con el reto, toca ir retrocediendo. Si comenzamos del principio, que son estos conceptos...
cuando ya entremos a la carnita, a lo complejo, ni cuenta nos vamos a dar cuando lo estemos solventando porque esos conceptos van a ser simples para nosotros.
Juan (53:21)
cierto, si muy cierto. Ok, networking muy importante, bueno iba a hablar sobre el ciclo de vida de una aplicación pero creo que va ligado con lo que nos estabas contando al inicio sobre cambiar nuestra mentalidad a...
a una mentalidad DevOps porque ahí es vamos a empezar a tener en cuenta esto, Cómo es el flujo de nuestra aplicación y cómo lo podemos arquitectar, Y cómo irla optimizando, mejorando y haciéndolo de manera que sea eficiente.
Douglas (54:01)
Sí, en ese sentido, Juan, y para agregar rapidito, yo creo que el programador
sí la tiene fácil o sí tiene corto porque está acostumbrado a trabajar en los diferentes ambientes que incluyen el ciclo de vida de desarrollo, que tal vez publicara staging, un ambiente de prueba local, ambientes de pre-producción y...
están de alguna manera ligados a entender que cuando hacen algo se empaqueta y se publica. por esa parte, yo esperaría que un programador estés a un 10 % de llegar a lo mínimo requerido o tal vez muy cerca y que le sería fácil entenderlo porque su rol ya es parte del ciclo de vida de las aplicaciones. Y de acuerdo, es necesario entenderlo muy bien.
y sería de los bases para estar en lo que es un rol de SRE.
Juan (54:52)
si creo que también hay ciertos puntos positivos cuando pasas de desarrollador a sri y ese es uno de ellos ya conoces como funciona cual es el ciclo de la aplicación vas a conocer un poco mejor probablemente cuáles son los requerimientos que debe tener ciertas aplicaciones en diferentes ambientes deberías conocerlo al menos como configurar ya sean los variables de entorno ese tipo de cosas que
cuando te toque configurar aplicaciones de otras personas pues ya no vas a estar tan perdido probablemente eso es lo que debería suceder
Douglas (55:32)
Y de hecho,
tal vez si alguien está considerando, un desarrollador está considerando cambiar su rollo a esto de SRE y no entiende bien el ciclo de vida de las aplicaciones, yo creo que esa es su métrica para saber que no está listo para empezar a transicionar. Ya hemos dado un par de métricas que les puede servir y de nuevo, no estamos diciendo una métrica para que no transicione. Es una métrica de que no está listo.
Juan (55:57)
Hay que mejorar.
Douglas (55:58)
y que mejor, correcto, que comience mejorando esas áreas desde su rol, que desde su rol las puede mejorar perfectamente y de hecho es mejor que las comience mejorando desde su rol porque le va a ser más fácil entenderlo y luego de eso que busque transicionar.
Juan (56:04)
Jajaja
Excelente, excelente. Ok, mencionabas algo muy importante, hecho de cómo...
conocer los conceptos básicos de networking, sistemas operativos, cómo funciona Docker. Entonces, ¿cómo ponemos en prueba eso? Yo creo que hay dos formas, Douglas. La primera es por nuestra cuenta. En mi casa yo puedo montar diferentes servidores, sea virtuales o computadoras que tengo ahí, tal vez que no, son computadoras viejas, puedo reutilizar. Y la otra forma puede ser de
el trabajo es en el área de trabajo, ¿no? dependiendo de la empresa nos pueden dar como acceso no a tocar la configuración que existe pero sí podemos tal vez acercarnos a nuestros compañeros para que nos expliquen algo y por ejemplo como desarrollador es importante que cuando estamos haciendo un deployment o estamos configurando una aplicación podemos acercarnos
al departamento de SRE y no solamente decirles bueno se hace así también ver cómo lo están haciendo ellos podemos ir y curiosear un poco claro depende de la empresa no dependiendo las políticas que tengan pero esa es una buena forma porque en nuestra casa podemos hacerlo a nuestra manera pero en la empresa podemos ver cómo se hace realmente a un nivel más profesional empresarial
Douglas (57:38)
Mhmm.
Juan (57:54)
que podemos hacer y cada una de ellas tiene sus pro y sus contras definitivamente. Yo recuerdo mucho acercarme a vos cuando teníamos que configurar ciertas aplicaciones y me mostraba cómo se hacía de tu lado que de cierta manera podríamos decir que eso no era de mi incumbencia pero para mí era muy importante y sí le encontraba mucho valor en la
el entender como la aplicación que yo estaba desarrollando, como se iba a ejecutar en el servidor y que cosas tenías que configurar, que cosas tenías que ver y prestarle atención para saber si estaba bien o si estaba mal. Eso me ayudaba a mí a poder desarrollar mejor la aplicación. Así que, bueno, yo daía ese consejo, el hecho de ser un poco más curiosos en los otros departamentos y acercarnos.
que seguro que que un compañero en sri le hacemos una pregunta nos va a contestar y nos va a explicar lo que le estemos diciendo al menos que sean un poco egoístas pero pero no no creo yo que eso pase
Douglas (59:08)
A veces ocurre, pero ya depende
de la cultura que está en una empresa. Fíjate que estoy tan de acuerdo con vos, en esta parte que yo pondría ambos combinados como la mejor estrategia probablemente para comenzar a transicionar. Yo recuerdo, yo cuando aprendí a manejar, a mí me enseñó a manejar a mi papá los carros estándar o los carros mecánicos como se conocen aquí en Latinoamérica.
y sin ánimo de ofender a nadie, por si alguien joven que nos ve y nos escucha no sabe que es un carro mecánico, todavía existen por supuesto, pero antes eran común y era lo único que había, un carro que tiene un tercer pedal y ese tercer pedal se usa para manejar la palanca de cambios y había que estar uno manualmente haciendo los cambios, primera, segunda, tercera.
etcétera. Entonces estaba muy pequeño yo, muy pequeño era un niño cuando mi papá me preguntó ¿quieres aprender a manejar? y yo le dije sí por supuesto, yo estaba emocionado y él lo que me dijo fue observame hacerlo. Esa fue su respuesta, yo tenía que tal vez nueve años.
No estaba listo todavía para agarrar un vehículo. Y entonces él me dijo, observame. yo, podía observarlo. Acabando él manejaba viendo absolutamente todo lo que él hacía. Tratando de encontrarle sentido y de solo ver, Juan, comenzás como a captar cosas. Después de un tiempo ya comenzás a hacer preguntas puntuales. Y por eso estoy agarrando este ejemplo.
Juan (1:00:35)
Sí.
Douglas (1:00:42)
que yo no sabía que iba a tocar ese tema, pero para mí este ejemplo encaja perfecto, yo lo he tomado para estas otras áreas en mi vida, comenzaba a preguntar cosas puntuales, yo miro que mueve la palanca, le decía yo, en estas direcciones, en este sentido, entonces ya comienza a preguntar él, ay miraba y que presiona el pedal del fondo cuando mueve la palanca, ya me explicó él, sí, miraba, aquí está el primera, segunda, tercera.
Juan (1:00:59)
explicar.
Douglas (1:01:09)
cuarta, quinta y aquí retroceso y él me explicó y seguía viendo yo y luego le hacía una pregunta de otra cosa y me respondía a medida pasaba el tiempo luego entra mira qué interesante a preguntas más profundas ahora de las velocidades
Yo le decía, y las velocidades van en cualquier orden, ¿cómo sé cuándo tengo que cambiar velocidad? Ya me decía él, mira, las primeras son cambios que tienen más fuerza para que el carro tenga potencia. Y, ⁓ ¿cómo sé cuándo será el cambio? Y me decía él, ⁓ el carro te lo va a pedir. Y ahí terminaba esa conversación y yo quedaba, ¿el carro me lo va a pedir? O sea...
Juan (1:01:35)
Sí.
Sí,
Douglas (1:01:43)
me va hablar, me va decir. Y ya luego
de estar observando, porque como yo voy enriqueciendo mi conocimiento, voy prestando la atención a más cosas y en eso empiezo a escuchar el motor. Y darme cuenta que cuando el motor estaba como ya ahogándose...
mi papá hacia el siguiente cambio y ya le decía yo, o sea esto cada plática de estas que te digo pasaban mínimo tres cuatro semanas en realidad pasaban como dos meses y ya le decía cuando usted dice que el carro pide el cambio es ahí verdad cuando se escucha como como profundo ya me explicaba si miraba es que es que ya con este cambio ya no le da la suficiente potencia o velocidad el motor se empieza a esforzar mucho ahí se le da el otro cambio entonces usando esa analogía Juan
Juan (1:02:07)
Sí.
Douglas (1:02:28)
cuando vos en un...
Juan (1:02:28)
Sí, me causa mucha
gracia porque sí, yo también tuve una experiencia similar con los carros, como lo estás contando. Sí, sí,
Douglas (1:02:35)
también mira bueno mira qué interesante
pero si vos usas esa analogía y aplicarla a tu rol y perdón al rol que quieres aprender o a la tecnología que quieres aprender y comenzado observando lo que hacen comenzó observando comenzar leyendo un poco por tu cuenta y tanto internet
Juan (1:02:44)
Mm-hmm.
Douglas (1:02:53)
aprende los conceptos necesarios y luego te vas si vos bajas el otro SRE en este caso estamos poniendo el ejemplo para transicionar de developer a SRE pero aplica para cualquier parte en tecnología pero si vos bajas al que sabe en la empresa y le decís hey yo miro que cuando vas a hacerlo despliegue a producción haces esto esto y esto pero aquí fíjate que no entendí bien para qué haces tal cosa y como es una pregunta puntual él no tiene que comenzar a explicarte nada desde el principio él te va a responder
y continúa, ah, ok, así es que bueno, y vos quedaste todavía con más dudas, seguí observando, por tu cuenta entendés un poquito más entre lo que investigas, lees, y vas y haces otra pregunta puntual. Y así vas adquiriendo, y es muy importante esta parte de la curiosidad y aprender con curiosidad en tu trabajo, y es porque esa es la parte donde aprendés con conceptos que están puestos en producción.
con flujos de trabajo que están sirviéndole a equipos enteros de desarrollo, PMs y otra gente de sistemas. Ahí es lo estás haciendo en la vida real, por así decirlo. Y eso lo combinás que te vas a tu casa, lo que vos dijiste, y en una laptop vieja, en una computadora vieja, o tal vez compras una máquina dedicada, o en tu misma laptop instalas una VM y empezás a probar estas cosas.
Estas mismas pruebas que estás haciendo te van a generar esas preguntas que luego vas a ir a hacer. Cuando menos te des cuenta, ya tenés el nivel suficiente para tal vez agarrar un curso más dedicado y más avanzado porque lo vas a entender. Cuando menos te des cuenta, algo que han hecho otros desarrolladores con los que yo trabajo, es que de repente me mandan un PR, un pull request.
Juan (1:04:27)
Sí.
Douglas (1:04:39)
con mejoras al pipeline, el pipeline que tal vez yo manejo y administro y ellos me mandaron el PR y fíjate que y antes de eso me decían preguntas, fíjate de repente me llega el PR, he recibido PR de algunos programadores con mejoras a Ansible que está administrando cosas porque yo quería aumentar la memoria y me mandaban el PR, fíjate que quiero subir, si está incorrecto me decís y descartarlo y creamos un ticket, si no revisar y lo aplicas, entonces usando este tipo, este método
lo estás diciendo, lo comparto tanto, que en mi opinión, la combinación de ambos es sin duda alguna la mejor forma de hacerlo y ningún ingeniero SRE, ningún ingeniero que está en el área de sistemas le va a molestar trabajar con un desarrollador, con un ingeniero web.
que tenga ese hambre de mejorar porque está siendo tu mejor aliado y hasta te está mandando pull requests o cuando vos le decís a él que querés aplicar mejoras a tus sistemas él está emocionado y está bordo y es el primero que empuja a tu favor porque él quiere ser parte de ese proceso de implementar esto nuevo. por ahí iría en mi opinión la mejor forma de hacerlo.
Juan (1:05:54)
Sí.
y que también es necesario saber cómo llegarle a las personas, creo yo.
con lo que mencionabas del PR donde te dicen esto es lo que yo quiero hacer pero echarle un ojo y darle tu punto de vista creo que es una forma muy digamos humilde de sin imponer, sin tratar de verse como mira yo te arreglo el trabajo porque se puede ver así dependiendo como decías de la cultura de cada empresa puede pasar también pasa a veces Douglas que hay personas que
ya es su personalidad que son un poco más gruñones o tal vez no gruñones pero no son así de que te van a estar explicando del pie de la letra todo es necesario que hay que saber cómo llegarle si ya sé que esta persona es un solo me va a contestar con un sí o con uno pues hay que saber cómo logro sacarle la información porque de nuevo el interesado soy yo él ya sabe y ya está haciendo lo que tiene que hacer
Douglas (1:07:01)
Sí, sí.
Juan (1:07:04)
y esa es su personalidad entonces ya recae en mí saber cómo interactuar con esta persona, cómo ganarme su confianza para que vea que no estoy solamente preguntando por preguntar sino que me interesa mejorar el proceso porque también este proceso de aprendizaje si bien estamos diciendo que te va servir para
para poder cambiar de rol, mientras estás cambiando también nos va a servir para hacer aplicaciones de mejor calidad. también ya al entender cómo funciona en el servidor, ya al entender cuáles son las limitaciones, probablemente podamos hacer cambios teniendo estas cosas en mente. Porque a veces puede pasar, a mí me pasó y creo que ya lo había mencionado, que yo en cierto momento quería que varios servicios
con diferentes replicas se conectaran a una instancia de SQLite pero yo no entendía como funcionaba todo ya en el servidor entonces ya hablé de hecho con tu hermano hablé y ya él me explicó no es que sólo está en un lado no los demás no se pueden conectar entonces ok ya me tocó entonces cambiar lo que estaba haciendo era en aquel entonces cuando estábamos empezando ahí ⁓
Entonces
es ventaja por todos lados desde mi punto de vista. hecho de aprender de las personas que ya saben, aprender de un ambiente que ya está utilizando estas soluciones y nos ayuda en nuestro trabajo actual y probablemente en un trabajo futuro en este nuevo rol que nos interesa. que sí, definitivamente es muy importante. las cosas que podemos hacer en casa son muy...
Douglas (1:08:47)
Sí.
Juan (1:08:57)
y son muy grandes Yo actualmente, yo le comentaba fuera de cámaras a Douglas que estoy muy enviciado con el tema de Home-Laving y configurar todo lo que es mi red local, diferentes servidores que tengo por allá arriba y definitivamente eso nos expone a otros conceptos que si bien los he escuchado no he profundizado en mi área de trabajo porque
en mi área de trabajo tengo que hacer un microservicio con Go y listo, estoy simplificando pero es así. Entonces al tratar de hacer soluciones en nuestra casa con algo simple empecemos, tener nuestra casa con una VLAN segura y una VLAN para invitados con eso ya vamos a empezar a exponernos a diferentes conceptos que como mencionaba Douglas al inicio, networking, manejar el servidor
manejar diferentes sistemas operativos, ¿no? Como yo puedo configurar mi servidor de archivos en Linux y lo puedo acceder desde Windows. es algo que es muy simple en teoría, pero hay que saberlo hacer. Así que sí, definitivamente, esas dos formas de practicar serían las ideales, ¿no Douglas? Ponerlo en práctica en nuestra casa y ir preguntando a los expertos en nuestro trabajo. También,
Yo estaba dando el ejemplo de ir físicamente, pero si estamos trabajando en remoto, si ya tenés la fortuna de trabajar en remoto, también se puede hacer durante las llamadas o un chat, un mensaje ahí cortito se puede hacer. Y yo creo que tal vez ahí sea incluso más fácil que nos contesten porque en un chat ahí lo revisan en cualquier momento.
Douglas (1:10:49)
Sí, exacto. De hecho, estos ingenieros que te he dicho yo que me han venido con preguntas y que luego han terminado mandándome pull requests, me escriben en chat y me dicen, mira, ve, fuera de tópico, dicen. Tenía dudas de cómo se hace esto, esto y esto. Y ahí hay preguntas relativas a los sistemas.
Juan (1:11:04)
jaja
Douglas (1:11:10)
ves que manejamos de manera conjunta, el código y yo la parte de infraestructura, pero yo tenía esta pregunta de cómo se maneja esto, esto y esto, entonces te dejo el mensaje aquí, me dice y sentiste la libertad de contestar cuando sea que tengas tiempo, aunque sea otro día y por supuesto uno a veces responde inmediatamente o respondes minutos luego, nadie responde días después, pero justo lo que estás diciendo.
Juan (1:11:28)
Sí.
Douglas (1:11:35)
la colaboración es más fácil porque permite eso si presencial a veces tenés que decir, tenés un minuto y tal vez no tiene el tiempo disponible cuando le dejas el mensaje en el chat en algún momento
Juan (1:11:42)
Sí.
Exacto, exacto. Ok, bueno.
Entonces, como una recapitulación Douglas, hemos hablado sobre qué es necesario entonces para un developer hay que cambiar de mentalidad y hay que tratar de ver el sistema en su totalidad, ver cómo es el ciclo de vida, que eso en teoría ya lo manejamos, pero también abarcar un poco más de lo que es la arquitectura necesaria para que nuestro sistema sea utilizado por los usuarios.
También
mencionamos lo que son los sistemas operativos, networking, contenedores y los diferentes servicios que existen como AWS y Azure. Por último, al menos de mi parte Douglas, yo creo que otro cambio en la mentalidad necesaria para poder...
trabajar en este rol es el hecho de ser un poco más colaborativo. dependiendo de la empresa, los desarrolladores a veces, dependiendo incluso también de qué tan seccionado esté y qué tan grande sea el equipo de trabajo, los desarrolladores tienden a veces a ser un poco más retraídos y se enfocan en su trabajo y listo, ¿no? No, no...
hablan tanto en las llamadas, en las reuniones y sabes, ¿no? El típico programador que se encarga de su trabajo y listo. En el rol de SRE, bueno, ya nos explicó Douglas que sí nos tocaría hablar con más personas y a veces incluso hasta más complicado porque tenemos que explicar cosas técnicas de la manera que se acople a la persona en la que estamos.
explicándole. Así que creo que hay que ser más colaborativos para poder trabajar en este rol que como decía Dulas hay que ingeniárselas en muchas cosas. Así que te toca contactar a la persona de al front end developer, al back end developer, al...
administrador de base de datos, al PM, te toca hablar con todos. Creo que lo que estaba hablando yo al inicio de hablar menos, creo que está totalmente invalidado. Te toca hablar con todo el Así que hay que ser más colaborativos en este rol.
Douglas (1:14:28)
Sí, mira, definitivo y quiero aclarar de que yo puse la parte de tener mentalidad de ingeniero más sí como una mentalidad, pero también yo lo incluyo en la parte técnica porque si no tengo el conocimiento técnico, para diseñar una solución, la mentalidad es bueno que ya la tenga, ¿verdad? Es bueno que ya vaya...
Juan (1:14:53)
La actitud.
Douglas (1:14:54)
de
tener la actitud, pero no tengo la capacidad aún. Realmente toparte con la experiencia de comenzar a diseñar soluciones, a ingeniar soluciones, es diferente a solamente tener la intención, porque vas viendo cómo entendés tecnología, cómo entendés protocolos, cómo entendés servicios, cómo entendés el lado del cliente, etcétera. esa es la razón por la cual tener la mentalidad de ingeniería, si bien es cierto, es un cambio de mentalidad.
lo puse ahí ponerle mitad y mitad con la parte técnica. Ya en los cambios de mentalidad definitivamente la colaboración es importante porque en la parte de infraestructura se vuelve como ese punto medio de todo, casi. Abajo de infraestructura suele estar redes que ahora en la nube mayormente los mismos profesionales lo manejan.
Juan (1:15:24)
Sí.
Douglas (1:15:49)
que antes en data centers suele ser equipos diferentes, pero infraestructura está en medio de la parte de redes y la parte del poder de los data centers incluso, y también está abajo de lo que es la aplicación corriendo. Entonces eso hace que toque interactuar con todo y como mencionaba al principio.
ver incluso métricas de la aplicación en sí para ver que está funcionando de manera óptima y ahí incluso hasta entender el negocio es requerido que un programador debería entender el negocio también pero hay muchos puestos en la parte de SRE donde se vuelve inevitable entender el negocio para saber si una métrica es un problema esto ha sido una métrica que un formulario está teniendo un montón de request
si entiendo el negocio voy a saber si es un problema o no. Tal vez haya una promoción y por eso están llenando el formulario y esa es la parte de negocio. Yo voy a venir y saber, ⁓ no, no pasa nada porque hoy lanzan la promoción y esa promoción dura tres días más. Mientras no llegue a tanto no te preocupes por eso. Entonces ahí está la parte de negocio y ahí está la parte de interactuar. Entonces yo estaría muy de acuerdo con vos. Y si me dejas agregar una más, Juan.
Juan (1:17:09)
Claro, claro.
Douglas (1:17:10)
Yo agregaría también, en cambio de mentalidad, este va a sonar raro, pero es cierto, prepárate para que te culpen por todo. Es una mentalidad de tomar las cosas con calma, es lo que quiero decir, porque en realidad se suele apuntar hacia la parte de infraestructura primero al momento de haber un inconveniente.
¿Por qué? Porque el... y analicémoslo de esta manera. El desarrollo de las aplicaciones comenzó que el programador probó su código en su local y luego actualizó el ticket y lo subió a un ambiente de staging donde probaron dos personas más y luego lo mandó a pre-producción donde probó a alguien de QA y probó el project manager y se ve bien. como han venido probando y se manda a producción...
combinado con otras pruebas, todo mundo está convencido de que eso va a funcionar bien sí o sí. Entonces al momento de que falla, única persona que no estuvo involucrada...
probando cosas fue el SRI o fue el de sistema. Entonces van a, se van ahí y te comienzan a preguntar, pero cambiaste la variable de entorno tal que te decía en el ticket. ⁓ pero reseteaste, limpiaste el cache como decían y comienzan a preguntarte casi con un tono atacándote diciendo esto está fallando porque vos hiciste algo malo. Ajá.
Juan (1:18:24)
Sí.
No,
Pero sí lo cambiaste.
Douglas (1:18:42)
Y a veces toca enviar pruebas, enviar el output de algo o cuando ejecutaste el pipeline, el resultado, etc. Pero es importante que en ese momento no tengamos una mentalidad de contienda porque entonces se vuelve un pleito innecesario. Comprendamos de nuevo, por eso di el flujo.
Juan (1:18:46)
evidencia.
Douglas (1:19:06)
entendamos por qué usualmente la gente se va a culpar al lado de sistemas, Porque ellos han venido probando y en su locales funciona y piensan que ya en los contenedores, en Kubernetes, en producción se va a comportar de la misma manera, donde tal vez los servicios están corriendo en diferentes regiones o en diferentes data centers dentro de la misma región. Entonces tengamos esa mentalidad de explicar lo que hicimos.
Juan (1:19:13)
Sí.
Douglas (1:19:30)
tomémoslo con calma, no lo tomemos personal y combinado con lo que vos dijiste de colaboración, ofrezcamos soluciones, entendamos no, mírense, hizo esto, esto y esto. Cuando encontremos que el problema fue en código, un problema que se pasó por alto durante el testing,
porque por hacer una métrica así al aire, 8 de 10 casos suele ser ese el problema, verdad. Entonces también lleguemos con gracia, aunque a nosotros nos hayan atacado, lleguemos con gracia. Esto va a hacer que eventualidades futuras nos vayan tomando con más tranquilidad y ya no lleguen de un solo atacar. Más bien la gente llega con precaución porque dicen,
las últimas veces que fui atacando a Douglas, él presentó evidencia y terminó de mi lado el problema. Entonces, a lo lo voy llevar quedito para que si el problema está de mi lado, lo podamos resolver rápido. Entonces, ese cambio de mentalidad yo le sugeriría, sí pasa. La cultura DevOps ha evolucionado bastante y se ha quitado mucho esa parte de buscar un culpable para estarlo señalando. Sin embargo, la naturaleza humana
Juan (1:20:19)
No,
Sí.
Douglas (1:20:41)
como tal busca culpables. Entonces, estemos preparados para ello.
Juan (1:20:46)
Pero eso me parece muy... y si es cierto, se suele culpar al...
SRE, DevOps in In, como se le diga, la empresa en la que están. Pero yo en lo personal lo veo al contrario. A menos que sea una aplicación totalmente nueva, sí pudiera yo creer que es un error de lado de SRE. Pero de lo contrario, si antes funcionaba y al introducir un nuevo feature ya no funciona, lo más probable es que sea un error de desarrollo.
Yo así lo veo, no suelo pensar que es un error de desarrollo de sistemas porque si todo ha estado bien hasta este punto, ¿qué es lo diferente? Pero sí, a veces se suele buscar otro tipo de culpables.
Douglas (1:21:39)
Pero que sabes qué pasa ahí Juan y
mira qué interesante, vos estás marcando un punto donde como vos estás codificando y estás viendo eso, vos sos un profesional que tiene esta mentalidad más senior y más de arquitecto que puede comprender eso. Segundo, segundo, cuando llega un PM, cuando llega un Account Manager, cuando llega un gerente, un cliente y te quiere culpar, estás como más acostumbrado porque vos sabes, yo toqué el código.
yo hice el código, yo lo toqué. Pero cuando el PM o cuando estos stakeholders llegan primero al SRE y te están culpando algo donde no tocaste el código, lo más probable es que fue un sistema automatizado que lleva año y medio corriendo sin tu intervención y de la nada me vienen a culpar a mí. Eso se vuelve frustrante.
Juan (1:22:32)
Exacto.
Sí.
Douglas (1:22:34)
Entonces hay
una diferencia, aunque vos sepas que no fuiste vos, ponen un escenario así, o sintas que que raro que está de tu lado porque se probó bien, se probó bien y que raro que en producción no funcionó.
como que sentís aceptable hasta cierto punto que quiera culpar de tu lado. Pero de nuevo, pensá en que normalmente en la parte de esa REAP no estamos involucrados en el día a día como tal de estar del código, en el día a día como tal de código. Entonces es ahí donde mentalmente si nos agarran cansados, estresados, se puede crear una contienda porque te parece ilógico siquiera que hayan venido a mí. Entonces ahí donde tal vez creo yo que existe
Juan (1:23:03)
Uh-huh.
Sí.
Douglas (1:23:17)
una diferencia en cómo se puede tomar.
Juan (1:23:20)
que a veces llegan incluso y te dicen, pero es que no hiciste tal cosa y es como, ni siquiera sé de qué hace tu aplicación, entonces como esperas que la configure, algo nuevo, ¿no?
Douglas (1:23:33)
No, es que fíjate que la mayoría de las
veces también, Juan, a veces publicás y por la siguiente hora funciona bien. muchas veces es, y mira, esto pasa tantas veces, el mensaje que vas a decir por Slag es, ¿qué tocaste?
O sea, ¿qué tocaste? Y mucha gente tal vez no entendió de que tal vez por este lado fue al contrario. La aplicación estuvo funcionando bien porque hay caching al nivel del Edge y luego caching en Redis o en otro layer. Y luego, ya cuando todo eso caching expiró, al tu nuevo código.
y tal vez a él fue que le faltó decir que limpiáramos el catching para verlo. Pero entonces, a veces recién publicás, está bien, a los minutos a la hora falla y recibí ese mensaje. ¿Qué tocaste? O sea, como que si yo por hobby me pongo a estar tocando producción, entonces sí.
Juan (1:24:13)
Sí.
A ver qué pasa si quito
esto.
Douglas (1:24:26)
Exacto, voy a matar estos pods a ver qué sale. Entonces, ahí hay que tomarlo con calma porque se puede volver frustrante a mí. Yo tuve incidentes cuando era más joven, pero he aprendido que cuando lo llevas con calma, luego de que la persona te aprenda a conocer uno o dos incidentes, luego ya llegan hacia vos con mayor gracia.
Juan (1:24:50)
Y eso de la calma es importante, ¿no Douglas? Porque también cuando hay un problema real, cuando hay un problema crítico, ese es el departamento que también requiere tener una mente fría para poder solucionar problemas que a veces no sabemos de dónde vienen. Y claro, hay mecanismos para hacer rollback y para hacer diferentes, para que la aplicación esté siempre correcta. Pero a veces suceden problemitas.
que son bien difíciles. Recuerdo que en cierto episodio nos contabas un tema sobre una migración y para mí escuchar migración, wow, se me rizan los pelos porque los vellos del cuerpo porque realmente hablar sobre la data de los usuarios es un tema bien, bien crítico. Así que definitivamente SRE requiere que las personas tengan una mentalidad muy, muy resiliente.
Douglas (1:25:41)
Sí.
Juan (1:25:50)
para poder afrontar estos desafíos que son bien bien complejos a veces.
Douglas (1:25:56)
Sí.
Juan (1:25:58)
Por último, entonces Douglas, la verdad es que me ha encantado. Me has, ¿cómo decirlo?, me has abierto la mente a muchas cosas. Definitivamente sé que es un puesto complejo, pero sé que no es imposible tampoco. Requiere mucha dedicación y tiene muchas ventajas y recompensas. Ya lo mencionabas al inicio, ¿no? La recompensa monetaria.
puede ser muy muy favorable. Por último entonces Douglas, no sé si tuvieses alguna recomendación hoy en día a la fecha que estamos grabando hoy en 2025, alguna herramienta que consideres que deberíamos prestarle atención ya sea porque es la que todo el mundo utiliza o que tal vez sea muy nueva y que creas que sea importante.
Douglas (1:26:31)
Sí.
Juan (1:26:55)
o alguna que vos utilicés muy seguido, perdón.
Douglas (1:26:55)
Sí. Fíjate que
para la parte de SRE, sobre todo para quienes quieran estar transicionando a la inteligencia artificial en general de manera profesional, de manera responsable. ¿Por qué lo digo? Porque hoy en día te ayuda mucho.
con tu proceso de estudio y de entender estos ejemplos que dimos de cómo podés por tu cuenta estudiar cosas, investigar cosas para luego preguntarle al de sistemas cómo lo hacen ellos en la empresa.
estas preguntas hoy en día, hacérselas a la Inteligencia Artificial, es mucho más rápido que buscarlo por tu cuenta en internet. Y ya tenemos todo un episodio donde discutimos formas eficientes de hacerlo, le vas a pedir a la Inteligencia Artificial que te dé referencias y los enlaces a la documentación de donde sacó esa información como tal, pero te lleva más rápido a entenderlo, te va a resumir.
Juan (1:27:45)
Sí.
Douglas (1:28:02)
estos conceptos, todo lo que tiene que ver, que dijimos de networking, de sistemas operativos, de virtualización, te va a ayudar a resumirlos de una manera que lo puedas entender y de nuevo, si nos da los enlaces para corroborar de qué está haciendo lo que está haciendo, entonces nos va ayudar mucho y de nuevo, cuando empecemos en el rol de SRA, si nos apoyamos de la inteligencia referente...
de la inteligencia artificial de manera responsable también nos va a ayudar a avanzar. de nuevo, no es reemplazar una cosa por otra, no es reemplazar su aprendizaje, es solamente acelerar. Entonces yo diría que se le preste atención. ¿Diste el ejemplo de N2A? Por ejemplo, perdón, N8N, N8N, para decirlo en español.
Juan (1:28:44)
un apoyo.
Sí, ese nombre me enreda.
Douglas (1:28:55)
Sí, yo que antes hablaba inglés.
Pero dices el ejemplo, se vende como inteligencia artificial como tal, no es que sea inteligencia artificial, pero algunas integraciones sí lo son, y eso ha venido a revolucionar soluciones que antes se ocupaba si alguien o un programador o alguien de sistemas que lo hicieran. yo diría, presten la atención a la inteligencia artificial, se pasa por alto.
cuando se trata de infraestructura porque si vos ves Juan, vos ves en la parte de tecnología la inteligencia artificial usando como vibe coding y que puedes hacer tu propia página web con unos clics o te lo ponen alrededor de contenido en redes sociales o que te edita un video, te crea una imagen esa es la publicidad de la inteligencia artificial en muy poquitos lugares la vas a ver relacionada con la parte de infraestructura
Juan (1:29:37)
supuestamente
Douglas (1:29:51)
y sí se puede utilizar muy bien ahí. Entonces yo diría no lo dejen dormir, investiguen un poco más a profundidad, sálganse de la bulla, no que sea mala, es muy buena esa bulla ahorita en inteligencia artificial, pero sálganse de la bulla porque la bulla no incluye mucho la parte de infraestructura. Entonces esa sería la herramienta que de manera general que recomendaría prestarle atención.
Juan (1:30:15)
Excelente.
Ok, excelente. ese caso Douglas, creo que podríamos finalizar entonces el episodio. Me ha encantado los consejos que nos has dado. Definitivamente me gusta porque como mencionaba, no sé, en algún punto tal vez pueda ser colega tuyo en ese rol, ojalá. Y bueno, sin más, solo me gustaría mencionar a los que nos escuchan.
Douglas (1:30:38)
bienvenidos a día
Juan (1:30:46)
les agradecemos que lleguen hasta el final del episodio si pueden si les ha gustado el contenido denle like, compártelo, eso definitivamente nos ayudaría mucho a nosotros para seguir creciendo y seguir llegando un poco más a las personas que probablemente les interese este, estas pláticas que estamos teniendo nosotros así que sin nada más que agregar dublas un gusto y nos vemos a la próxima
Douglas (1:31:11)
un gusto, bye.