Meetup Fundamentos de Cloud Native en grupo Software Crafters

2. Cloud Native Chile

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

43. X. Procesos Administrativos

44. X. Procesos Administrativos

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