Migrando a Microservicios

Mi charla en CodeÑuble 2019

Transcript

1. Migrando a microservicios @janogonzalez
2. Monolitos Microservicios Nuestra arquitectura Extrayendo servicios Conclusiones
3. Monolitos
4. $ rails new soundcloud Cómo SoundCloud comenzó Monolitos
5. Monolitos Toda la funcionalidad en un lado User Track Like
6. Monolitos Usualmente organizados en capas Backend DB UI
7. Monolitos Tienden a la especialización por capa
8. Monolitos Tuvimos problemas cuando los equipos crecieron
9. Monolitos Nuestro delivery era muy lento
10. Microservicios
11. Microservicios Bounded contexts User Track Like
12. Microservicios Modelo de dominio que cabe en tu cabeza Like Track Likes Count User Likes Count
13. Microservicios Cada bounded context pertenece a un servicio Likes Service
14. Microservicios Tienden a tener equipos multifuncionales
15. Microservicios Delivery más rápido
16. Microservicios Usar la herramienta más adecuada
17. Microservicios Reemplazabilidad
18. Los requisitos
19. Los requisitos Facilidad para reservar recursos de cómputo
20. Los requisitos Monitoreo
21. Los requisitos Continuous delivery
22. Los problemas
23. Los problemas Fallos en cascada
24. • Circuit breakers • Failure accrual Fallos en cascada Los problemas
25. Los problemas Consistencia eventual (A: a1,a2; B: b1) (A;B) (A;C) (A: a1, a2) (B: b1, b2)
26. • Definir fuentes autoritativas • Componer respuestas en los bordes • Usar eventos de ciclo de vida cuando sea necesario Consistencia eventual Los problemas
27. Los problemas Muchos stacks tecnológicos
28. • Estandarizar mecanismos de RPC y comunicación asíncrona • Proveer niveles de soporte para distintos stacks tecnológicos Muchos stacks tecnológicos Los problemas
29. Los problemas Proteger contra cambios en las APIs
30. • Tolerant readers • Consumer driven contracts Proteger contra cambios en las APIs Los problemas
31. Los problemas Incremento de “chattiness”
32. • API Gateway • BFF Incremento de “chattiness” Los problemas
33. Los problemas Componentes se comunican en la red
34. • Tolerancia a fallos • Comunicación asíncrona Componentes se comunican en la red Los problemas
35. Nuestra arquitectura
36. Vista desde 1000 km de altura Nuestra arquitectura
37. Capas Nuestra arquitectura (idealizada)
38. Extrayendo servicios
39. Identificar candidatos Este feature necesita cambios? Produce riesgo técnico? Escoger un enfoque de integración Cómo integrar el servicio extraído? Escoger un enfoque de migración de datos Cómo mover los datos a su propio storage? Extrayendo servicios El proceso 1 2 3
40. Identificar candidatos Este feature necesita cambios? Produce riesgo técnico? Escoger un enfoque de integración Cómo integrar el servicio extraído? Escoger un enfoque de migración de datos Cómo mover los datos a su propio storage? Extrayendo servicios El proceso 1 2 3
41. Escoger un enfoque de integración Monolito como gateway AN TES Monolith
42. Escoger un enfoque de integración Monolito como gateway Monolith Service Service D ESPU ÉS
43. Introducir capa de servicios para el feature Si ya no la tienes Agregar camino alternativo bajo feature flag Cuidado, se podrían necesitar joins en memoria Mover el tráfico Ahora el código se puede limpiar Monolito como gateway El proceso 2.1 2.2 2.3
44. def index likes = user_likes_service.public_track_likes( @user, pagination) respond collection_for(likes) end Introducir capa de servicios para el feature Monolito como gateway
45. Introducir capa de servicios para el feature Si ya no la tienes Agregar camino alternativo bajo feature flag Cuidado, se podrían necesitar joins en memoria Mover el tráfico Ahora el código se puede limpiar El proceso 2.1 2.2 2.3 Monolito como gateway
46. def public_track_likes(user, pagination) if $feature.active?(:use_likes_service, user) … else … end end Agregar camino alternativo bajo feature flag Monolito como gateway
47. Introducir capa de servicios para el feature Si ya no la tienes Agregar camino alternativo bajo feature flag Cuidado, se podrían necesitar joins en memoria Mover el tráfico Ahora el código se puede limpiar El proceso 2.1 2.2 2.3 Monolito como gateway
48. Strangler Monolith AN TES Escoger un enfoque de integración
49. Strangler Strangler STR AN G LIN G Monolith Escoger un enfoque de integración
50. Strangler Strangler Service Monolith D ESPU ÉS Escoger un enfoque de integración
51. Strangler Strangler Service Service ALG Ú N D ÍA… Service Service Escoger un enfoque de integración
52. Introducir handlers para los paths Esto permite intervención Agregar camino alternativo bajo feature flag Puede implicar no sólo invocar el nuevo servicio Mover el tráfico Ahora el código se puede limpiar Strangler El proceso 2.1 2.2 2.3
53. def index handle(request) end Introducir handlers para los paths Strangler
54. Introducir handlers para los paths Esto permite intervención Agregar camino alternativo bajo feature flag Puede implicar no sólo invocar el nuevo servicio Mover el tráfico Ahora el código se puede limpiar Strangler El proceso 2.1 2.2 2.3
55. def index if $feature.active?(:use_likes_service, @current_user) … else handle(request) end end Agregar camino alternativo bajo feature flag Strangler
56. Introducir handlers para los paths Esto permite intervención Agregar camino alternativo bajo feature flag Puede implicar no sólo invocar el nuevo servicio Mover el tráfico Ahora el código se puede limpiar Strangler 2.1 2.2 2.3 El proceso
57. Identificar candidatos Este feature necesita cambios? Produce riesgo técnico? Escoger un enfoque de integración Cómo integrar el servicio extraído? Escoger un enfoque de migración de datos Cómo mover los datos a su propio storage? Extrayendo servicios El proceso 1 2 3
58. Escoger un enfoque de migración de datos Nuevo schema Monolith AN TES
59. Nuevo schema Monolith M IG R AC IÓ N A Service B Escoger un enfoque de migración de datos
60. Nuevo schema D ESPU ÉS Monolith A Service B Escoger un enfoque de migración de datos
61. • Permite cambiar el motor de storage • Agrega riesgo a la migración • No lo he usado personalmente, más adecuado cuando se requieren cambios de features. Nuevo Escoger un enfoque de migración de datos
62. El mismo schema Monolith AN TES Escoger un enfoque de migración de datos
63. El mismo schema Monolith M IG R AC IÓ N A Service A’ Escoger un enfoque de migración de datos
64. El mismo schema D ESPU ÉS Monolith A Service A’ Escoger un enfoque de migración de datos
65. • Bajo riesgo • Usualmente movemos los lecturas en forma progresiva más un cut-over para las escrituras • Lo hemos escogido para migraciones por riesgo técnico El mismo schema Escoger un enfoque de migración de datos
66. • Sistemas que leían directo desde BDs ajenas • Cut-over de las escrituras • Migrando eventos de ciclo de vida • Outages Extrayendo servicios Detalles omitidos
67. Conclusiones
68. Equipos pequeños y bien concentrados Delivery rápido Conclusiones Razones para migrar
69. Provisioning rápido Monitoreo Deployment pipeline Conclusiones Requisitos para migrar (Fowler)
70. Más partes en movimiento Conclusiones Problemas que se introducen
71. Un feature a la vez Cuando lo necesitas Sin parar el delivery! Conclusions Como romper un monolito
72. Todo es un trade-off! Conclusions Debes hacerlo?
73. Gracias
74. Preguntas