- Incluso en la era del agentic coding, se espera que la demanda de ingenieros de software aumente; la clave está en la capacidad de operar servicios, no en escribir código
- Escribir código siempre fue la parte fácil; lo verdaderamente difícil es operar sistemas de forma estable durante largos periodos
- Como en los casos del no-code y las hojas de cálculo, incluso los no especialistas pueden crear herramientas, pero la carga de mantenimiento y operación termina exigiendo ingeniería profesional
- Los usuarios no compran software, sino servicios; el buen software debe funcionar de manera invisible
- La excelencia operativa (operational excellence) —uptime, tasa de fallas, velocidad de recuperación, actualizaciones de seguridad— es el núcleo de la competitividad futura
- Como el rol que satisface todas estas exigencias, SRE se está moviendo al centro de la ingeniería de software
SRE apunta a convertirse en el puesto más contratado
- Cuando el código se abarata, gana la excelencia operativa
- Cualquiera puede hacer una demo greenfield, pero para operar un servicio de forma estable se necesita capacidad de ingeniería
- "Todos quieren escribir demos greenfield, pero nadie quiere operar servicios"
- La ingeniería de software no es programación simple, sino gestionar sistemas que cambian con el tiempo
La lección de la era del no-code y las hojas de cálculo
- Joe, del área contable, redujo una tarea repetitiva que le tomaba 10 horas semanales a 1 hora con herramientas no-code y macros en hojas de cálculo
- Al principio el resultado fue claro, pero con el tiempo la complejidad creció rápidamente
- Se acumularon cambios en el entorno de negocio, modificaciones a las reglas contables y problemas de zonas horarias y horario de verano
- Cada semana aparecían nuevos edge cases y se volvió necesario ajustar y corregir continuamente
- Al final, Joe quedó atado al sistema que había construido
- Incluso durante las vacaciones tenía que estar pendiente del sistema, y era difícil transferir su operación a otra persona
- Ejecutar el código y revisar los resultados se convirtió en una fuente de ansiedad y tensión
La enfermedad de la computadora (The Computer Disease)
- Es un concepto nombrado por Feynman: el problema de las computadoras es que invitan a estarles metiendo mano todo el tiempo
- La automatización en sí es divertida, pero existe la trampa de automatizar incluso áreas donde no hace falta y aumentar así la complejidad
- La verdadera carga está en la operación del servicio
- Mantenerlo funcionando de manera estable
- Escalarlo en entornos grandes sin problemas
- Administrarlo de forma continua durante años
- Al prestar un servicio, lo esencial es la estabilidad, confiabilidad y continuidad
Por qué la excelencia operativa es el futuro
- La gente no compra software; contrata un servicio que le resuelva un problema
- A nadie le importa el funcionamiento interno de iCloud; esperan que las fotos siempre se sincronicen automáticamente entre dispositivos
- No importa cómo se hicieron Word, Notion o gDocs; lo esencial es la experiencia de escribir y compartir ideas
- Más que la estructura de la red de pagos, importa que un matcha latte de 7 dólares se pague sin problemas
- El buen software no se nota (funciona de forma natural, sin hacerse presente)
Los desafíos de ingeniería realmente difíciles
- El primer 90% de hacer una demo que funciona es fácil; el 190% restante es lo que de verdad importa
- Preguntas que deben responderse desde la perspectiva operativa:
- ¿Cuál es el uptime?
- ¿Cuál es la tasa de aparición de fallas?
- Cuando ocurre una caída, ¿qué tan rápido es el tiempo de recuperación?
- ¿Se detectan los problemas antes de que el usuario los perciba?
- ¿Se pueden gestionar las dependencias upstream?
- Cuando hay problemas con un proveedor, ¿se detectan antes de que lleguen las quejas de los usuarios?
- ¿Cuánto tiempo toma incorporar ideas propuestas por los usuarios?
- ¿Se evita que los ingenieros rompan los sistemas de los demás?
- ¿Existe un sistema que permita a los ingenieros seguir avanzando sin que la app se convierta en una masa caótica?
- ¿Se puede lidiar con software de una escala que no cabe en la cabeza de una sola persona?
- Si ocurre un problema grande mientras un ingeniero duerme en una zona horaria con 12 horas de diferencia, ¿se arregla antes de que los usuarios abandonen el servicio?
- ¿Es posible recuperarse de fallas propias y de fallas upstream, o se pierden datos importantes?
- ¿Se están aplicando actualizaciones de seguridad de manera constante?
- ¿No hay filtración de datos de usuarios?
- ¿Es confiable?
- ¿Se puede depender de ello?
- ¿Existe evidencia que respalde esa confianza?
- ¿Se puede firmar una garantía legalmente vinculante de que el software funcionará cuando se necesite?
- Estos son los desafíos de ingeniería realmente difíciles, y escribir código es la parte fácil
8 comentarios
La reacción en los comentarios jajajaja, se siente como si hubieran podado solo lo necesario del contenido original~ Lo disfruté mucho
Resultado de la lectura por IA: piiii-piiii-bip... 95% de probabilidad de que sea un blog generado por IA.
jajaja 90 190 jajaja
Jajajajajajaja
¿De qué estás hablando?
Creo que habría sido mejor si también hubiera una explicación de qué es SRE.