Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Migrando a Microservicios

Migrando a Microservicios

Mi charla en CodeÑuble 2019

Ee64bbdcdeffabc6d4166a96e6d2a0d5?s=128

Jano González

June 07, 2019
Tweet

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