The Twelve-Factor App methodology

JVM MX Meetup Virtual de Abril de 2020

"Twelve-Factor App methodology" por parte de Diana Chávez aka @kodyakckaly.

Se habló de las mejores practicas diseñadas por Heroku para permitir que las aplicaciones se creen con portabilidad y resilencia cuando se implementan en la web.

¿Qué pasa si no tomo en cuenta estas estrategias?

El error más común es que obtienes un proyecto el cual depende de diversos recursos, y cuando un desarrollador quiere instalarlo en su ambiente todos esos recursos se pierden o colapsan por una mala configuración de la aplicación; generando a su vez tiempos altos en desarrollo.

¿Para quién es la plática?

Cualquier persona que construya aplicaciones y las ejecute como un servicio así como las personas que desplieguen y gestionen dichas aplicaciones. (DevOps, operaciones, desarrolladores, ingenieros en sistemas, etc.)

Se transmitió en: https://www.youtube.com/watch?v=6IBB4kFLrjU

Transcript

1. The twelve-factor app Manifiesto desarrollado por diseñadores y creadores de aplicaciones Heroku @javamexico
2. • Formatos declarativos • Contrato claro con el OS =+portabilidad • Despliego en plataformas en la nube • Minimización de diferencias entre entornos • Horizontal Scaling Enfoque para la arquitectura e implementación de aplicaciones en la nube que conserven:
4. ¿Para quién es la metodología? DevOps Ingeniero de Sistemas Desarrolladores Operaciones
5. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
6. I. CODEBASE? Un código base sobre el que hacer el control de versiones y múltiples despliegues App 1 A 1
7. Sistema Distribuido? App
8. App App App
9. Librerías Deploys Codebase Production Staging Developer 1 Developer 2
10. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
11. II. DEPENDENCIES Declarar y aislar explícitamente las dependencias No se depende nunca de la existencia explícita de paquetes instalados en el sistema Maven: pom.xml Gradle: gradle.build
12. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
13. III. CONFIG La cual incluye: Backing Services. Credenciales para servicios externos. Valores de despliegue. Guardar la configuración en el entorno
14. III. CONFIG Guardar la configuración en el entorno $s3->putObject( array( 'Bucket' => ‘Mybucket’, 'Key' => ‘AKIAIHD2H5DLKYTAFGSR’, 'ACL' => 'public-read', 'SourceFile' => $file, 'StorageClass' => 'REDUCED_REDUNDANCY' ) ); Ejemplo:
15. III. CONFIG Guardar la configuración en el entorno AWS::S3::Base.establish_connection!( :access_key_id => ENV['S3_KEY'], :secret_access_key => ENV['S3_SECRET'] ) S3_KEY=‘8N029N81’ S3_SECRET=‘9s83109d3+583493190’ La configuración varía entre despliegues
16. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
17. IV. Backing Services Tratar a los “backing services” como recursos conectables. Cada “backing service” distinto es un recurso Production deploy Recurso Recurso Recurso Recurso
18. IV. Backing Services Arquitectura Hexagonal Conectores
19. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
20. V. BUILD, RELEASE & RUN? Separar completamente la etapa de construcción de la etapa de ejecución Cuando se crea una distribución no se puede modificar posteriormente. Cada distribución debería tener siempre un identificador único. Ejemplo: 2011-04-06-20:32:17 v100 Dependencies Build Run Release deployment configuration
21. Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
22. VI. Processes Ejecutar la aplicación como uno o más procesos sin estado Ejemplo Sticky sessions: Balanceador S1 S2
23. Stateless Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
24. VII. PORT BINDING Publicar servicios mediante asignación de puertos auto-contenidas http / {ports} / URLs de backing services Ports App
25. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
26. VIII. Concurrency Escalar mediante el modelo de procesos En las aplicaciones “twelve-factor”, los procesos son ciudadanos de primera clase. Web 1 Web 2 Worker 1 Worker 2 Worker 3 Clock 1 SCALE
 procesos corriendo Diversidad de carga de trabajo tipo de proceso
27. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
28. IX. Disposability Hacer el sistema más robusto intentando conseguir inicios rápidos y finalizaciones seguras Aplicaciones desechables Minimizar tiempo arranque Responder al SIGTERM desde el gestor de procesos Finalizaciones inesperadas (Hardware, timeout, etc)
29. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
30. Mantener desarrollo, preproducción y producción tan parecidos como sea posible. X. Dev/Prod parity Traditional App Twelve Factor App Time between deploys weeks hours Code authors vs code deployers Different people Same people Dev vs Production environments Divergent As similar as possible
31. Mantener desarrollo, preproducción y producción tan parecidos como sea posible. X. Dev/Prod parity
32. Stateless Port Binding Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Admin processes Logs
33. XI. LOGS Tratar los historiales como una transmisión de eventos Medir comportamiento Formatos de salida Formato texto Un evento por línea No tienen un principio o fin fijo
34. Stateless Port Binding Logs Admin processes Dependencies Codebase Configuration Backing Services Build Release Run Stateless Port Binding Concurrency Disposability Dev/Prod parity Logs Admin processes
35. Ejecutar las tareas de gestión/administración como procesos que solo se ejecutan una vez XII. Admin processes Migraciones scripts Roles NO se deben hacer INSERT directos a la base de datos.
36. Conclusión Básicos Deseables Puedes sobrevivir sin I. I. Codebase II. II. Dependencies III. III. Config IV. VI. Stateless V. VII. Port Binding VI. XII. Admin Processes IX. IV. Backing Services VIII. Concurrency IX. Disposability X. Dev/Prod Parity V. Build Release Run XI. Logs
37. Aplicación twelve factor Mi aplicación web Conclusión
38. @kodyakckaly