Los Doce Factores: la metodología para construir apps SaaS modernas
The Twelve-Factor App
El manifiesto de los Doce Factores, creado por los desarrolladores de Heroku, define una metodología para construir aplicaciones software-como-servicio (SaaS) que sean portables, escalables y fáciles de desplegar en la nube. Basada en la experiencia con cientos de miles de apps, esta guía establece doce principios que abarcan desde la gestión del código y las dependencias hasta la configuración, los procesos y los logs. Su objetivo es evitar la erosión del software y fomentar el despliegue continuo, minimizando las diferencias entre desarrollo y producción.
La metodología de los doce factores se puede aplicar a aplicaciones escritas en cualquier lenguaje de programación y que utilicen cualquier combinación de servicios de apoyo (base de datos, cola, caché de memoria, etc.).
- nebezb
Sigue siendo increíblemente relevante. Incluso si no lo aplicas, hay mucho que aprender leyendo esto en 15 minutos.
La única queja que tengo con esto es el Capítulo 3: Config [1]
"Almacena la configuración en el entorno", "Credenciales para servicios externos como Amazon S3 o Twitter"
Además de ser un mal consejo, tuvo el efecto de segundo orden de llevar a los desarrolladores a creer que podían poner todos sus secretos de entorno local en archivos ~/.bashrc.
Dejen de hacer esto. Hagan los otros 11.5 factores.
- browningstreet
Realmente pensé que esto sería una demostración de MFA de 12 capas que muestra lo absurdo de nuestras tendencias actuales de MFA, dolorosas e insostenibles.
- dec0dedab0de
Heroku parecía que iba a ser el futuro en aquel entonces. Cada vez que me encuentro luchando por entender alguna tontería en Azure, sueño con el futuro más simple que perdimos.
- sandeepkd
Es interesante cómo esto se sentía tan natural y como la forma correcta de hacer software. Recuerdo a gente refiriéndose a ello como la estrella del norte. Y luego gradualmente la gente se acercó pero lo superó. Personalmente siento que estos conceptos requieren tener una mentalidad generalista, es decir, un arquitecto de aplicaciones. Lo que tenemos hoy en día son muchos ingenieros de producto dentro de los equipos, gestores de producto y dirección. Los ingenieros de producto no siempre tienen suficiente influencia o incentivos para impulsar este tipo de conceptos.
Y aún así, al mismo tiempo, estos conceptos se sienten tan tallados en piedra que de una forma u otra todo el mundo va a seguir descubriéndolos de nuevo.
- theozero
.env tal como lo conocemos está lleno de problemas... ¡PERO! echen un vistazo a varlock (https://varlock.dev) - es gratuito y de código abierto, y realmente hemos modernizado y adaptado la sintaxis familiar (un pequeño DSL encima) para hacerlo mucho mejor.
Tiene validación integrada, seguridad de tipos, composición mediante funciones, carga con plugins, prevención de fugas y mucho más.
- RKearney
El título debería decir (2011)
- mermadicsolutio
Estoy debatiendo el equilibrio entre ventajas y desventajas para la gestión de secretos en mi aplicación también. Almacenarlo es fácil, solo necesitas cifrado y está mayormente bien. Pero entregarlo es complicado. La entrega mediante variables de entorno es simple, seguro, pero puede filtrarse. La otra ruta sería una firma con ámbito de trabajo, pero esto no impide que el trabajo imprima el secreto, solo reduce el radio de explosión.
Pero si eliminas el secreto después de que el trabajo termine o el despliegue esté activo, es prácticamente el mismo resultado.
- imglorp
Buenas prácticas, en su mayoría, pero siento que el modelo 12FA esquivó por completo el estado al definirlo fuera de alcance: "el estado está allí en ese servicio externo, emoji de tres monos".
Sí, pero a veces el estado es el punto central y necesitas gestionarlo tú mismo, y entonces algunos de tus procesos deben ser de factor 9 o 10 como resultado.