Comprender la diferencia entre DevOps y SRE es el primer paso para construir aplicaciones que soporten grandes volúmenes de tráfico sin caerse. Pablo Fredriksson, con más de quince años de experiencia como sysadmin y site reliability engineer, explica con claridad qué significa cada término, cómo se relacionan y qué conocimientos necesitás para entrar en este mundo.

¿Cuál es la diferencia entre DevOps y SRE?

Una confusión muy común es tratar DevOps y SRE como sinónimos. En realidad, cumplen funciones distintas pero complementarias. DevOps es una cultura que se aplica a toda la empresa, no solo a un equipo [01:52]. Esto significa que desarrolladores, personal de operaciones y equipos de sistemas trabajan bajo los mismos principios de colaboración y mejora continua.

Por otro lado, SRE es el puesto que se encarga de aplicar esa cultura desde la perspectiva de infraestructura [01:57]. El equipo de SRE garantiza que los sistemas sean estables mientras permite que los equipos de producto desplieguen nuevas features con la menor fricción posible.

¿Por qué desarrollo y operaciones suelen ser rivales?

En empresas tradicionales, los equipos de desarrollo quieren lanzar código nuevo constantemente, mientras que los equipos de operaciones priorizan la estabilidad [02:12]. Cada cambio nuevo representa un riesgo potencial para los sistemas en producción. La cultura DevOps resuelve este conflicto al crear un ecosistema donde ambos equipos colaboran, comparten responsabilidades y construyen herramientas que hacen los despliegues más seguros y predecibles.

¿Los site reliability engineers programan?

La respuesta es un rotundo sí [02:44]. Los SRE desarrollan y crean herramientas internas que facilitan a los equipos de producto poner sus features en producción de la forma más sencilla posible. No se trata solo de administrar servidores; se trata de automatizar, instrumentar y construir soluciones que mejoren la fiabilidad del sistema.

¿Conviene pasar de desarrollo a SRE o de sysadmin a SRE?

Un punto interesante es la recomendación de Pablo sobre la transición profesional. Según su experiencia, es mucho más fácil enseñarle a un desarrollador sobre sistemas que enseñarle a un sysadmin a programar [01:18]. Esto no significa que un sysadmin no pueda convertirse en SRE, pero el camino suele ser más fluido para quienes ya tienen bases sólidas en programación.

Si te gusta programar y querés moverte hacia roles de infraestructura, tenés una ventaja natural. Ya contás con la mentalidad de resolver problemas mediante código, y solo necesitás sumar conocimientos de sistemas.

¿Qué conocimientos y habilidades necesitás para ser SRE?

Para empezar en un equipo de SRE, los requisitos no son inalcanzables. Del lado de sistemas, necesitás [03:18]:

• Manejar un servidor Linux de forma básica.
• Instalar paquetes y gestionar servicios.
• Trabajar con servidores web y bases de datos.

Estos conocimientos son suficientes para un perfil junior. Un SRE senior obviamente requiere experiencia más profunda, pero como punto de partida es todo lo necesario.

Del lado de programación, el camino recomendado es [03:50]:

• Comenzar con Bash, un lenguaje que permite hacer scripting y automatización básica.
• Avanzar hacia Python o Go, los dos lenguajes más usados en el ecosistema SRE.

Tanto Python como Go cuentan con librerías extensas para integrarse con sistemas de nube y distintos proveedores de infraestructura [04:08]. Esto los convierte en herramientas fundamentales para el trabajo diario de un site reliability engineer.

La alta concurrencia no se resuelve solo con más servidores; requiere una combinación de cultura organizacional, conocimiento técnico y las herramientas adecuadas. Si ya tenés bases en programación o en administración de sistemas, el siguiente paso es entender cómo estas piezas encajan en una arquitectura que soporte tráfico real a gran escala. ¿Qué lenguaje te gustaría aprender primero para este camino?