Modernizing Java EE Monoliths: a Roadmap to Scalable Microservices

Legacy Java EE monoliths still power many critical systems, but scaling and evolving them for the cloud can be a major challenge. In this session, I’ll share a practical, step-by-step approach to modernizing monolithic applications into scalable microservices using Jakarta EE, MicroProfile, and cloud-native tools – based on real-life experience from a recent client project undergoing this exact transformation.We’ll cover how to identify service boundaries, isolate functionality using the strangler pattern, and incrementally transition to microservices without disrupting business operations. You’ll see how to improve communication using REST and messaging platforms like Kafka or RabbitMQ, while applying MicroProfile APIs for configuration, health checks, metrics, and resilience. We’ll also explore cloud deployment strategies using containers, Kubernetes, and serverless runtimes like AWS Lambda – ensuring that modernized services are not just modular, but production-ready and scalable. Whether you’re starting your modernization journey or refining your approach, this talk provides a proven, experience-backed roadmap you can apply in your own projects.

Transcript

1. @OndroMih https://omnifish.ee Modernizing Java EE Monoliths A Roadmap to Scalable Microservices Ondro Mihalyi @OndroMih
2. @OndroMih https://omnifish.ee Actionable roadmap to start adoption of microservices Best practices we adopted on our customer’s project Strangler pattern in action on a message-driven architecture What You'll Learn Today Challenges we faced and how we addressed them
3. @OndroMih https://omnifish.ee Single deployment unit - Every change risks entire system Tight coupling - Components can't evolve independently All-or-nothing scaling - Can't scale just what you need Technology lock-in - Stuck with legacy frameworks Operational burden - Large codebase, slow builds Challenges With Legacy Monoliths
4. @OndroMih https://omnifish.ee Microservices Enable Modern Cloud-Native Architecture Independent deployment - Ship services separately Technology flexibility - Choose best tool for each job Team ownership - Clear boundaries and responsibilities Cloud-native ready - Containers, auto-scaling Message-driven - Loose coupling, async communication
5. @OndroMih https://omnifish.ee Benefits Come With Trade-offs Better Scalability, performance, resilience Easier Deployments, development, testing Different Team ownership, orchestration, messaging Complicated Distributed processing, contracts Harder Maintenance, observability, data sync
6. @OndroMih https://omnifish.ee Target Architecture - Distributed Microservices Move from centralized monolith to distributed, message-driven microservices architecture
7. @OndroMih https://omnifish.ee The Monolith Doesn't Disappear Overnight MONOLITH+MICROSERVICE+MICROSERVICE+... All connected via message brokers or APIs Hybrid architecture is the reality Monolith shrinks gradually over time New features go to microservices, both systems coexist for years
8. @OndroMih https://omnifish.ee Safe Migration Through Incremental Replacement Incremental - Replace piece by piece, not big-bang rewrite Parallel running - Old and new systems together Gradual traffic shift Rollback capability - Keep old logic, compare, revert if needed
9. @OndroMih https://omnifish.ee Domain-Driven Design Defines Clear Boundaries Bounded Contexts with Clear Responsibilities Order Service Manages order lifecycle and processing Customer Service Handles customer data and profiles Inventory Service Tracks stock levels and availability Payment Service Processes transactions and billing Preparation Clarify team responsibilities for domains in the Monolith
10. @OndroMih https://omnifish.ee 5-Stage Migration Process 1 Monolith only All handled by monolith 2 Messaging enabled Monolith publishes/consumes messages 3 New service ready Built, tested, deployed 4 Traffic shift Gradually route to new service 5 Decommission Remove old code from monolith Each stage is safe and reversible
11. @OndroMih https://omnifish.ee Strangler Pattern applied 1 Prepare the monolith - monolith publishes to Kafka. Feature toggle to consume messages and call REST services 2 New service - consumes/publishes messages from/to Kafka, replicates and extends the behavior of monolith 4 Gradual traffic shifting - switch toggle to call services and prefer messages from services, fallback to old behavior Safe migration with rollback capability at every step 3 Data migration - initial migration to synchronize services with monolith
12. @OndroMih https://omnifish.ee Modern Java Runtimes Full Jakarta EE, MicroProfile - Embedded GlassFish, OpenLiberty, ... Other - SpringBoot, Micronaut The choice is yours Partial Jakarta EE, MicroProfile - Quarkus, Helidon
13. @OndroMih https://omnifish.ee Frontend Migration Strategies 1 Monolithic Frontend Keep existing frontend, backends split into microservices 2 Microfrontends Frontend components from microservices, served from monolith Each service owns its UI components. Watch for CORS issues . 3 Alternative Frontends Multiple lightweight frontends for specific domains When domains isolated, or for a specific user group or a market
14. @OndroMih https://omnifish.ee Choose the Right Message Broker Kafka Event streaming platform High throughput, distributed Log-based storage Event sourcing support Best For: Frequent updates, analytics, event-driven architectures RabbitMQ Message queuing system Reliable delivery guarantees Flexible routing patterns Complex message workflows Best For: Task queues, guaranteed delivery, request-reply Managed Service Alternatives AWS: SQS/SNS | Azure: Service Bus | Google Cloud: Pub/Sub
15. @OndroMih https://omnifish.ee Kubernetes Manages Service Lifecycle Automatically Liveness Probe Is the service alive? If not → Restart container Readiness Probe Ready for traffic? If not → Remove from load balancer Simple HTTP endpoints - /health/live and /health/ready MicroProfile Health - Standard APIs for Java applications Kubernetes integration - Define health and readiness probes
16. @OndroMih https://omnifish.ee Three Pillars of Understanding Distributed Systems 1 Distributed Logging Aggregate logs from all services into centralized system 2 Correlation IDs Track requests across service boundaries with unique identifiers 3 Distributed Tracing Visualize request flow across services using OpenTelemetry
17. @OndroMih https://omnifish.ee Operational Characteristics Improve Significantly Scalability Horizontal scaling easier, only relevant services scale up Performance Smaller services, less overhead, better throughput Resilience When something fails, rest of the system keeps going Splitting into smaller pieces makes systems more flexible and robust
18. @OndroMih https://omnifish.ee Development Becomes Simpler 1 Deployments Faster, isolated, simpler 2 Tech Stack Choose best tool for the job 3 Testing Isolated services Clear boundaries Easier automation 4 Development Smaller services Smaller services accelerate development velocity Faster develop-build-test cycle
19. @OndroMih https://omnifish.ee Changes How Teams Work Team Responsibility Clear ownership, no shared code between teams Orchestration Docker, Kubernetes, messaging, routing infrastructure required Message-Driven Asynchronous processing becomes default, distributed nature We need to adapt and adopt new tools and paradigms
20. @OndroMih https://omnifish.ee Increased Complexity Distributed Processing Changes need synchronization, flow not visible in code Monitoring Information scattered across services, needs centralization Interoperability Compiler cannot verify contracts, need integration testing Need better tooling and processes to manage complexity
21. @OndroMih https://omnifish.ee Real Costs and Downsides to Consider ! Duplication Multiple repos, CI pipelines, deployment charts ! Data Synchronization Distributed data needs message-based sync ! Observability Information needs to be pulled together from many sources ! Troubleshooting Harder to find issues across many components Complexity produces costs - new tooling and processes
22. @OndroMih https://omnifish.ee Logs Need Centralization Each service logs to its own container → Tedious to analyze distributed logs Centralized Aggregation Tools: Datadog, ELK Stack, CloudWatch Standards help OpenTelemetry, MicroProfile Telemetry
23. @OndroMih https://omnifish.ee Proper Labeling is Crucial Monitoring Complexity Multiple data sources - Dozens of service instances Unified labeling critical - Service, environment, version Aggregation & analysis - Group metrics by dimensions Operational overhead - Expertise required The Solution Proper labeling enables effective metric organization and analysis service: order-service env: production branch: main Without proper labels, logging and metrics become meaningless
24. @OndroMih https://omnifish.ee Operating Costs: Infrastructure 1 More Service Instances 50 small services vs 10 large monoliths 2 Centralized Logging Storage and bandwidth costs for log aggregation 3 Multiple Databases Each service has its own database instance
25. @OndroMih https://omnifish.ee Development Infrastructure Becomes More Complex 1 CI/CD Pipelines One pipeline per service multiplies infrastructure 2 Deployment Configurations Different configurations per service and environment 3 Source Repositories Separate repos or monorepo strategy decision required
26. @OndroMih https://omnifish.ee Actionable Roadmap for Starting Modernization 1 Identify Boundaries Use Domain-Driven Design principles 2 Set Up Broker Choose and deploy message infra 3 Build First Service Extract one bounded context 4 Implement Observability Logging, tracing, metrics from day one 5 Deploy and Monitor Start with low traffic routed to services
27. Thank You! Questions? Jakarta EE Consultancy (migrations, tuning) Enterprise Application Development GlassFish Server Support Jakarta EE Training OmniFish - Jakarta EE Consulting & Support https://omnifish.ee