división del monolito
De monolito a microservicios: el primer servicio en producción el día 20
Cuatrocientas tablas en un esquema y un tren de releases que sale una vez por trimestre porque nadie puede desplegar una parte sola. Nuestros ingenieros, con 25 años largos en producción, lo dividen: el primer servicio el día 20, el resto el día 30.
Envíe hoy el tamaño del repo y su ritmo de releases. En 48 horas sabe dónde están las costuras y cuánto cuesta.
Un repositorio, un esquema, una release por trimestre e imports que dan vueltas en círculo.
- one deployable11 years of commits
- shared schema400+ tables
- release trainquarterly
- circular importscycles
Primer servicio el día 20, la división terminada el día 30
Servicios con su propio esquema y su pipeline, una librería compartida pequeña y despliegues cuando cada equipo esté listo.
- billingGo · own schema
- catalogueGo · own schema
- shared kernellibrary
- deploysper service
Primero se divide el esquema, después se mueve el código
- 01días 1–4
Encontrar las costuras en los datos
Los logs de consultas muestran qué tablas se leen juntas en la misma petición. Ahí están las fronteras, diga lo que diga la estructura de paquetes.
- 02días 3–9
Dividir primero el esquema
Las tablas se separan y los joins que cruzan la frontera desaparecen mientras todo sigue siendo un solo desplegable. Casi todo el riesgo vive en este paso, y aquí todavía es reversible.
- 03días 8–20
Extraer el primer servicio
Tomamos el que tiene menos dependencias entrantes, que casi nunca es el que más molesta a la gente. El día 20 corre en producción detrás de la misma interfaz.
- 04días 18–30
Su propio pipeline, y después el siguiente
El servicio recibe su propio repositorio, su despliegue y su turno de guardia. Los siguientes salen más rápido con el mismo método, y desde el día 30 sus equipos publican sin esperar a ningún tren.
La plataforma mide, los ingenieros eligen el corte
Mapear el acceso conjunto a tablas y el acoplamiento entre módulos
Plataforma
A partir de los logs de consultas y del grafo de llamadas, sobre un periodo que incluya un cierre de mes.
Proponer las costuras
Ambos
La plataforma ordena las candidatas. Un ingeniero contrasta cada una con las fronteras de sus equipos.
Romper los joins que cruzan la frontera
Plataforma
Trabajo mecánico, revisado como pull requests y entregado en piezas pequeñas que su equipo puede seguir.
Elegir qué servicio sale primero
Ingeniero
Esto lo decide la propiedad de los equipos más a menudo que el código.
Fronteras transaccionales
Ingeniero
Donde una transacción cruzaba la costura, decidimos qué pasa si falla y lo dejamos por escrito.
Pipelines, despliegues y guardias
Ambos
Construimos cada pipeline y cada turno con su equipo, para que ellos operen los servicios desde el primer despliegue.
Una costura es correcta cuando casi todos los cambios posteriores a la división tocan un solo lado. Lo medimos antes de dar el trabajo por terminado.
La gente que corta la costura
Nuestros ingenieros llevan más de 25 años entregando código de producción, y para esta división no hay gente mejor. Monolitos en Rails, Django, Spring, .NET, Node, PHP y Go, esquemas de cuatrocientas tablas con una década de joins cruzados: decenas de migraciones. La costura nunca está donde la pone el diagrama de arquitectura, y ellos encuentran la real.
Precio cerrado antes de cortar, y el día en que el primer servicio se despliega por su cuenta entra en el contrato. Un servicio que no coincide con el monolito sobre su tráfico no se acepta.
Lo que preguntan los líderes de ingeniería antes de dividir
¿Con cuántos servicios deberíamos terminar?
Con tantos como equipos tenga para hacerse cargo de ellos, que son menos de los que muestra la presentación de arquitectura. Extraemos el primero, lo ponemos en producción y los datos indican dónde va el siguiente corte. Envíe hoy el repo y reciba el mapa de costuras con precio en 48 horas.
¿Tenemos que reescribir en Go?
Solo donde compensa. Extraer y reescribir son decisiones separadas, y muchos servicios se quedan en su lenguaje original. Donde el monolito quema memoria en Java o Python, reescribir en Go recorta la factura de instancias dentro del mismo calendario. Díganos qué módulos cuestan más de operar.
¿Podemos seguir publicando funcionalidades durante la división?
Sí. El paso que protegemos es la separación del esquema, los días 3–9, y planificamos con usted su calendario de releases alrededor de él. Todo lo demás avanza mientras su equipo publica. Envíe su ritmo de releases y ajustamos el plan a él.
¿Y la base de datos compartida de la que todos advierten?
Por eso el esquema se divide primero. Dos servicios sobre un mismo esquema son un monolito distribuido que falla de maneras peores que el original, y nunca entregamos uno. Pida presupuesto y vea el plan del esquema antes de que se mueva una línea de código.
¿Qué pasa con el código compartido?
Se convierte en una librería versionada con una superficie pequeña. Si esa librería crece en cada sprint, la costura está en el sitio equivocado, y la movemos durante el proyecto, mientras todavía sale barato. Envíe el repo y le señalamos las costuras en 48 horas.
Saque su primer servicio
Denos el tamaño del repo, el ritmo de releases y lo que fuerza el cambio. En 48 horas tiene las costuras, un precio cerrado y una fecha. El día 20 el primer servicio se despliega por su cuenta.
Lee el formulario un ingeniero con 25+ años en producción. La primera pregunta es sobre su ritmo de releases.