En producción, lo mínimo que resuelve el problema
Cada pieza de infraestructura que añado es una pieza que hay que administrar, respaldar, actualizar y entender cuando falla a las tres de la madrugada. En equipos de una persona ese coste no es teórico. Así que la pregunta no es si una herramienta es buena, es qué problema mío resuelve — y si no resuelve ninguno todavía, no entra. La contrapartida es honesta: el día que el problema aparezca, la herramienta entra sin discusión.
Este principio explica por qué no uso Docker, y a la vez es la razón de que hoy sea un hueco real en mi currículum. Las dos cosas son verdad al mismo tiempo. Un criterio que solo produce ventajas no es un criterio, es una excusa.
Dónde se ve4
- Mindundi
SQLite en producción con WAL, synchronous en FULL y copia diaria, en lugar de un servidor de base de datos que nadie iba a administrar
- Mindundi
Trabajo periódico con timers de systemd y operaciones idempotentes, en lugar de un broker de colas
- Ajuntaweb 2.0
PWA descartada con argumento escrito, después de haberla implementado en otro proyecto donde sí tenía sentido
- Ecosistema de nueve aplicaciones con identidad federada
Sin Docker, Redis ni Celery por defecto: criterio escrito y sostenido en nueve aplicaciones en producción