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 una vez que esta cultura se empieza a...
a implementar, a poner en práctica como que la industria se fue dando cuenta de que los nombres de estos diferentes puestos tenían que ajustarse para acomodarse un poco más a las funciones que comenzaban a realizar, ¿verdad?
esta misma evolución creó nuevas funcionalidades, nuevos requerimientos para estos puestos de trabajo y entonces, por ende, se hicieron cambios a los nombres para que reflejaran eso. Ya, esta persona ya no solo era un server admin, porque ya no solo administraba servidores únicamente, o solo un sysadmin porque no se encargaba de la configuración de un sistema o de algunos cuantos sistemas en específico, ya era un puesto que requería más colaboración, más automatización.
incluso, entonces eso fue lo que comenzó a crear esa necesidad de cambio de nombres para que se entienda cuando damos el nombre de nuestro puesto de trabajo o a qué rol queremos aplicar, que se sobreentienda que, cuáles son las funciones,
sean bienvenidos a un episodio más de Dev & Ops, este espacio en el cual hablamos de tecnología, desarrollo, DevOps y su cultura en general. En esta ocasión, lamentablemente, me encuentro por mi cuenta ya que mi amigo y co-host, Juan Ramos, se encuentra incapacitado por motivo de salud, aprovechando hacer la aclaración de que no es nada grave. Juan se encuentra descansando en su casa, pero su médico le hizo ⁓
la recomendación y sugerencia de que descanse, lo cual él decidió acatar, la salud ante todo, ¿verdad?
Por otro esto de la creación de contenido, al igual que el entretenimiento, pues no descansa y tiene como lema el show debe continuar. Tanto Juan como mi persona tomamos la decisión de que yo pudiera tomar cartas en el asunto y guiar este episodio con un tema en el cual desde mi perspectiva y desde mi experiencia pueda abordar algo el cual pueda traerle beneficio y valor a todos ustedes. Y es así que hemos decidido
viendo muchas dudas que encontramos por ahí en el internet y mucha confusión alrededor de los puestos y de los títulos que se le dan a los diferentes puestos en el área de operaciones, en el área de sistemas. Y pues hoy hemos decidido abordar esa parte y tal vez tratar de traer un poco de claridad a todos los que quieren comenzar en esta parte de lo que es la tecnología, la diferencia entre SRE a Cloud Engine.
platform engineer y DevOps engineer. Entonces, como siempre, nos gusta hacer aclaraciones que tratamos siempre de hablar desde nuestra experiencia, nuestra perspectiva a lo largo de los años en lo que es la parte de IT en general, en esta ocasión de mi persona hacia ustedes, hablando de mi experiencia, la evolución que yo mismo he tenido dentro de IT y mi experiencia.
a lo largo de estos diferentes roles, como se le llama hoy en día. voy a mencionar un poco sobre la descripción de qué es cada uno de estos roles, tal vez en qué partes se diferencian, pero más allá, eso sería como la introducción para compartirles a todos ustedes.
un pensamiento final desde una perspectiva en la cual puedan sacar algo práctico, algo que puedan poner en práctica en su día a día o en su esfuerzo por prepararse tal vez para en algún momento desempeñar uno de estos roles, ¿verdad?
Y por qué hay tanta confusión en este sentido y realmente que la implementación de la cultura DevOps para agilizar el ciclo de vida de las aplicaciones en lo que es la industria, diferentes empresas, sean empresas que se dediquen primordialmente a desarrollo, ⁓ o empresas meramente técnicas o empresas con cualquier otro rubro que tienen sus departamentos técnicos, esta implementación de la cultura DevOps hizo evolucionar
lo que antes se conocía como el departamento de sistemas en las diferentes empresas. También hizo evolucionar los departamentos de desarrollo, pero en esta ocasión nos vamos a enfocar en la parte de operaciones o lo que antes se conocía como departamento de sistemas. Teníamos en esos departamentos puestos como server admins o los server administrators, sysadmins, storage administrators, parte de estos departamentos muchas veces.
incluía lo que son los network admins, la implementación de DevOps y su cultura hizo que esta área se volviera un poco más dinámica, un poco más hacia la parte de operaciones. Y una vez que esta cultura se empieza a...
a implementar, a poner en práctica como que la industria se fue dando cuenta de que los nombres de estos diferentes puestos tenían que ajustarse para acomodarse un poco más a las funciones que comenzaban a realizar, ¿verdad?
esta misma evolución creó nuevas funcionalidades, nuevos requerimientos para estos puestos de trabajo y entonces, por ende, se hicieron cambios a los nombres para que reflejaran eso. Ya, esta persona ya no solo era un server admin, porque ya no solo administraba servidores únicamente, o solo un sysadmin porque no se encargaba de la configuración de un sistema o de algunos cuantos sistemas en específico, ya era un puesto que requería más colaboración, más automatización.
incluso, entonces eso fue lo que comenzó a crear esa necesidad de cambio de nombres para que se entienda cuando damos el nombre de nuestro puesto de trabajo o a qué rol queremos aplicar, que se sobreentienda que, cuáles son las funciones,
verdad.
Estos cambios en la industria tanto de la implementación de la cultura DevOps en general como comenzar a asignar nombres a los diferentes puestos fueron liderados por los grandes de la industria, hasta compañías grandes que tienen el presupuesto para crear incluso departamentos de investigaciones y de pruebas, departamentos que solo están tratando de probar nuevas tecnologías que muchas veces ni siquiera
salen a la luz para ser usadas de manera interna. Pero estas empresas grandes, estamos hablando que a los inicios de los 2000, Amazon, Google, Netflix, incluso Walmart, ⁓ yo recuerdo muy bien a principios de los 2000, aprender mucho de empresas como Walmart cuando estábamos queriendo implementar PopIt para Configuration Management, ellos compartían muchos casos de éxito y su evolución.
con lo que es la implementación de Puppet, incluso empresas como Walmart, comenzaron a marcar estos estándares de la industria, comenzaron a definir el camino para las empresas que venían por detrás.
pero desafortunadamente muchas de estas empresas cuando se apresuraron a ponerse al día porque tal vez al inicio no se prestaba mucha atención y como es una buena práctica de la misma manera que nunca instalamos la última versión de un software o la última versión de un sistema operativo en producción porque queremos esperar a asegurarnos de que no tenga fallas porque no queremos arriesgar a perder en producción de la misma manera la mayoría de la industria
en tecnología y esto es una realidad, esperamos a que los grandes pongan en práctica y se tope con errores y los puedan corregir para que la industria luego lo pueda adoptar con un presupuesto menor porque estas empresas no disponen de la misma cantidad de dinero, por así decirlo, para prueba y error, ¿verdad? Pero cuando la demás industria quiso ponerse al día...
la misma premura, el acelere de llegar ahí y no quedarse atrás, comenzaron a utilizar estos títulos de puestos de trabajo a la ligera, tal vez no les dio mucho tiempo de sobreentender al final del día cuál es el título que se le pone, no representa necesariamente un impacto en las funciones que realizan estos diferentes puestos, pero esta asignación de títulos a la ligera es lo
comenzó como VAC a causar confusión en la industria.
Y esa confusión se extiende hasta el día de hoy. En mi caso, yo recuerdo que por un tiempo mi título de trabajo era middle tier administrator. Middle de en medio o la capa de en medio, administrador de la capa de en medio. Y es gracioso porque en la empresa se tenía un departamento de sysadmin, que son los que se encargaban de provisionar la infraestructura, de proveerla, de crear las máquinas virtuales, eran en aquel momento, y asignar toda la configuración de sistema operativo.
y las seguridad y paquetes requeridos, crear usuarios y grupos, etcétera, a nivel del sistema operativo. Y también estaban los departamentos de desarrollo que creaban las diferentes aplicaciones.
Middle tier era el nombre del departamento y middle tier administrator era el nombre del puesto, se encargaba de configurar esa capa de en medio que era la configuración del web server, la configuración del application server y su deployment, ¿verdad? Y era un poco gracioso, yo normalmente decía que mi puesto era sysadmin, no porque me causara vergüenza ni nada por el estilo, sino que cuando yo decía, descubrí que cuando yo decía que mi puesto era middle tier administrator,
requería que yo explicara qué hacía porque no era muy común el título y entonces causaba curiosidad y me preguntaban, pero y eso qué es, verdad, incluso recuerdo que en una ocasión
en el 2018 para ser específico, que fue el año en que mantuve ese título, tuve la oportunidad de asistir a la conferencia de NGINX, NGINXConf se llamaban, pude asistir a la conferencia y alguien de la empresa me inscribió, no lo hice yo mismo y cuando llego y me entregan el badge, porque nos dan un badge para importarlo y que la gente vea cómo nos llamamos y qué puesto tenemos, me pusieron middle tier administrator.
si lo hubiese hecho yo y hubiese puesto sysadmin porque tal como lo esperaba cada persona con la que interactuaba y cada persona con la que creaba networking surgía la curiosidad y me decían, hey, ¿qué es middle-tier administrator? Entonces me pasé más tiempo en esa conferencia explicando qué es un middle-tier administrator que probablemente discutiendo otros temas.
Pero eso, ese tipo de situaciones son los que causan tal vez cuando se implementan mal los nombres o los títulos de trabajo y de nuevo aclarando de que lo importante al final del día es la función que se desempeña, sin embargo, cuando se viene comenzando o cuando se quiere transmitir a alguien más, ya sea a otras empresas, otros grupos o incluso candidatos que quieran aplicar apuestos de trabajo, cuando no se usa el título correcto.
se genera confusión, ¿verdad? Entonces, queremos, en este caso de mi persona para ustedes, explicar un poco estos como los más comunes hoy en día y tal vez de donde se derivan otros puestos, explicar un poco qué hacen...
y encontrar como que en qué partes se traslapan o se encuentran unos con otros, pero sobre todo compartir algo práctico al final que ustedes puedan implementar en su día a día y que les traiga beneficio. Y me gustaría comenzar con SRE, ¿verdad? Que son las iniciales de Site Reliability Engineer, título.
en inglés, supuesto, todo lo que tiene que ver con tecnología normalmente tiene un nombre en inglés porque las personas que hablamos español no comenzamos innovando en este ámbito de la tecnología y de igual manera quienes mayor consumen tecnología son...
países como Estados Unidos que hablan inglés. Entonces estos títulos son en inglés, Reliability Engineer creado y popularizado por Google, ¿verdad? Con la idea de facilitar la administración.
de sistemas a gran escala. hablando de sistemas, yo creo que no hace falta explicar qué tipo de sistemas tiene Google de manera interna, pero no se me ocurre un solo sistema que Google pueda tener que correr en un solo servidor, ¿verdad? Y que si se cae no hay mayor problema o que aguantaría la gran carga. Podemos imaginarnos el tipo de sistemas que ellos corren. Y esta...
puesto de trabajo que ellos relacionaron o esta incluso cultura, ¿verdad? Ellos tenían como mentalidad mezclar prácticas de desarrollo de software con operaciones, el manejo de la parte de operaciones o con el manejo de la parte de sistemas, teniendo como objetivo principal...
la alta disponibilidad y el alto rendimiento de los sistemas. nuevo, recordemos qué tipo de sistemas maneja Google, ¿verdad? Y si se cae el buscador o si se nos cae Gmail o si se nos cae el calendario, el caos, la catástrofe que sería para...
la mitad del internet probablemente si eso llegara a ocurrir. Y de igual manera, si se pusieran lentos, imagínense que ustedes quieren entrar a su correo, porque está extremadamente lento, y esa es la misma experiencia para todos los usuarios. Entonces, para Google es muy importante también el rendimiento de sus aplicaciones. Y esto es lo que buscaba resolver cuando ellos implementaron el puesto de SRE y esa cultura, y era mezclar estas prácticas de desarrollo de software con la parte de sistemas y operación.
con toda la intención de mantener la disponibilidad y el rendimiento lo más óptimo posible. perdón, ¿qué prácticas de desarrollo de software se utilizaron o comenzaron a crear como parte de este rol? Mayormente lo que son las automatizaciones, la automatización de tareas.
desde pipelines, CI-CD pipelines, scripts para automatizar diferentes procesos hasta código como tal, creando APIs internos.
para consumir y crear servicios internos como almacenamiento, incluso máquinas virtuales o contenedores. Ellos desarrollan y mantienen este tipo de servicios con código para automatizarlo. Entonces realmente es algo que depende bastante del desarrollo de código. De hecho, el libro de SRE de Google, muy recomendado, libro de SRE de Google nos muestra todo su pensamiento.
y las prácticas que se llevan y cómo implementarlo, ¿verdad? Este libro dice que el mejor candidato para el puesto de SRE es un sysadmin que aprende a programar, ¿verdad? Porque de nuevo la parte del código es bien importante para ellos para agilizar.
para automatizar todo lo que tiene que ver con el monitoreo, rendimiento y disponibilidad de la aplicación. Al final del día, cualquiera puede aprender, puede ser incluso un desarrollador que entra a la parte de operaciones o alguien que venga comenzando y definitivamente puede convertirse en un SRE. Nos está diciendo este texto que hay una limitante y que solo ellos pueden. La intención de este texto es que...
Un sysadmin
que aprende a programar es el que tiene el camino más corto para llegar a convertirse en SRE. Pero es importante que ellos dicen y resaltan que aprende a programar. Eso muestra y realza lo significante que es codificar para este puesto. No necesariamente codificar aplicaciones de front-end que se vean bonitas, pero sí codificar este tipo de automatizaciones que sean óptimas. ¿Verdad?
⁓ Otra cosa en la que se enfoca SRE, verdad, es que toman ellos de lo que es la práctica de desarrollo de software para este puesto de SRE, ellos toman también la implementación para mejoras y configuraciones.
con metodologías ágiles, con metodologías de desarrollo de software, con Scrum o cualquiera de estas otras metodologías que llevan a asignar tareas, asignarles estimados, hacerlas en sprints o en ciclos cortos para ver el progreso, SRE toma este tipo de prácticas de lo que es el desarrollo de software para implementarlo.
estas automatizaciones que ellos crean o incluso a las diferentes configuraciones que manejan en sus sistemas y en su infraestructura. También implementan lo que es el manejo de incidentes, cuando ocurre un incidente, ya sea un problema pequeño, grande, cuando se atrasa o se afectan sistemas internos, sistemas externos, cómo manejar esos incidentes, eso se copian prácticas de lo que es el desarrollo de software para el manejo de operaciones.
⁓ Otra práctica que se implementa de parte del desarrollo del software pero que se pule dentro de SRE, verdad, es la definición de métricas para documentar los rendimientos del sistema porque tenemos, es un puesto de trabajo que se está enfocando en...
la disponibilidad y en el rendimiento del sitio. Pero cómo saber de qué ese objetivo se está cumpliendo. ¿Cómo saberlo? ¿Porque no tenemos muchas quejas de los usuarios? Bueno, sí, es una métrica, Pero cómo cuantificar eso y entonces es ahí donde se crean estas diferentes métricas, crean, se definen a Service Level Objectives o lo que se conocen como SLO.
SLO que para quienes no saben, verdad, es un valor aceptable para una métrica específica. De forma resumida, verdad, es un valor para una métrica específica. define, ¿qué métrica puede ser? El uptime, por ejemplo, el tiempo que está arriba un servidor o un sistema. El response timeout.
cuando da Timeout un servicio al intentar conectarme a él, el error rate o cualquiera de estas otras métricas dentro de un sistema.
¿Cuál es el SLO o cuál es el valor aceptable para este sistema, para el buscador de Google? ¿Cuál es el valor aceptable de un timeout? Que hayan en un minuto 10 timeouts o 20 timeouts, ellos definen cuál es un valor aceptable y que si esa cantidad de timeouts se dan en un minuto, no hay ningún problema. En su sistema no hay nada de qué preocuparme porque definimos que ese valor es aceptable debido a la infraestructura que tenemos.
debido al tráfico, debido a la latencia que tienen los diferentes clientes, etcétera. O el opten de un servicio puede estar caído un servidor, no todo un servicio, ahí ya es una catástrofe, pero un contenedor o uno de los servidores de un servicio puede estar caído por 40 segundos porque ese tiempo toma en que se genere uno nuevo.
por el load balancer o por el auto scaling group o cualquier otro método que ellos tengan de auto healing, de auto sanación. Entonces, a 40 segundos puede estar caído, hay ningún problema porque el nuevo servidor va ser creado en 35 segundos. Entonces, hasta 40 segundos está bien. Pero si se excede de eso, entonces ya requiere una acción. Entonces, ellos toman.
esta parte del desarrollo de software, la definición de SLO dependiendo de cada una de estas métricas. Y junto con ello, porque va de la mano, se definen también los Service Level Agreedments o los SLAs, un Service Level Agreement en pocas palabras es...
¿Cuánto de eso se puede tolerar para que no haya un problema grande? ¿Cuánto de se puede tolerar? Sabemos que el uptime de una máquina virtual puede estar caída, dijimos como ejemplo 40 segundos, pero ¿cuánto de eso se puede tolerar, asumiendo que se pasa? Digamos que ocurrió dos veces en el día.
el SLA lo tolera, no hay ningún problema para el negocio recordemos que a ese punto si el SLO falló hay que ir a monitorear, que ir a hacer algo, verdad el SLO es el que define una métrica y si esa métrica se rompe hay que ir a hacer algo pero el SLA define
cuántas veces puede ocurrir uno de esos incidentes, cuántas veces se puede exceder uno de esos SLO sin que al negocio le afecte. Y es que SRE opera desde la perspectiva en que los demás departamentos de la empresa son sus clientes entre comillas. Porque esa es la misma empresa, es el mismo negocio. Pero la forma en que SRE opera es que ve cada uno de estos departamentos como clientes. Entonces, si la métrica de uptime...
está definido que puede romperse dos veces al día y no hay problema con el negocio, todo sigue bien.
pero si dice que puede romperse dos veces y yo se rompió tres veces, hay un problema con el negocio. En este caso hay un problema con cualquier otro departamento que se haya encargado de ese sistema en particular. Entonces, espero haberlo podido explicar de la manera más sencilla posible para aquellos de ustedes que no lo, tal vez no están familiarizados con estos conceptos, ¿verdad? Pero SRE, al ser un departamento,
enfocado en la disponibilidad y en el rendimiento crea estas diferentes métricas y cuánto es aceptable que estas métricas fallen para rendir cuentas y asegurarse que se está haciendo bien su trabajo.
Hay otras métricas, ⁓ como error budget y otros montones de métricas que existen alrededor de esa planeación, pero esto es como lo más relevante a resaltar para que se pueda entender que SRE realmente se enfoca más en este tipo de cosas y saca mayormente de lo que fue tradicionalmente práctica de desarrollo de software para implementarlas en el mantenimiento de la infraestructura. Ahora...
La parte de operaciones, en que se enfoca de la parte de operaciones, esto es algo que ya no se saca necesariamente de la cultura o de las prácticas de desarrollo de software, pero que son cosas que tradicionalmente han sido parte de los departamentos del sistema o de los sysadmin, pero que SRE sí se enfoca de manera activa. Y una de ellos es...
el monitoreo y la observabilidad de la infraestructura. De nuevo, y creo que ya a este punto ha quedado claro el patrón a seguir, que es estar pendiente de la alta disponibilidad y del alto rendimiento. Por ende, el monitoreo y la observabilidad es crítico, es muy importante. Y el monitoreo, para resumirlo y ponerlo como manera sencilla, se enfoca en seguir...
una métrica específica. Se enfoca en estar pendiente de una métrica específica, el uptime, el CPU, la memoria, el error rate, una métrica específica y si esa métrica llega, sobrepasa, ya sea por arriba o por abajo, porque muchas veces se monitorea.
que no baje esa métrica, un ejemplo de ello puede ser, para aclararlo aquí, un ejemplo de puede ser un servidor que sabemos que corre cron jobs. Y entonces tiene que estar algo ocupado todo el tiempo y sabemos que el CPU debería de estar aproximadamente en un 30 % de uso constante porque está corriendo ese diferente cron jobs. Entonces puedo poner una métrica de que si el CPU baja de 25 % de uso,
que me alerte porque muy probablemente los cron jobs no están corriendo y eso me hace ir a actuar y ver, ¿por qué este servidor está tan relajado cuando debería de estar constantemente mínimo a un 30 %? Entonces, el monitoreo se enfoca en una sola métrica y alerta cuando esa métrica os supera un valor.
o está recibiendo menos que un valor en específico. Ahora, por su parte, la observabilidad va más allá y la observabilidad permite tanto a los SRE como a los developers encontrar la causa de problemas o por qué esa alerta está cayendo.
Estamos teniendo alertas de uptime o estamos recibiendo alertas de CPU. El monitoreo nos manda esas alertas, pero la observabilidad nos permite encontrar eso porque incluye cosas como logs de diferentes servicios, ya sea del web server o del application server o logs específicos y métricas de la aplicación como tal. La aplicación, los diferentes, el developers, los diferentes equipos de desarrollo.
crean logs de diferentes métricas como por ejemplo, cuántas veces un endpoint en específico está recibiendo request o de dónde está recibiendo los requests, cuántas veces un endpoint en particular está recibiendo timeout o cuando el endpoint X se conecta a la base de datos, cuánto tarda.
o cuando el endpoint Y cuando pasa por cache, cuánto tarda. Entonces esa observabilidad nos permite identificar qué es lo que está pasando.
Ya va más allá de solo, hey, un error de CPU alto o un error de que las instancias se están reiniciando, un error de que los contenedores se están reiniciando. Va más allá de eso y con esta observabilidad encontramos la causa principal del problema. Y de nuevo, esto es crítico cuando tenemos un equipo que su función principal es...
mantener la aplicación corriendo todo el tiempo con un rendimiento aceptable todo el tiempo, ¿verdad?
Entonces, otra de las cosas en las que SRE se enfoca de roles que han sido tradicionalmente para la parte de sistemas es en la publicación o el despliegue de las aplicaciones a los diferentes ambientes. Y aquí se combina con la parte que saca de desarrollo del software que ya discutimos al principio, que ya mencionamos, es combinando estas prácticas se automatiza.
se automatiza ya sea por medio de CI-CD pipelines o si hay diferentes pruebas, tests o cosas que se tienen que ejecutar, se crean en código para que se pueda automatizar y el despliegue pueda ser efectivo, automatizado en tiempo y forma porque si estamos preocupados por el rendimiento o estamos preocupados por la alta disponibilidad y se necesita lanzar un fix de un bug, tiene que ser rápido.
automatizado, dándole el poder al developer del poder hacerlo y de poder, utilizando las otras prácticas anteriores, seguirlo y ver cómo funciona. Entonces, esa es otra de las prácticas en las que se enfoca, que han sido tradicionalmente de los departamentos de sistemas.
Y una última que me gustaría mencionar es el responder a incidentes. Tradicionalmente, cuando una aplicación se caía antes de lo que es la cultura DevOps, normalmente las alertas llegaban a los departamentos de sistemas. Eran quienes recibían el correo con la alerta o el mensaje con la alerta y son los que tenían que ir a ver qué ocurre.
Pero era tedioso, era complicado porque no se tenía acceso a la observabilidad, esta parte de las aplicaciones o aún en los equipos que sí tenían una mejor configuración de logs. Era difícil porque el de sistemas no conocía la aplicación. Entonces, aunque tenga esa observabilidad, al no conocer la aplicación...
para mí se vuelve a mostrar viendo algo en chino, como decimos en Latinoamérica. Y eso lo volvía complicado, tocaba llamar al developer, hey, mirá, veo este error y el developer se buscaba a lavarse las manos y decía, a me currió bien, debe de ser el server, ya probaste a reiniciar y se crean las historias y existen muchos mitos y leyendas alrededor de eso y yo a nivel personal tengo cientos de historias que no voy a contarlas por motivo de tiempo, pero eso era un problema.
Pero
ya con SRE, al responder a incidentes, toma esa responsabilidad de lo que tradicionalmente eran los departamentos de sistemas, pero ahora utilizando como base esos SLOs o SLAs que se definieron al inicio como práctica traída del desarrollo de software al manejo de operaciones, utilizando eso se crean runbooks.
que son procesos para reaccionar de manera más eficiente ante incidentes. Estos runbooks incluyen los errores más comunes de la aplicación, forma de escalar un problema, forma de documentar si ocurre un nuevo problema, algo que no se había visto, cómo documentarlo.
para traerlo enfrente del equipo de desarrollo, traerlo enfrente de tal vez otros desarrolladores senior, y documentarlo y agregarlo al mismo round book para que cuando se dé un incidente, en lugar de estar llamando el de sistema al desarrollador, el desarrollador a lavarse las manos y meter a todo mundo en la conversación, de manera eficiente siguiendo los SLA y definiendo estos round books,
rápido se actúa y se busca resolver el problema de manera inmediata porque, voy a recalgar una vez más, ya lo hice como cuatro veces antes, ¿verdad? Pero SRE se enfoca en la alta disponibilidad y en el rendimiento de la aplicación. Por ende, cada vez que hay un incidente es crucial saber reaccionar rápido para tener el sitio operando de la mejor manera lo más rápido posible.
Ahora, con toda esta información y tal vez van a decir Douglas me dijiste un montón de cosas, quedé siempre un poco perdido o cómo lo resumo, les voy a dar un resumen sencillo para que lo tengamos en mente y de esa manera podamos hacer la distinción de qué realmente es lo que hace un SRE. La primera vez se enfoca en la alta disponibilidad y rendimiento de los sistemas.
Segundo, automatiza el despliegue de las aplicaciones utilizando la parte que dijimos de la cultura o las prácticas de desarrollo de software tradicional. Tercero, monitoreo y observabilidad de los sistemas y de la infraestructura. Y todo eso utilizando estas prácticas de desarrollo de software y metodologías ágil.
Entonces, con estas cuatro cosas, podríamos resumir en una simplificación tal vez bien grande, pero es una simplificación bien acertada de cuál es el rol de un SRE realmente. De nuevo, popularizado por Google, pero enfocado en el rendimiento y disponibilidad de la aplicación. Ahora, habiendo aclarado un poco y contando un poco cuál debería de ser el rol de SRE,
Avancemos ahora con Cloud Engineer. Cloud Engineer es otro de los roles que hoy en día es de los más comunes, más buscados y a veces decimos, Engineer es solo otro nombre de SRE. En la realidad y para estas empresas grandes que son los que han definido estos estándares de la industria, en la realidad es que no. No es otro nombre para SRE. No otro título para SRE. Es un rol diferente. Es un rol diferente.
¿En qué se enfoca un Cloud Engineer? Se enfoca en diseñar o arquitectar, desplegar y mantener infraestructura en la nube.
diseño o arquitectura, el despliegue y el mantenimiento de infraestructura en la nube. Principalmente esta infraestructura tiene como objetivo que en ella se despliegue o se publique aplicaciones que se conocen como cloud native application. Quienes no se han encontrado con este término antes, o tal vez lo han escuchado pero no han tenido idea de qué es.
Cloud Native Applications son aplicaciones diseñadas desde su concepción, desde que se pensó, desde que nació, aplicaciones diseñadas para aprovechar todos los beneficios de la nube, los diferentes servicios de la nube, pensadas para si va a tener un almacenamiento compartido utilizar tal vez storage como S3.
en lugar de disco de oro interno porque esto va a correr en contenedores o en diferentes máquinas virtuales. Object Storage va a ser mejor que el Storage local. Aplicaciones pensadas para utilizar servicios como bastas de datos escalables o sistemas de cola. Son aplicaciones que desde su concepción...
tienen en mente favorecerse, beneficiarse de todo lo que la nube ofrece y de esta manera ser más eficiente. en pocas palabras eso es Cloud Native Applications. Un Cloud Engineer se enfoca en diseñar, desplegar y mantener infraestructura en la nube con la intención de que mayormente en esa infraestructura se desplieguen este tipo de aplicaciones.
Cloud Architect es un rol similar, del cual no vamos a profundizar mucho, pero en las empresas donde es grande de nuevo, se implementan estos roles como de manera más estricta, el Cloud Architect normalmente solo diseña las aplicaciones.
pero no se encarga de desplegarlas ni de mantenerlas, sino que el Cloud Architect las diseña y luego se las pasa al Cloud Engineer para que él las despegue y las mantenga. Normalmente en estas empresas grandes es así, pero ahorita nos estamos enfocando en el puesto de Cloud Engineer, ¿verdad? Aunque en muchas empresas...
medianas, pequeñas, cloud architect, cloud engineer, son diferentes niveles para el mismo puesto y tal vez el cloud architect es alguien con mayor experiencia. Pero de nuevo estoy tratando de abordar aquí como que lo más común dentro de estas empresas que definen el rumbo de la tecnología, así como hoy en día tenemos con lo es la inteligencia artificial cuatro o cinco empresas grandes definiendo este rumbo, siempre ha sido así a lo largo de la historia.
y con lo que tiene que ver con estos términos del ciclo de vida de aplicaciones y la implementación de la cultura DevOps fue así en su momento y sigue siendo así. Ahora, continuando, el Cloud Engineer tiene que ser alguien que es experto mínimo en uno de los tres grandes proveedores de nube. Experto mínimo en uno de entre AWS,
Azure o Google Cloud Platform. Estos son los tres grandes. Cualquier aplicación grande, cualquier sistema que requiera de una integración completa de muchos servicios.
va correr en uno de estos tres grandes. Hay proveedores de nubes muy buenos que son más pequeños. Yo uso mucho DigitalOcean para mis propios servicios o mi propio entrenamiento. Mi sitio, Blog Personal, corre en DigitalOcean en Kubernetes. Nuestro sitio de DevOps corre ahí mismo en DigitalOcean también en Kubernetes.
y aunque tienen muchas funciones buenas, cualquier sistema grande realmente va correr en uno de estos tres. Entonces mínimo un cloud engineer va a ser experto en uno de estos tres, si no es que en dos o probablemente en los tres, ¿verdad? Pero mínimo uno. También tiene que ser experto o al menos eficiente en los puestos de trabajo dice proeficiente, normalmente. Es alguien de que tal vez no es el más experto.
pero tiene la capacidad de trabajar con esa tecnología en particular, tal vez en lo que lee un poco de documentación o tal vez en lo que busca en Google un poco, que hoy en día es preguntarle a la inteligencia artificial también, ¿verdad? Pero eso es proeficiente en algo, entonces un cloud engineer tiene que ser experto o al menos eficiente, proeficiente en infraestructura como código, lo que se conoce como infrastructure as code.
ya sea Terraform, Pulumi, CloudFormation y todas estas Crossplane y otras... cualquier otro servicio que están por ahí. Terraform es como el más utilizado aún en la actualidad, Pero tiene que saber de infraestructuras code para desplegar esta infraestructura que primero diseñó de manera automática y mantener todo en version control, ¿verdad? También tiene que ser experto o suficientemente bueno.
en lo que es Configuration Management, herramientas como Puppet, Ansible Chef, verdad, y para quienes no conozcan la diferencia entre Infrastructure as Code y Configuration Management, Infrastructure as Code es diseñado para desplegar infraestructura, por eso es un nombre de infraestructura como código, para crear y desplegar infraestructura al ejecutar tu código, en pocas palabras, y Configuration Management se encarga de configurar.
los servicios que corren en esta infraestructura como ser desde el sistema operativo, usuarios y estándares de seguridad básicos, instalar paquetes básicos en el sistema operativo o configuraciones de web server, application server, configuración de NGINX, cosas de seguridad, etc. Configuration Management se encarga de ello. el Cloud Engineer tiene que saber hacer, saber manejar mínimo uno de estas herramientas.
para poder administrar la infraestructura que ellos crean con forma de código, que es el beneficio de estas herramientas. Un cloud engineer también tiene que ser o experto o proeficiente en Kubernetes, porque hoy en día, si bien es cierto, existen otros orquestradores de contenedores.
como ICS en el caso de los que están en Amazon, por ejemplo, que es muy bueno, muy potente, o todavía existe Docker Swarm y hay algunos escenarios en los que yo recomiendo Docker Swarm. La realidad es que la gran mayoría de escenarios en los que se necesitan contenedores y orquestración de contenedores se usa Kubernetes. Entonces, tiene que saber...
utilizar Kubernetes. También un Cloud Engineer tiene que saber de configuración de servicios, en general configurar web servers como NGINX, configurar servicios de caching como Redis, Memcache o cualquier otro que se quiera, servicios de cola, de mensajería, etcétera. Tiene que saber configurar estos servicios ¿por qué? Porque el Cloud Engineer, como objetivo recordemos es
crear, diseñar, arquitectar, desplegar y manejar esta infraestructura donde van a correr estas aplicaciones, mayormente cloud native applications. Entonces, hay que entender todos estos servicios para poder ofrecer la mejor solución posible de acuerdo a los requerimientos de la aplicación.
No puedo, si soy un cloud engineer, no puedo dar la mejor solución en cuanto a web server si no sé configurar el web server. No puedo ofrecer la mejor solución en cuanto a caching o un servicio de caching si no sé configurarlo y si no sé si ese servicio de caching en particular cumple con los requerimientos de la aplicación. Entonces como cloud engineer tengo que saber mínimo esas cosas para poder cumplir con ese rol, ¿verdad?
Entonces, de nuevo, queremos porque hemos dado bastante información y si estás pensando, hey, esta información sí me es útil, es un montón, me perdí un poco, ¿cómo puedo resumir el puesto de Cloud Engineer? Como inicié. Diseña, despliega y mantiene infraestructura en la nube lista, infraestructura lista para poder publicar.
Cloud Native Applications. Ese es el rol de un Cloud Engineer. Ahora, avanzando, me gustaría avanzar al otro puesto que hoy en día es como bien popular y se busca bastante, que es el de Platform Engineer. El Platform, no puedo hablar inglés hoy, no sé qué me pasa.
Platform Engineer. Y este es un puesto que me resulta bien interesante porque por el nombre y por el título, a veces me lleva a otro lugar cuando no conozco ciertas prácticas modernas que manejan empresas grandes, me lleva a pensar que configuro una plataforma como tal donde corren aplicaciones de producción.
Pero en realidad un Platform Engineer se foca en diseñar y mantener algo que se le conoce como Internal Developer Platforms o IDPs. IDP. Internal Developer Platforms. ¿Y qué es esto? ¿Qué son los IDPs? En palabras sencillas son herramientas y servicios internos que les permiten a los desarrolladores
crear y manejar infraestructura de manera fácil y rápida. Miren qué interesante es esto, ¿verdad? En lugar de que los cloud engineers estén creando esta infraestructura donde van a correr los cloud native applications,
Los Platform Engineers crean herramientas, crean servicios internos o instalan herramientas porque hay algunas herramientas que ya hacen este tipo de cosas y un Platform Engineer puede basarse en una de ellas y expandirlas de acuerdo a las necesidades de la empresa, pero crean estas herramientas para que los desarrolladores creen esta infraestructura final donde van a correr las aplicaciones. Levantan ambientes enteros.
y abstrae para el developer el contexto y lo que está detrás en la infraestructura. El developer no tiene por qué preocuparse de cómo se crean los contenedores o qué tipo de base de datos, bueno, no el tipo, sino qué servicio de base de datos creó o qué cache está utilizando, los CI-CD pipelines. El developer no tiene que tener el contexto ni saber cómo configurar.
cada una de estas cosas. developer solo tiene que entender los requerimientos, solo tiene que entender que quiere una base de datos de MySQL o una base de datos de Postgres. El developer solo tiene que entender que necesita para cache de Redis o Memcache o cualquier otro servicio de cache. El developer solo tiene que entender que ocupa tres ambientes, uno de staging, uno de preproducción y uno de producción. El developer solo tiene que entender estas cosas.
Y el Platform Engineer crea todas estas herramientas, esta interfaz donde el developer con algunos clics o a veces como parte de un CI-CD pipeline da los requerimientos que quiere y esta infraestructura se crea. Y esto es algo bien interesante y los IDPs por sí solos son un tema muy interesante que pudiéramos tocar en otro episodio. Quiero aclarar que yo a nivel personal
No tengo tanta experiencia trabajando con ellos, tengo algo de experiencia, he jugado un poco con estas tecnologías, verdad, yo a nivel personal no tengo tanta experiencia.
Aunque sí he implementado conceptos en pipelines donde dependiendo el nombre de un branch se crea de manera dinámica un ambiente de desarrollo o de manera dinámica creamos ambientes o diferentes alertas y monitoreos dependiendo de algunos annotations que se crean en Kubernetes. Entonces tengo algo de experiencia con ellos pero conozco bastante porque es algo que hemos explorado en los últimos años.
para tratar de implementar donde trabajo actualmente. Pero es algo muy interesante y el Platform Engineer crea estas plataformas para que los developers...
creen la infraestructura final. Creen la infraestructura final donde van a correr las aplicaciones. El developer al hacer esto se encarga de empoderar, o Platform Engineer empoderar al developer para que él se pueda encargar del ciclo de vida completo de su aplicación incluyendo la infraestructura final.
incluyendo acceso a logs, incluyendo acceso a observabilidad, alertas, de nuevo, sin que el developer tenga que saberlo, pero en estas, hay DPs en estas, perdón.
IDP que son las Internal Developer Platforms, el Platform Engineer se asegura de que la infraestructura que se va a crear cumpla con todos los requerimientos de la empresa, requerimientos de seguridad, requerimientos de acceso, estándares internos de diferentes herramientas, etcétera. El Platform Engineer.
facilita estas plataformas a los desarrolladores. es un puesto muy interesante y literalmente se llama Platform Engineer porque está trabajando en las plataformas que los developers van a utilizar para crear infraestructura. Entonces, de nuevo, si se sintió confuso, te pareció interesante, pero lo sientes un poco confuso, ¿cómo puedo resumir Platform Engineer?
A diferencia de lo que su título puede sonar para muchos, el Platform Engineer se enfoca en el desarrollo de herramientas internas para que los desarrolladores creen y administren sus propios ambientes. De nuevo, se enfoca en herramientas internas para que los developers tengan el poder de desarrollar, crear, administrar sus propios ambientes. Entonces, esto es el rol de Platform Engineer.
Ahora,
Douglas (49:57)
existen otros roles que son como bien granulares, bien específicos, roles como Release Engineer, que está como más definido en la parte del despliegue de las aplicaciones, Infrastructure Engineer.
que es tal vez un poco parecido a lo que es el Cloud Engineer, pero tal vez más abierto, manejando infraestructuras híbridas, o tal vez solo en data centers on-prem o infraestructuras híbridas, Automation Engineer y otro montón que existe por ahí. Pero nos estamos enfocando en estos principalmente porque son...
De nuevo, los que más se encuentran en ofertas laborales, los que más se comentan y de donde se derivan muchos de los otros nombres que existen. Ahora, ¿en dónde encaja DevOps Engineer?
que probablemente es el más sonado, probablemente es el que más se encuentra por ahí en ofertas laborales, el que más nos comentan conocidos o amigos, nos dicen yo soy un DevOps Engineer y trabajo de DevOps Engineer en la empresa Xoy.
¿Cuál es la función realmente de un DevOps Engineer? Y aquí es donde se vuelve interesante, Porque como lo hemos mencionado en el pasado, DevOps realmente es la cultura de colaboración, esta estrategia de cultura de colaboración entre los departamentos o los equipos de desarrollo y los equipos de sistemas o operaciones. Eso es lo que es realmente DevOps.
Sin embargo, por alguna razón, muchas empresas decidieron nombrar o crear ese rol dentro de sus empresas o dentro de sus equipos. Porque así lo quisieron. Y ya hemos aclarado antes, es bueno que evitemos como estresarnos por el tema y tal vez ser bien cerrados y querer debatirlo. Porque al final del día, la realidad es que estas empresas han creado este puesto, este rol de DevOps Engineer.
Y el hecho de que exista este puesto, pero no hay una definición exacta de qué es lo que hace un DevOps Engineer. Si le preguntamos a la Inteligencia Artificial o si ⁓ buscamos en Google qué es lo que hace un DevOps Engineer,
diferentes sitios o diferentes personas nos van a dar una lista de responsabilidades diferentes. Hay algunas torales, hay algunas torales que se van a repetir entre una y otra, pero no vamos a encontrar consistencia como en estos otros puestos de trabajo que mencionamos donde si ustedes buscan casi que en cualquier sitio va a haber una consistencia mayor entre las funcionalidades que la que existe con lo que es el DevOps Engineer.
porque las empresas lo fueron creando y lo que ocurre es que aquí fue como su forma de nombrar cualquiera de los puestos anteriores que hemos mencionado, SRE o Cloud Engineer, su forma de nombrarlo por la premura, por querer ponerse al día con tecnología, fue decir un DevOps Engineer o porque tal vez crearon su propia versión del rol.
su propia versión del puesto agarrando un poquito de aquí y poquito de allá para crear su propia versión del puesto para adaptarla a sus empresas, sus flujos de trabajo, a sus departamentos porque hay algo que tenemos que tener bien importante, algo bien importante perdón que tenemos que tener en mente el día de hoy es la realidad de la industria del día de hoy ⁓
Las empresas medianas o pequeñas no pueden darse el lujo de tener puestos tan marcados como lo hacen las empresas grandes. Como dije al inicio, estas empresas grandes tienen incluso departamentos de prueba y de desarrollo y ellos tienen el dinero para invertir gente.
para invertir tiempo y recursos en personas que trabajen en prototipos que algunos se van utilizar, a otros no. Pero los cuantos prototipos que sí se logran utilizar, les terminan recompensando más que el dinero que invirtieron. Por una empresa mediana o pequeña, no puede darse ese lujo. Lamentablemente no puede darse ese lujo. Entonces, es ahí donde proviene.
de que tenga que surgir un puesto de trabajo que se ha vuelto tan popular como lo que es el DevOps Engineer, porque tal vez tienen que juntar los diferentes puestos en uno solo. Y yo recuerdo que en el tiempo de los departamentos clásicos de sistemas, también las empresas grandes tenían puestos bien granulares.
que comúnmente en una empresa mediano pequeña los hacía únicamente el sysadmin. Casi todo eso lo hacía sysadmin. Las empresas grandes tenían aparte de un server admin o un sysadmin, tenían también storage admin.
que se encargaba de los storage centralizados para asignarles volúmenes a diferentes clusters o instancias y todo la creación de storage y los rates que hay que crear y los diferentes loans y cómo compartirlo por medio de fibra o por medio de SCoS y todo eso es su ciencia propia. Entonces, yo recuerdo bien empresas grandes tener storage admin, solo encargado de estar creando
porque era tanta la necesidad que había que ocupaban mínimo una persona dedicada a eso. También había virtualizaciones admins encargados de la plataforma de virtualización y aún dentro de virtualización había subdivisiones a veces, los que se encargaban de la virtualización tradicional Intel o los que se encargaban de virtualización por ejemplo de los Power Series de IBM donde se instalaba EIX o el AS400.
Entonces tenían esas, aún antes las empresas grandes tenían esas segmentaciones del network admin, verdad. También era separado donde empresas medianas o pequeñas el sysadmin normalmente hacía o todo eso o la mayoría de eso. Lo que normalmente, lo más que yo lograba ver era que tenían sysadmin y network admin.
porque tal vez la parte de redes pues sí se extendía más y se tenía un network admin. Pero fuera de ello las empresas medianas o pequeñas, el sysadmin lo hacía todo, mientras que las empresas grandes tenían puestos para trabajos más granulares. Y lo mismo es hoy en día. Las empresas pequeñas, medianas, no pueden realmente darse ese lujo. Entonces, es de ahí donde...
donde aparentemente surge entre la premura, entre querer ponerse al día rápido y entre no poder cumplir con todo lo anterior la granularidad de estos puestos, nace o surge este puesto de DevOps Engineer. Entonces...
teniendo eso en mente, teniendo eso en mente, quisiera como que dar unos consejos finales o quisiera darles como qué hacer con esta información porque podemos decir, hey, sí me parece muy interesante el tema, tal vez algunas cosas no las sabías, tal vez algunas cosas sí las sabías o tal vez algunas cosas se topas como normalmente se hacen en la industria, pero entonces, qué hacer con esta información, qué beneficio le puedes sacar.
Lo primero que yo te puedo decir como consejo en esto es ser mente abierta, ser comprensibles, va. Recordemos por favor no dejar llevarnos por esto, definiciones del libro, por esto de que DevOps Engineer no es un puesto de trabajo, es una cultura, entonces no voy a aplicar en esta empresa o no me gusta que en mi empresa nos van a cambiar el nombre de Sysadmin a DevOps Engineer.
No, abramos nuestra mente un poco más. No es que estemos equivocados, estamos en lo correcto. No debería de llamarse DevOps Engineer, acorde al crecimiento de la industria y acorde a lo que han marcado estos grandes de la industria. Sin embargo, tomémoslo con calma, entendamos de dónde viene y no dejemos que eso se apodere de nosotros. Recordemos, lo recalco, lo recuerdo. Estas empresas medianas pequeñas no tienen la capacidad.
no tienen la capacidad de, aunque nos parezca que sí, la realidad es que no tienen la capacidad de pagar un puesto de trabajo muy granular. Recordemos que un profesional alrededor de la cultura DevOps, la parte de operaciones, puede oscilar fácilmente para una empresa de 48 mil dólares al año hasta 50, 160 mil dólares al año.
eso es realmente bastante dinero ya que nos parezca que es una empresa millonaria tiene muchos más gastos entonces no todas pueden realmente pagarlo y si esto es algo quien a pesar de que sé esta información me sigue molestando tanto me sigue incomodando tanto pues entonces
les recomiendo que se preparen bien para que busquen trabajo en una empresa de estas grandes donde si pueden segmentar sus diferentes puestos y si pueden ser SRE, llamado SRE o si pueden ser Cloud Engineer, llamado Cloud Engineer. Solo que quiero recordarle que estas empresas como si tienen...
un presupuesto más amplio son más exigentes con lo que requieren y necesitan y van a contratar únicamente a los mejores. Su proceso de contratación, diferentes pruebas que van a hacer ellos probablemente van a ser más rigurosas porque como tienen el dinero, tienen el recurso, se van a asegurar de que ese recurso sea implementado solamente en los mejores. ¿Verdad? Entonces...
No estoy diciendo que no sean capaz, que no seamos capaces, si lo somos. Solo quiero decir de que muchas veces es bueno que seamos de mente abierta y vayamos por pasos para ir creciendo, para ir creciendo y tomemos con calma si en la empresa en la que estoy mi puesto DevOps Engineer y no debería llamarse así o si en empresa en la que estoy mi puesto es SRE, pero no estoy haciendo de SRE.
Entonces, tomémoslo con calma. En la actualidad, mi puesto donde yo estoy, en realidad se llama Systems Engineer. Y el motivo de ello es porque ellos separan las funciones en disciplinas. Y la parte que tiene que ver con desarrollo se llama Web Engineering, la disciplina de Web Engineering, todo lo que tiene que ver con desarrollo, front-end, backend, aplicaciones móviles, etcétera, está dentro de esa disciplina. Y todas las partes que tiene que ver con operaciones, infraestructura, la disciplina se llama Systems.
por ende, los que estamos en esa disciplina somos systems engineer y en realidad es mayormente cloud engineering en su gran mayoría cloud engineering con algunas funcionalidades ya comenzando de senior system engineer o en mi caso que soy un lead system engineer
tomamos partes de lo que es SRE, la parte de observabilidad, la parte del monitoreo y también la parte de lo que son los SLAs, SLOs y todo lo que tiene que ver con la aplicación. Eso mayormente y un poquitito de Platform Engineer es lo que en realidad en la empresa en la que yo trabajo es Systems Engineer. Entonces de nuevo, seamos abiertos, eso es el primer consejo que les puedo dar.
de qué pueden hacer con esta información, verdad. Y el segundo consejo que les puedo dar es...
para quienes están comenzando y quieren agarrar este camino de la parte de operaciones, de la parte de sistemas o lo que se conoce como la parte de DevOps, ya sea quienes vienen comenzando en tecnología o que tal vez ahorita son programadores, ahorita son sysadmins y quieren transicionar a este camino, a este pad de la parte de operaciones, con esta información podemos ver...
¿Qué comenzar aprendiendo? ¿Qué herramientas o tecnologías son relevantes para encontrar trabajo? sea en una de estas áreas en particulares, si tienen como meta, yo quiero ser SRE porque es la parte que más me gusta, más me llama la atención, o yo quiero ser Cloud Engineer porque es la parte que más me gusta, la que más me interesa, interactuar con la nube, configurar Kubernetes y los web servers, etcétera. Entonces, con esta información...
pueden saber qué tecnología comenzar a aprender. Y si quieren un consejo de mi parte, como alguien que tiene dos décadas en lo que es tecnología, si quieren un consejo de mi parte, yo les diría que comiencen aprendiendo un poco de cada uno de estas áreas. ¿Cuál les recomiendo aprender? Que no lo mencioné aquí porque está implícito, pero comiencen con Linux.
porque ese es el común denominador entre todas estas áreas. Los servidores corren en Linux, los sistemas corren en Linux y aunque aquí y allá hay servicios que van a ser Windows y en algunas áreas Windows sobresale, algunas cuantas áreas Windows sobresale sobre... comparado con Linux, realmente que la web corre realmente en Linux, comenzar con Linux y DSRE, ¿qué pueden sacar? Las metodologías ágiles porque la mayoría de empresas... ⁓
trabajan como metodologías ágiles, eso ahorita también se puede sacar la automatización.
básico de automatización, ya sea con scripting, ya sea con CI-CD pipelines, no tiene que ser como en full código, como lo hace SRE, creando APIs, creando SDKs, pero sí la parte de automatización de SRE básico. Y también de SRE, yo les recomiendo que comiencen con monitoreo y observabilidad.
entendiendo herramientas de monitoreo, métricas básicas, analizar logs de manera básica, ya sea con herramientas o de manera manual, pero que DSRE puedan incluir eso en su estudio si quieren agarrar este pad. Ahora, de Cloud Engineering, les recomiendo aprender mínimo lo básico de uno de los tres proveedores grandes de nubes.
de cualquiera de los tres grandes y ahí puede depender un poco como que hacia qué quieren orientarse si están en una empresa que tal vez tiene bastantes flujos en Windows de manera local porque tienen su Exchange Server, tienen Optic Directory y tienen otros servicios en Windows, probablemente les favorezca que comience con Azure porque la transición va a ser mejor, más eficiente si se van a Azure. Y si no saben cuál de los tres escoger para comenzar, yo recomiendo AWS.
es el que yo más uso, el que mejor manejo y realmente que es el más utilizado. Entonces la probabilidad de que encuentren trabajo en AWS es más alta comparado con Azure o comparado con Google Cloud Platform. De Cloud Engineering que también les recomiendo aprender, Terraform y Ansible. De infraestructura scope, Terraform sigue siendo el más utilizado.
más utilizado que hoy en día existe Pulumi, existe Crossplane y otras que son muy buenas, muy, buenas, pero la realidad es que sigue siendo más utilizado Terraform, entonces de nuevo la posibilidad de que se encuentre trabajo, si saben Terraform va a ser más amplia.
a que se aprende en Pulumi o Crossplane o el mismo CloudFormation que está ligado únicamente a AWS y no puedo crear recursos en otro tipo de proveedores. Y Ansible, de lo que yo miro en mi experiencia, también es probablemente el más utilizado hasta donde yo miro. Aquí no estoy tomando yo con Ansible métricas o no busqué yo información como tal en Internet de cuál es el configuration management más utilizado. Sin embargo, con lo que
yo
me he topado ansibu es el más utilizado. Cloud Engineering, más pueden incluir en su path para iniciar estudiando? Configuración de web servers con NGINX.
NGINX normalmente se pone en frente casi que de cualquier servicio web servers mayormente, como reverse proxy, pero también se puede usar como load balancer, también se puede poner, se pone mucho en frente de Elasticsearch y se pone en frente de otros servicios. Entonces, aprender NGINX, yo lo incluiría sí o sí de lo que normalmente sacándolo del path de cloud engineering para incluirlo a mi estudio si viniera comenzando.
Y una cosa más que sacaría de lo que normalmente hace un cloud engineer sería Docker con Kubernetes básico. De nuevo, Docker para Dockerizar como tal las aplicaciones y Kubernetes sigue siendo el orquestrador más utilizado. Pudieran comenzar con DockerSummit que es más fácil, pero lo mismo que aplica para otras tecnologías. Lo más probable es que la empresa donde están...
esté trabajando con Kubernetes, mis posibilidades de encontrar trabajo en esa área si estudio Kubernetes van a ser más amplias. Ahora, de Platform Engineer, ¿qué recomiendo que comiencen a estudiar si ustedes no tienen algo bien marcado? Primero el entendimiento.
de los diferentes ambientes en el ciclo de vida de una aplicación para que sirva un ambiente de desarrollo, que sirva un ambiente de staging, que es un ambiente de reproducción, que es un ambiente de producción como tal. Ese entendimiento que un Platform Engineer lo maneja muy bien.
Yo recomendaría incluirlo y también recomendaría incluir lo básico de entender lo que son estos IDPs, los Internal Developer Platforms, entender lo básico, funciona, son, conocer un poco de las herramientas más utilizadas, los open source.
⁓ Spotify tiene una herramienta, ahorita se me olvidó el nombre, pero incluso la estuve investigando un poco, ahí sí me acuerdo que lo menciono, pero Spotify tiene una que es muy utilizada, igual hay otras por ahí, entonces de platform engineering yo recomendaría incluir esas cosas. Ahora, esta es una recomendación muy personal, basado tanto en mi experiencia de cómo yo ido aprendiendo, como de qué yo miro en la industria hoy en día, pero en realidad...
pueden escoger el camino que ustedes consideren más conveniente. De nuevo, su objetivo puede variar porque si están en una empresa, sos desarrollador y querés moverte a la parte de DevOps, puede que, dependiendo que haya en tu empresa, quieras escoger otras herramientas para comenzar en ellas porque eso va a beneficiar tu puesto. Entonces...
esos son esos son los consejos que yo les daría de qué pueden hacer con esta información que no sea más allá de sólo saber o entender qué son estos diferentes roles y qué hacen normalmente sino que puedan tener algo práctico que puedan poner que puedan implementar y les pueda generar valor y beneficio para que resalten al momento de conseguir trabajo o dentro de su trabajo actual
Y habiendo compartido esta información, quiero agradecerles mucho por su atención a pesar de que hoy no estuvo Juan y les tocó escuchar un monólogo de mi parte. Espero no haberlos aburrido de nuevo. Si llegaron hasta acá, les agradezco mucho su atención. Espero que la información que les compartí hoy haya sido de utilidad, que les pueda generar valor a su vida.
en su vida como profesionales y si tienen preguntas, si quieren hacer sugerencias, dudas, por favor déjenlo en la sección de comentarios de la plataforma en la que nos estén viendo o escuchando. De nuevo, muchísimas gracias por su tiempo. Nos vemos hasta la próxima.