Cómo pasé de backend a SRE
Durante mucho tiempo pensé que mi responsabilidad terminaba en el backend.
Si una API fallaba, el problema tenía que estar en el código: una query mal optimizada, un timeout mal ajustado, un pool de conexiones corto. Ese era todo mi terreno conocido y lo dominaba. Me encontraba bastante cómodo.
Pero… Siempre hay pero, ¿eh? Una noche un endpoint importante se cayó.
A las tres de la madrugada todo parece una mala idea.
Llevábamos horas con el dichoso endpoint que se caía de forma intermitente. Nada reproducible. Nada obvio. El tipo de fallo que te hace desconfiar incluso de tu propio criterio. Yo estaba convencido de que el código estaba bien, pero aun así volví a revisarlo entero. Dos veces. Tres. Buscando ese detalle mínimo que se te escapa cuando estás cansado y quieres creer que el problema es sencillo.
Nada. El servicio seguía cayéndose.
En ese momento yo era desarrollador backend. Mi mundo terminaba en el código.
A las horas un compañero dio con el origen del problema. No era una línea de código. Era una política IAM mal aplicada que estaba limitando un recurso crítico. Algo que yo no había tocado. Algo que, hasta ese momento, ni siquiera consideraba parte de mi responsabilidad.
Al día siguiente no paraba de darle vueltas a una cosa: mis decisiones en código estaban condicionadas por una infraestructura que no controlaba. Y lo peor no era eso. Lo peor era darme cuenta de que había pasado horas pensando que el fallo era mío porque mi forma de pensar se limitaba a mi parcela de trabajo.
Ese fue el primer momento en el que entendí que saber programar bien no era suficiente. Que podía escribir código limpio, probado y eficiente y aun así no entender por qué mis servicios fallaban en producción.
Aquí vino mi primer salto: de backend a cloud engineer
Lo que parece un cambio de rol, resulta una expansión natural de la forma de pensar si salimos de nuestro cubículo. Un cloud Engineer no es un desarrollador que sabe AWS, es un desarrollador que entiende que su código está en producción porque hay una infraestructura que lo permite y lo sostiene, y sabe crearla, manejarla y optimizarla.
El cambio de perspectiva, lo cambia todo. Este primer salto no fue tanto de herramientas, si no de cambiar mi manera de pensar.
- La infraestructura también puede ser código. Un VPC, un bucket de S3 o tus roles de AIM son literalmente código.
- Los pipelines CI/CD te facilitan los despliegues porque hay test, validaciones, análisis o rollbacks automáticos.
- Se termina el tópico de “en mi máquina funciona”. Con contenedores y orquestadores todo funciona en cualquier máquina que siga las reglas.
- Y como cualquier infraestructura, aprendes a entender los límites, costes, latencias, observabilidad, etc.
Si trabajas con equipos de infraestructura separados y los desarrolladores de tu empresa no entienden nada de cómo se despliega a producción lo más probable es que en algún momento te encuentras con un problema gordo provocado por la falta de entendimiento sobre cómo se despliega.
Aquí, el cambio de mentalidad es sutil pero profundo, pasas de construir servicios a construir entornos que los hacen posible.
Mi segundo salto: de Cloud Engineer a SRE
Una de las situaciones más "educativas" que viví fué durante un pico de tráfico que se nos fue de las manos. En mi época de agencia gestionamos mucho grandes clientes y siempre teníamos la vista puesta en fechas señaladas como Black Friday y Navidad, pero en esta ocasión, uno de estos clientes decidió lanzar una promoción sin notificarlo, todo un clásico.
Por aquel entonces mi rol estaba más enfocado a cloud que a SRE puro.
Después de más de media hora de confusión, conseguimos dar con el origen, el autoscaling de clúster había llegado al límite máximo, porque el límite se había configurado como dos meses atrás para ahorrar costes en staging, y bueno, se quedó así en producción.
Lo gracioso, es que la infraestructura sí intentaba escalar, las métricas así lo pedía, el orquestado estaba más que preparado, pero la configuración lo impedía.
El sistema no fallaba por un bug, fallaba porque la responsabilidad no acaba en escribir el código, sino en entender el entorno donde ese código vive.
Podemos echarle la culpa al cliente, por no avisar, pero la realidad es que a día de hoy tenemos la capacidad de convertir cualquier plataforma o web en un entorno monitorizado y fiable.
Ahí es donde desarrollé mi siguiente paso, en convertir los servicios en plataformas robustas, escalables y tolerantes a fallos.
Convertirse en SRE es, en cierto modo, llevar la lógica del desarrollo y la nube al extremo de la fiabilidad. Mientras un Cloud Engineer se centra en construir infraestructura reproducible, el SRE se ocupa de mantenerla observable, escalable y resiliente (aunque en muchas empresas ambos roles se solapan o son el mismo y no pasa nada).
Ahí entra en juego todo lo que un desarrollador ya sabe, pero aplicado a otro plano.
- Automatización: todo lo que se puede repetir, se codifica. Automatizar el escalado horizontal, crear health checks o scripts de recuperación ante fallos.
- Observabilidad: monitorizar los logs, métricas y trazas como primera fuente de verdad. Instrumentar tu código o enviar métricas a Prometheus y visualizar la latencia en Grafana.
- Diseñar fiabilidad medible: saber cuándo un servicio no ha estado disponible. Entender las causas y generar alertas de downtime.
- Postmortem y mejora continua: documentar las causas de los problemas, acciones llevadas a cabo y patrones recurrentes, y luego automatizar las soluciones repetidas.
Pasar de backend a Cloud/SRE no se trata de aprender más herramientas, sino de ampliar el horizonte de responsabilidad, convivir con la idea de que el código corre en una infraestructura que es igual de importante y debe mantenerse fiable la mayor parte del tiempo posible.
Pasar de backend a SRE
La infraestructura no es un detalle técnico, es parte importante del negocio.
Si eres backend y te interesa la infraestructura piensa en ampliar tu radio de acción hacia la nube y la fiabilidad.
Pasar a Cloud Engineer o SRE no es un salto al vacío, es la evolución natural para quien disfruta construyendo plataformas que viven, escalan, fallan, se recuperan.
Puede intimidar al principio, pero en cuanto empiezas a versionar infraestructura, a entender un pipeline y ver tus servicios desde la observabilidad real, descubres que todo lo que parecía un mundo nuevo en realidad es la extensión lógica de lo ya sabes.
Tu experiencia como desarrollador se convierte en tu arma más potente. Piensa siempre que no es un cambio de rol, si no un cambio de perspectiva.
¿Quieres saber un poco más sobre quién ha escrito este artículo? 👇
Soy Cloud Engineer | SRE con experiencia en entornos cloud y arquitecturas AWS, enfocado en automatización, seguridad y eficiencia operativa.
Me apasiona diseñar infraestructuras sólidas, optimizar costes y convertir la complejidad técnica en soluciones claras y mantenibles.