Principios de cloud native
0 recomendaciones136 vistas
Este documento resume los principios de los Doce Factores para aplicaciones nativas en la nube. Estos factores incluyen tener una sola base de código para cada aplicación, diseñar las APIs primero, gestionar dependencias de forma declarada e aislada, y tratar la configuración, registros y procesos como recursos descartables. También recomiendan escalar horizontalmente para lograr concurrencia, monitorear telemetría, y asegurar los endpoints con controles de acceso basados en roles. El objetivo general es construir aplicaciones que sean altamente
Principios de cloud native
- 16. The ¿Twelve? Factors, Hoy
- 17. I. Una base de código, una aplicación Antes: Una base de código rastreada en control de revisión, muchas implementaciones
- 18. I. Una base de código, una aplicación ● Un repositorio de código fuente o un conjunto de repositorios con una raíz común
- 19. I. Una base de código, una aplicación ● Producir N releases inmutables
- 20. I. Una base de código, una aplicación ● No significa que no está permitido compartir código en varias aplicaciones ○ Código compartido es otra base de código
- 21. I. Una base de código, una aplicación ● Equipos más pequeños a aplicaciones individuales o microservicios
- 22. I. Una base de código, una aplicación Antes: Una base de código rastreada en control de revisión, muchas implementaciones ● Un repositorio de código fuente o un conjunto de repositorios con una raíz común ● Producir N releases inmutables ● Equipos más pequeños a aplicaciones individuales o microservicios ● No significa que no está permitido compartir código en varias aplicaciones ○ Código compartido es otra base de código
- 23. II. API Primero Ecosistema de servicios ● ¿Por qué API primero? ● Dependencias horizontales ● API como un artefacto de primera clase ● Trabajar contra los contratos públicos
- 24. II. API Primero Ecosistema de servicios ● Construir API de servicios primero ● Lo que estás creando es una API para ser consumida ● Requisitos funcionales == Consumo API ● API Blueprint
- 25. III. Gestión de Dependencias
- 26. III. Gestión de Dependencias ● Declaradas
- 27. III. Gestión de Dependencias ● Aisladas
- 28. III. Gestión de Dependencias ● NO asumir nada
- 29. IV. Design, Build, Release, Run
- 30. IV. Design, Build, Release, Run ● Design (enfoque ágil) ● Diseña pequeñas características ● Debe existir diseño de alto nivel ● El desarrollador decide cómo se gestionan las dependencias
- 31. IV. Design, Build, Release, Run ● Build. ● Repositorio de código se convierte en un artefacto binario versionado ● Idealmente creado por un servidor de integración continua ● Hay una relación 1: muchos entre Build y Deployment
- 32. IV. Design, Build, Release, Run ● Release. ● Las versiones deben ser únicas ● Tener fases de build y release separadas, y almacenar esos artefactos
- 33. V. Configuration, Credentials, and Code ● ¿Que varía entre deploys? ●
- 34. V. Configuration, Credentials, and Code ● Química de Configuración
- 35. V. Configuration, Credentials, and Code ● Trata tu Aplicación como Open Source
- 36. VI. Logs ● Los logs deben tratarse como flujos de eventos
- 37. VI. Logs ● escribe todas sus entradas de logs en stdout y stderr.
- 38. VI. Logs ● Delega la gestion de logs a backing services
- 39. VII. Desarrolla para desechar ● Una aplicación es tan efímera como la nube que la Soporta ● Una aplicación no se puede escalar, desplegar o recuperar rápidamente si no es capaz de iniciar rápidamente y cerrar con gracia ● Los tiempos de arranque extremadamente lentos incluso pueden evitar que su aplicación se inicie en la nube
- 40. VIII. Paridad de Ambientes ● Confianza de que la aplicación funcionará en todas partes.
- 41. IX. Backing Services ● servicio en el que su aplicación se basa para su funcionalidad
- 42. IX. Backing Services ● servicio en el que su aplicación se basa para su funcionalidad
- 45. XI. Port Binding ● Evitar el puerto determinado por el contenedor ● Evitar la Microgestión de asignación de puertos ● Las aplicaciones tratadas como Backing Services
- 46. XII. Procesos sin estado ● Las aplicaciones deberían ejecutarse como un proceso único, sin estado.
- 47. XII. Procesos sin estado ● Gestión en caché de estados.
- 48. XIII. Concurrencia ● Escalar Horizontalmente.
- 49. XIII. Concurrencia ● Escalar Horizontalmente.
- 50. XIV. Telemetría ● "Trata tus aplicaciones como sondas espaciales"
- 51. XIV. Telemetría ● Monitoreo del rendimiento de la aplicación (APM) ● Telemetria específica de dominio ● Health & system logs
- 52. XV. Autenticacion y autorizacion ● La seguridad nunca debe ser tema de ultimo momento
- 53. XV. Autenticacion y autorizacion ● Siempre asegurar endpoints con RBAC
- 54. XV. Autenticacion y autorizacion ● Siempre asegurar endpoints con RBAC
- 55. Preguntas?
- 56. Muchas gracias