Enterprise Java Design Patterns in the Cloud Native Era (Markus Eisele) (z-library.sk, 1lib.sk, z-lib.sk)

Red Hat

Enterprise Java Design Patterns in the Cloud Native Era Building Resilient, Scalable Systems in the Kubernetes Era Markus Eisele

Enterprise Java Design Patterns in the Cloud Native Era by Markus Eisele Copyright © 2026 O’Reilly Media, Inc. All rights reserved. Published by O’Reilly Media, Inc., 141 Stony Circle, Suite 195, Santa Rosa, CA 95401. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Andy Kwan Development Editor: Melissa Potter Production Editor: Aleeya Rahman Copyeditor: Penelope Perkins Cover Designer: Susan Thompson Interior Designer: David Futato Interior Illustrator: Kate Dullea April 2026: First Edition Revision History for the First Edition 2026-04-01: First Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Enterprise Java Design Patterns in the Cloud Native Era, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.

The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. This work is part of a collaboration between O’Reilly and Red Hat. See our statement of editorial independence. 979-8-341-67405-9 [LSI]

Introduction Enterprise Java systems carry real business value, but they also carry real costs. Aging monoliths slow down delivery, increase operational risk, and make it hard to adopt new capabilities like AI or cloud native infrastructure. This report gives you a practical approach to modernization: how to reduce that cost and risk while keeping the business running, and how to build systems that can grow with your organization. Here’s what we’ll cover: Strategy You’ll get a decision-making framework for choosing the right modernization approach for each system. Organization You’ll learn how to organize teams and responsibilities to enable different systems to evolve at different speeds. Migration You’ll learn patterns for incremental modernization. No big- bang rewrites. You’ll see how to modernize piece by piece and reduce risk. Design You’ll learn cloud native patterns for infrastructure concerns and data consistency that solve real problems. Integration You’ll learn how to integrate AI safely, control costs, protect data, and make probabilistic AI work in deterministic enterprise systems. By the end, you’ll have a complete toolkit for modern Enterprise Java architecture.

Acknowledgments Writing books takes a lot more time than reading them, and it requires a lot more people to be successful at it. I am thankful to have had the technical support and creativity of Sahil Kaw, Lydwin Chinnappan, and Narang Dixita Sohanlal for this report, building on the foundation laid by Mark Little, Arun Gupta, and Daniel Bryant in Modern Java EE Design Patterns.

Chapter 1. Strategic Frameworks for Modernization Enterprise Java has evolved from J2EE to Jakarta EE, but Kubernetes, cloud infrastructure, and generative AI demand new approaches. Traditional design patterns no longer fit modern distributed systems. The challenge: enterprise systems now span stable OpenJDK 8 monoliths, containerized modular applications, and AI-powered microservices on GraalVM (a high-performance JVM that compiles Java to native binaries), all running simultaneously. This chapter introduces the “Four-Path Framework” for navigating this complexity and making structured modernization decisions, as shown in Figure 1-1. Start with your main goal (stability and security, cloud agility, performance and velocity, or new capabilities) and follow the path to the appropriate modernization strategy. Each path leads to specific outcomes and technology choices that match your business objectives.

Figure 1-1. The Four-Path Framework Path 1: Maintain (Stability and Security) This path applies to applications that provide business value, have low change frequency, and high rewrite risk. These systems quietly run your business: processing payroll, managing inventory, or handling regulatory reporting. They work, they’re stable, and nobody wants to touch them. Let’s walk through Path 1: Goal Keep the lights on while reducing security risks and compliance drift without code changes. When to choose this path The application has no active development roadmap. Business users are satisfied with current functionality. The cost and risk of rewriting exceeds the value gained. The application runs on legacy Java versions (OpenJDK 8 or 11). You need to maintain compliance and security posture without code changes. Optimized technology strategy Legacy stability: Use Extended Life Support (ELS), which is available from various vendors, for OpenJDK 8/11 to maintain security compliance for aging infrastructure. Edge and API defense: Implement API gateways (Kong, Apigee) and web application firewalls (ModSecurity,

Cloudflare WAF, AWS WAF, Azure WAF, Envoy-based filters) for centralized authentication and virtual patching. Infrastructure control: Deploy service mesh (Istio, Linkerd) for granular traffic management and observability tools for proactive issue detection. Decision logic: If the app runs on OpenJDK 8 or 11 with no functional roadmap, use ELS. The cost of ELS is often lower than the risk-adjusted cost of a rewrite. Path 2: Migrate (Cloud Agility) This path focuses on infrastructure optimization without architectural refactoring, also known as “Lift and Shift.” Take your existing application, containerize it, and run it on Kubernetes. You’re not changing the code architecture, just where and how it runs. Infrastructure modernization delivers real value even without code changes: better resource utilization, faster deployments, and standardized operations. Let’s go through Path 2: Goal Gain operational consistency by moving applications from virtual machines (VMs) to managed containers in Kubernetes. When to choose this path You need to decommission expensive legacy hardware or data centers. You want operational consistency across all applications (legacy and modern).

The application works well but runs on outdated infrastructure. You need better resource utilization and cost optimization. You want to enable GitOps and modern continuous integration, continuous deployment (CI/CD) pipelines. The business needs faster deployment cycles without code risk. You’re consolidating multiple data centers or moving to cloud. The migration process Assessment: Identify dependencies, integrations, and configuration requirements. Containerization: Create a Dockerfile with the right JDK version and startup command. Configuration externalization: Extract hardcoded values into ConfigMaps and Secrets. Health checks: Add HTTP endpoints for liveness and readiness probes. Testing: Deploy to development and verify all integrations. Production deployment: Use blue-green or canary strategies. Technology choices

Runtime and orchestration: Standardize on Kubernetes or OpenShift using Podman/Docker for secure, scalable image builds. Security and config: Manage environments via ConfigMaps and secure Secrets; optionally add a service mesh (Istio/Linkerd) for advanced traffic governance. Automation (CI/CD): Streamline deployments using Tekton, GitLab, or GitHub Actions to ensure a consistent delivery pipeline. Governance and visibility: Centralize image management in Quay/Docker Hub, with Prometheus/Grafana for metrics and ELK/EFK for log analysis. Strategic value Decommission legacy hardware, manage monoliths with the same tools as microservices, and achieve better resource utilization, faster deployments, and automated scaling. Avoid this path if The application has severe performance problems requiring code-level fixes. You need to break down a monolith for team autonomy. The application uses frameworks with unpatchable security vulnerabilities. You’re planning a complete rewrite. The application is tightly coupled to specific hardware, making containerization impractical.

Path 3: Refactor (Performance and Velocity) This is the “modernize” path, which involves changing code to improve performance, reduce technical debt, or break down monoliths. The business case is driven by three factors: cloud costs (traditional Jakarta EE apps need 2–4 GB memory per instance), developer velocity (slow builds and deployments), and technical debt (tightly coupled code that’s hard to test and maintain). Here is what is important for Path 3: Goal Reduce cloud costs and improve developer velocity. Applications should start in seconds, use megabytes (not gigabytes), and deploy multiple times per day. When to choose this path Cloud infrastructure costs are significant and growing. Application startup time is too slow for modern deployment practices. Memory footprint prevents efficient scaling. Developer productivity is hampered by slow build/test/deploy cycles. The codebase has accumulated significant technical debt. You need to break down a monolith for team autonomy. The application uses deprecated Jakarta EE features (EJB, JSF). You want to adopt cloud native patterns (health checks, metrics, configuration).

The business needs faster feature delivery. Migration strategies Big Bang: Rewrite everything at once (risky, only for small apps). Strangler Fig: Gradually replace functionality with new services (safest for large apps). Modular monolith first: Refactor into modules, extract services later if needed. Vertical slice: Migrate one complete business capability end-to-end as proof. Technology choices Runtimes: Evaluate Quarkus when memory footprint, startup time, and Kubernetes-native deployment are key factors; consider prioritizing EAP 8 bootable JAR when preserving existing Jakarta EE code and minimizing migration effort. The right choice depends on your team’s skills, your deployment target, and how much change the application can absorb. Standards: Leverage MicroProfile for microservices- focused specs (health checks, metrics, fault tolerance) or JBoss EAP 8 bootable JAR for full Jakarta EE support with traditional enterprise patterns. Data and API: Use Hibernate Panache to slash database boilerplate and Quarkus REST for reactive, high- throughput service layers. Avoid this path if

The application works fine with acceptable costs. You lack team capacity for multimonth refactoring. The business prioritizes new features over technical improvements. The application is scheduled for retirement within one to two years. Path 2 (Migrate) achieves your goals. The team lacks modern Java framework experience. Path 4: Innovate (New Capabilities) This path is for greenfield development: you’re building something new without legacy constraints. Unlike the other three paths, you are starting fresh with maximum freedom to choose modern architectures, adopt the latest technologies, and optimize for the future. The business case is driven by new revenue opportunities, competitive differentiation, or emerging capabilities. In the age of Kubernetes, this means building modern distributed systems that can scale horizontally, handle failures gracefully, and process data in real time. Event-driven architecture (EDA) is a strong fit when you need to decouple services, handle unpredictable loads, or process data in real time. It works well for systems where services need to react to things that happen rather than wait to be called. That said, EDA adds operational complexity: you need to manage message brokers, handle out-of-order or duplicate events, and reason about eventual consistency. It is a deliberate architectural choice, not a default. Choose it when your scalability or decoupling requirements clearly justify the overhead. Goal

Maximum velocity and scalability. You want to move fast, experiment quickly, and scale to millions of users if the product succeeds. You need architectures that support rapid iteration and can handle unpredictable growth. When to choose this path Building a new product or service from scratch Exploring AI-powered features that could drive new revenue Creating real-time experiences (live dashboards, streaming analytics, collaborative tools) Launching a new business line that needs its own technology stack Experimenting with emerging technologies before committing to them Building internal platforms or developer tools Creating customer-facing applications that need to scale rapidly Developing event-driven systems for complex business processes Key benefits Loose coupling: Services don’t need to know about each other, only about events. Scalability: Events are processed in parallel across multiple instances.

Resilience: If a service is down, events queue up and get processed when it recovers. Audit trail: Events provide a complete history of what happened. Real-time processing: React to events as they happen, not in batch jobs. Technology choices High-volume data streaming (Apache Kafka): Serves as the enterprise’s central nervous system. It provides durable, high-throughput event logs that allow multiple services to process, replay, and analyze data in real time without impacting the source. Intelligent scaling (Knative and serverless): Optimizes resource costs by automatically adjusting compute power. It enables “scale-to-zero” (turning off idle services) and rapid autoscaling during traffic spikes, moving the focus from managing servers to executing code. Avoid this path if You’re not building something new. The team lacks distributed systems experience. The organization is not ready for microservices complexity. The use case doesn’t require this scalability. You need quick delivery. The business case doesn’t justify investment.

The decision navigator matrix in Table 1-1 provides a detailed view of the Four-Path Framework. Use this matrix to match your situation to the appropriate modernization path. Each row represents one of the four paths, showing the main goal that drives the decision, the key outcomes you can expect, and the primary technologies that enable those outcomes.