Microservices or not? A dependency management decision
summary
Company moves a large Java codebase toward a module-first architecture so modules can be built as a monolith or deployed as microservices by swapping dependencies. Example uses Java, Maven, Jakarta / MicroProfile APIs, Quarkus for the service image, Jersey for endpoint tests and TCK-style tests that extend a single domain interfaces test to validate every implementation. Demo splits work into API + implementation + endpoints + HTTP client modules, runs Quarkus integration tests against a built image, and reports ~10–12 modules and 5–6 services in their rollout.
AI-written summary · about
chapters (18)
- 0:00Introduction and speaker background
- 2:19Context of Magnolia’s monolith
- 4:06Why avoid microservices complexity
- 6:15Defining domain interfaces for modules
- 10:29Testing domain interfaces early
- 12:37Implementing module contracts
- 15:06Integrating modules into applications
- 16:32When to consider microservices
- 17:14Creating REST endpoints for microservices
- 20:06Building HTTP clients for modules
- 21:32Packaging microservices with Quarkus
- 22:35Testing microservices effectively
- 24:23Providing development and testing tools
- 25:25Switching dependencies to microservices
- 26:53Deploying modular applications
- 28:40Benefits of modular over microservices
- 37:35Summary of key benefits
- 43:43Final recommendations and Q&A
related talks
02h 51mReactive Microservices with Quarkus
59mMajestic Modular Monoliths
41mCloud Chaos & Microservices Mayhem
57mA New and Open Way to Build Cloud-Native Microservices - MicroProfile
34mLets be Real Quarkus in the Wild
52mWhat Does a Good Microservice Architecture Look Like?
42mMicroservices and Modularity or the difference between treatment and cure!
36mJava: Microservices...decisions, decisions, decisions everywhere