Levantar solo parte de los microservicios
Tu sistema tiene doce servicios y tú vas a tocar dos. La máquina puede con doce —a duras penas— pero arrancarlos todos tarda cuatro minutos, se come la memoria y no aporta nada al cambio que estás haciendo. La pregunta no es si se puede recortar: es a dónde llaman los que sí levantas.
El recorte no es el problema; el destino sí
Levantar un subconjunto es trivial en cualquier herramienta: eliges dos y arrancas. Lo que nadie resuelve por ti es lo que pasa cuando uno de esos dos llama a un tercero que ya no está.
Cada dependencia que sale del recorte tiene exactamente tres destinos posibles:
- Local — está levantado aquí al lado. Es el caso fácil y también el que arrastra: si lo levantas, arrastras su propia cola de dependencias.
- La nube — vuestro entorno compartido. Te ahorra levantarlo, a cambio de VPN, de datos que cambian bajo tus pies, y de que si ese entorno está caído, tú también.
- Un mock — perfecto cuando su respuesta no es lo que estás probando. A cambio de mantener el stub.
La decisión es por dependencia, no por entorno. Ahí está la diferencia con casi todo lo demás: no quieres «modo local» o «modo nube», quieres esta llamada al micro que tienes abierto, aquella a la nube y una tercera a un mock, y cambiar de idea a mitad de la tarde.
Por qué un compose no lo distingue
docker compose up bff orders levanta dos servicios, sí. Pero dentro de un
compose todo es un contenedor de la misma red, y las URLs entre ellos
son nombres de servicio de esa red. La configuración de bff dice
http://payments:8081, y payments ahora no existe: obtienes un
fallo de resolución de nombre.
La salida habitual es editar la URL a mano en la configuración de bff —un
repositorio que a menudo no es tuyo—, acordarse de no comitearla, y deshacerlo cuando
quieras probar otra cosa. Multiplicado por servicios y por veces al día, es de donde
sale el LOCAL_SETUP.md de cuarenta pasos.
Lo que se rompe al recortar mal
Dos fallos, y el segundo es mucho peor que el primero:
-
Falla ruidosamente.
connection refusedo un nombre que no resuelve. Molesto, pero honesto: te enteras en el primer intento. - Funciona sin que nadie lo haya decidido. La configuración traía por defecto la URL del entorno compartido, así que la llamada sale a la nube, responde, y todo parece bien. Te enteras el día que esa llamada escribe: una migración, un pedido de prueba, un correo enviado a un cliente real desde tu máquina.
El segundo es el que justifica que esto merezca una decisión explícita en vez de un valor por defecto. Un entorno local que sale a producción por descuido no avisa.
Y un caso que casi todos hacen mal
Si un servicio sí está levantado aquí al lado, la llamada debería ir a él —aunque el fichero de configuración general diga «nube»—. Parece obvio y casi ninguna herramienta lo hace: acabas con un micro arrancado en tu máquina al que su vecino llama por internet. Consume VPN, es más lento, y el día que la VPN se cae tienes un escenario entero en local que no arranca por un servicio que tenías al lado.
La regla correcta: lo que se levanta aquí al lado se llama en local, y la configuración general solo decide sobre lo que no está en el escenario.
Cómo lo resuelve Aseptic
Un escenario es exactamente esto: el subconjunto que quieres levantar, con la decisión tomada para cada dependencia que se sale de él.
- Eliges qué entra. Dos de doce, o los que sean, agrupados por flujo —«Checkout», «Alta de cliente»— y guardados con nombre, para no volver a decidirlo mañana.
- Por cada dependencia eliges destino —local, nube o mock— y el motor
reescribe la URL al arrancar, inyectada como propiedad
-Do variable de entorno. Tus repositorios no se tocan. - Lo que está en el escenario se llama en local por encima de lo que diga el manifiesto: la decisión reciente y específica gana a la general.
- Si las declaraciones se contradicen, el arranque se corta en vez de desempatar en silencio. Dos verdades sobre la misma dependencia es el bug que acaba con el panel diciendo «nube» mientras un micro llama al vecino local.
- El escenario se comparte como fichero autocontenido: quien entra nuevo importa y arranca, sin leerse el documento de nadie.
Cuánto hace falta levantar de verdad
La regla que funciona: solo los servicios que vas a cambiar, más aquellos cuyo comportamiento estás verificando. Todo lo demás es una URL apuntando a otro sitio. En la práctica, la mayoría de las tardes eso son dos o tres servicios de un sistema de doce.
Si al recortar te encuentras con que uno de los dos no arranca, está por qué un microservicio no levanta en local; y si lo que necesitas es sustituir a los que dejas fuera, mockear un servicio que no controlas. El panorama completo, en qué necesita un entorno local de microservicios.
Preguntas frecuentes
¿Puedo levantar solo dos servicios de doce y que el resto siga funcionando?
Sí, pero hace falta decidir a dónde llaman los que sí levantas. Cada dependencia que apunte a un servicio que no está arriba tiene que ir a otro sitio: a tu entorno en la nube o a un mock. Si no se decide, se decide sola y falla.
¿Por qué docker compose no me deja hacer esto sin editar el fichero?
Porque dentro de un compose todo es un contenedor de la misma red y las URLs son nombres de servicio. docker compose up bff orders levanta dos, pero la URL que bff usa para llamar a un tercero sigue apuntando a un nombre que ahora no existe.
¿Qué se rompe cuando recorto mal?
Lo típico es un connection refused hacia un nombre de servicio que ya no está, o peor: una llamada que sale por defecto al entorno compartido sin que nadie lo haya decidido. Lo segundo es peor porque funciona, y no te enteras hasta que escribes en la base de datos de todos.
¿Cuánto de un sistema hace falta levantar de verdad?
Menos de lo que se suele levantar. La regla útil: solo los servicios que vas a cambiar o cuyo comportamiento estás verificando. Todo lo demás es una URL apuntando a otro sitio.