La charla cuestiona la idea de que escalar siempre significa atender millones de usuarios. Para muchos equipos, escalar también es poder trabajar juntos, operar el sistema con confianza y responder a su nivel real de criticidad. Rodríguez Monti propone priorizar los fundamentos de ingeniería y construir sistemas simples, observables, seguros y recuperables antes de adoptar complejidad que el producto todavía no necesita.
Temas
- La escala no es lo mismo que la criticidad
- Primero escala el equipo y la ingeniería
- Usar IA sin perder control del sistema
- Operación: costos, observabilidad y seguridad
- Sistemas pequeños con alta criticidad
- Simplicidad, complejidad y decisiones por etapas
Key takeaways
- La escala incluye la capacidad de que cinco o diez desarrolladores trabajen en el mismo sistema sin bloquearse; no se reduce a atender millones de usuarios.
3:22 - Un producto para 200 usuarios también necesita estar bien hecho, sobre todo si esos usuarios o las operaciones que realizan son críticos.
3:55 - Antes de añadir tecnologías distribuidas, hay que resolver el ABC de ingeniería: flujo de ramas, pruebas, precommits, CI/CD, límites claros y ownership.
9:2511:19 - La IA acelera la escritura, pero no reemplaza la revisión, las pruebas, la seguridad ni a una persona responsable que entienda el código generado.
13:1814:43 - El autoscaling puede reaccionar tarde ante un pico; hacen falta aprovisionamiento acorde, presupuestos, alertas y control de costos de nube y tokens.
8:0916:0616:38 - La observabilidad puede revelar una falla antes de que la note el usuario cuando las trazas permiten seguir una petición a través del sistema.
17:18 - Los sistemas de baja escala y alta criticidad exigen un margen de error pequeño y prácticas para controlar despliegues, amenazas, recuperación, mantenimiento y auditoría.
19:4122:2723:07 - Diseña para el sexto desarrollador antes de optimizar para doce millones de usuarios; agrega complejidad cuando resuelva una necesidad concreta.
24:0426:08