Migrando a Microservicios

Slide 1

Slide 1 text

Migrando a microservicios @janogonzalez

Slide 2

Slide 2 text

Monolitos Microservicios Nuestra arquitectura Extrayendo servicios Conclusiones

Slide 3

Slide 3 text

Monolitos

Slide 4

Slide 4 text

$ rails new soundcloud Cómo SoundCloud comenzó Monolitos

Slide 5

Slide 5 text

Monolitos Toda la funcionalidad en un lado User Track Like

Slide 6

Slide 6 text

Monolitos Usualmente organizados en capas Backend DB UI

Slide 7

Slide 7 text

Monolitos Tienden a la especialización por capa

Slide 8

Slide 8 text

Monolitos Tuvimos problemas cuando los equipos crecieron

Slide 9

Slide 9 text

Monolitos Nuestro delivery era muy lento

Slide 10

Slide 10 text

Microservicios

Slide 11

Slide 11 text

Microservicios Bounded contexts User Track Like

Slide 12

Slide 12 text

Microservicios Modelo de dominio que cabe en tu cabeza Like Track Likes Count User Likes Count

Slide 13

Slide 13 text

Microservicios Cada bounded context pertenece a un servicio Likes Service

Slide 14

Slide 14 text

Microservicios Tienden a tener equipos multifuncionales

Slide 15

Slide 15 text

Microservicios Delivery más rápido

Slide 16

Slide 16 text

Microservicios Usar la herramienta más adecuada

Slide 17

Slide 17 text

Microservicios Reemplazabilidad

Slide 18

Slide 18 text

Los requisitos

Slide 19

Slide 19 text

Los requisitos Facilidad para reservar recursos de cómputo

Slide 20

Slide 20 text

Los requisitos Monitoreo

Slide 21

Slide 21 text

Los requisitos Continuous delivery

Slide 22

Slide 22 text

Los problemas

Slide 23

Slide 23 text

Los problemas Fallos en cascada

Slide 24

Slide 24 text

● Circuit breakers ● Failure accrual Fallos en cascada Los problemas

Slide 25

Slide 25 text

Los problemas Consistencia eventual (A: a1,a2; B: b1) (A;B) (A;C) (A: a1, a2) (B: b1, b2)

Slide 26

Slide 26 text

● Definir fuentes autoritativas ● Componer respuestas en los bordes ● Usar eventos de ciclo de vida cuando sea necesario Consistencia eventual Los problemas

Slide 27

Slide 27 text

Los problemas Muchos stacks tecnológicos

Slide 28

Slide 28 text

● Estandarizar mecanismos de RPC y comunicación asíncrona ● Proveer niveles de soporte para distintos stacks tecnológicos Muchos stacks tecnológicos Los problemas

Slide 29

Slide 29 text

Los problemas Proteger contra cambios en las APIs

Slide 30

Slide 30 text

● Tolerant readers ● Consumer driven contracts Proteger contra cambios en las APIs Los problemas

Slide 31

Slide 31 text

Los problemas Incremento de “chattiness”

Slide 32

Slide 32 text

● API Gateway ● BFF Incremento de “chattiness” Los problemas

Slide 33

Slide 33 text

Los problemas Componentes se comunican en la red

Slide 34

Slide 34 text

● Tolerancia a fallos ● Comunicación asíncrona Componentes se comunican en la red Los problemas

Slide 35

Slide 35 text

Nuestra arquitectura

Slide 36

Slide 36 text

Vista desde 1000 km de altura Nuestra arquitectura

Slide 37

Slide 37 text

Capas Nuestra arquitectura (idealizada)

Slide 38

Slide 38 text

Extrayendo servicios

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Escoger un enfoque de integración Monolito como gateway AN TES Monolith

Slide 42

Slide 42 text

Escoger un enfoque de integración Monolito como gateway Monolith Service Service D ESPU ÉS

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Strangler Monolith AN TES Escoger un enfoque de integración

Slide 49

Slide 49 text

Strangler Strangler STR AN G LIN G Monolith Escoger un enfoque de integración

Slide 50

Slide 50 text

Strangler Strangler Service Monolith D ESPU ÉS Escoger un enfoque de integración

Slide 51

Slide 51 text

Strangler Strangler Service Service ALG Ú N D ÍA… Service Service Escoger un enfoque de integración

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

def index handle(request) end Introducir handlers para los paths Strangler

Slide 54

Slide 54 text

Slide 55

Slide 55 text

def index if $feature.active?(:use_likes_service, @current_user) … else handle(request) end end Agregar camino alternativo bajo feature flag Strangler

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Escoger un enfoque de migración de datos Nuevo schema Monolith AN TES

Slide 59

Slide 59 text

Nuevo schema Monolith M IG R AC IÓ N A Service B Escoger un enfoque de migración de datos

Slide 60

Slide 60 text

Nuevo schema D ESPU ÉS Monolith A Service B Escoger un enfoque de migración de datos

Slide 61

Slide 61 text

● 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

Slide 62

Slide 62 text

El mismo schema Monolith AN TES Escoger un enfoque de migración de datos

Slide 63

Slide 63 text

El mismo schema Monolith M IG R AC IÓ N A Service A’ Escoger un enfoque de migración de datos

Slide 64

Slide 64 text

El mismo schema D ESPU ÉS Monolith A Service A’ Escoger un enfoque de migración de datos

Slide 65

Slide 65 text

● 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

Slide 66

Slide 66 text

● Sistemas que leían directo desde BDs ajenas ● Cut-over de las escrituras ● Migrando eventos de ciclo de vida ● Outages Extrayendo servicios Detalles omitidos

Slide 67

Slide 67 text

Conclusiones

Slide 68

Slide 68 text

Equipos pequeños y bien concentrados Delivery rápido Conclusiones Razones para migrar

Slide 69

Slide 69 text

Provisioning rápido Monitoreo Deployment pipeline Conclusiones Requisitos para migrar (Fowler)

Slide 70

Slide 70 text

Más partes en movimiento Conclusiones Problemas que se introducen

Slide 71

Slide 71 text

Un feature a la vez Cuando lo necesitas Sin parar el delivery! Conclusions Como romper un monolito