Quarkus: un entorno local para varios servicios
Quarkus ya resolvió la parte que la mayoría de frameworks hace mal: el dev mode recarga al guardar y los Dev Services te levantan un contenedor para la base de datos que se te olvidó arrancar. Lo que no resuelve es el servicio de al lado, ni el siguiente.
Dónde se para el dev mode
- Es por servicio. Cinco servicios son cinco terminales, cinco dev modes y acordarse de qué puerto cogió cada uno.
- Los Dev Services también son por servicio. Cada uno que quiere una base de datos se lleva su propio contenedor. Eso está bien para aislar y está mal para un flujo donde tres servicios leen el mismo topic de Kafka.
- Las URLs entre servicios siguen siendo cosa tuya. Cada
@ConfigPropertyo URL base de un cliente REST que apunta a otro servicio hay que apuntarla a algún sitio cuando no levantas el sistema entero. - El orden sigue importando. La recarga no ayuda si la dependencia no estaba respondiendo cuando arrancó quien la llama.
Qué añade Aseptic
Aseptic detecta un servicio Quarkus por su manifiesto y lo arranca como proceso
nativo con tu herramienta de build, inyectando la configuración al arrancar como
propiedades -D o variables de entorno. Las URLs entre servicios se
reescriben ahí, así que application.properties se queda exactamente
como está en git.
Un escenario es el flujo: los servicios que participan, el orden que necesitan y dónde se resuelve cada dependencia —un servicio local, vuestro entorno compartido en la nube o un mock—. Los puertos que chocan se remapean y el valor nuevo es el que se les cuenta a quienes llaman.
Para la infraestructura común, Aseptic levanta Kafka, Redis y PostgreSQL en Docker una vez, para todo el escenario, y apunta todos los servicios a la misma instancia. Esa es la diferencia con los Dev Services: un broker que comparte el flujo, en vez de uno por servicio. Si para una ejecución concreta prefieres los Dev Services, nada te lo impide: Aseptic arranca tu servicio como tú le digas.
Librerías que estás tocando a la vez
Si la funcionalidad abarca un servicio y una librería tuya, Aseptic construye la librería y la enlaza donde Maven y Gradle la resuelven, reconstruyéndola y reenlazándola al cambiar. El fichero de build del consumidor no se edita nunca, y desenlazar deshace solo lo que puso Aseptic.
Lo que no hace
No sustituye al dev mode, ni debería: recargar al guardar es cosa de Quarkus y lo hace mejor de lo que podría añadir ningún lanzador. No construye imágenes nativas ni ejecuta un clúster de Kubernetes, así que todo lo que necesites verificar a ese nivel es de otro sitio. Y necesita Docker instalado para la infraestructura común.
Está en beta pública, se publica para Windows, macOS y Linux, y es gratis para uso personal.
Al lado de las alternativas
Si tus servicios ya están en contenedor y se despliegan con manifiestos que mantienes, Tilt y Skaffold te dan un bucle con la forma de producción. La página de alternativas a Docker Compose cubre el campo entero.
Hay equivalentes de esta página para Spring Boot y para Node.
Preguntas frecuentes
¿No me basta con el modo dev de Quarkus?
Para un servicio, es excelente. Lo que el modo dev no resuelve es quién arranca a los demás, en qué orden y contra qué: en cuanto el flujo pasa por tres servicios, esa parte sigue siendo tuya.
¿Aseptic rompe la recarga en caliente de Quarkus?
No. El servicio se arranca como proceso nativo con su propio comando, así que la recarga en caliente es la de siempre.
¿Puedo mezclar Quarkus con servicios de otro stack?
Sí. El motor no lleva lógica de una tecnología concreta: cada stack tiene su perfil y en un mismo escenario pueden convivir.