Posts Tagged ‘SpringBoot’
[SpringIO2024] Mind the Gap: Connecting High-Performance Systems at a Leading Crypto Exchange @ Spring I/O 2024
At Spring I/O 2024, Marcos Maia and Lars Werkman from Bitvavo, Europe’s leading cryptocurrency exchange, unveiled the architectural intricacies of their high-performance trading platform. Based in the Netherlands, Bitvavo processes thousands of transactions per second with sub-millisecond latency. Marcos and Lars detailed how they integrate ultra-low-latency systems with Spring Boot applications, offering a deep dive into their strategies for scalability and performance. Their talk, rich with technical insights, challenged conventional software practices, urging developers to rethink performance optimization.
Architecting for Ultra-Low Latency
Marcos opened by highlighting Bitvavo’s mission to enable seamless crypto trading for nearly two million customers. The exchange’s hot path, where orders are processed, demands microsecond response times. To achieve this, Bitvavo employs the Aeron framework, an open-source tool designed for high-performance messaging. By using memory-mapped files, UDP-based communication, and lock-free algorithms, the platform minimizes latency. Marcos explained how they bypass traditional databases, opting for in-memory processing with eventual disk synchronization, ensuring deterministic outcomes critical for trading fairness.
Optimizing the Hot Path
The hot path’s design is uncompromising, as Marcos elaborated. Bitvavo avoids garbage collection by preallocating and reusing objects, ensuring predictable memory usage. Single-threaded processing, counterintuitive to many, leverages CPU caches for nanosecond-level performance. The platform uses distributed state machines, guaranteeing consistent outputs across executions. Lars complemented this by discussing inter-process communication via shared memory and DPDK for kernel-bypassing network operations. These techniques, rooted in decades of trading system expertise, enable Bitvavo to handle peak loads of 30,000 transactions per second.
Bridging with Spring Boot
Integrating high-performance systems with the broader organization poses significant challenges. Marcos detailed the “cold sink,” a Spring Boot application that consumes data from the hot path’s Aeron archive, feeding it into Kafka and MySQL for downstream processing. By batching requests and using object pools, the cold sink minimizes garbage collection, maintaining performance under heavy loads. Fine-tuning batch sizes and applying backpressure ensure the system keeps pace with the hot path’s output, preventing data lags in Bitvavo’s 24/7 operations.
Enhancing JWT Signing Performance
Lars concluded with a case study on optimizing JWT token signing, a “warm path” process targeting sub-millisecond latency. Initially, their RSA-based signing took 8.8 milliseconds, far from the goal. By switching to symmetric HMAC signing and adopting Azul Prime’s JVM, they achieved a 30x performance boost, reaching 260-280 microsecond response times. Lars emphasized the importance of benchmarking with JMH and leveraging Azul’s features like Falcon JIT compiler for stable throughput. This optimization underscores Bitvavo’s commitment to performance across all system layers.
Links:
[DevoxxBE2023] Securing the Supply Chain for Your Java Applications by Thomas Vitale
At Devoxx Belgium 2023, Thomas Vitale, a software engineer and architect at Systematic, delivered an authoritative session on securing the software supply chain for Java applications. As the author of Cloud Native Spring in Action and a passionate advocate for cloud-native technologies, Thomas provided a comprehensive exploration of securing every stage of the software lifecycle, from source code to deployment. Drawing on the SLSA framework and CNCF research, he demonstrated practical techniques for ensuring integrity, authenticity, and resilience using open-source tools like Gradle, Sigstore, and Kyverno. Through a blend of theoretical insights and live demonstrations, Thomas illuminated the critical importance of supply chain security in today’s threat landscape.
Safeguarding Source Code with Git Signatures
Thomas began by defining the software supply chain as the end-to-end process of delivering software, encompassing code, dependencies, tools, practices, and people. He emphasized the risks at each stage, starting with source code. Using Git as an example, Thomas highlighted its audit trail capabilities but cautioned that commit authorship can be manipulated. In a live demo, he showed how he could impersonate a colleague by altering Git’s username and email, underscoring the need for signed commits. By enforcing signed commits with GPG or SSH keys—or preferably a keyless approach via GitHub’s single sign-on—developers can ensure commit authenticity, establishing a verifiable provenance trail critical for supply chain security.
Managing Dependencies with Software Bills of Materials (SBOMs)
Moving to dependencies, Thomas stressed the importance of knowing exactly what libraries are included in a project, especially given vulnerabilities like Log4j. He introduced Software Bills of Materials (SBOMs) as a standardized inventory of software components, akin to a list of ingredients. Using the CycloneDX plugin for Gradle, Thomas demonstrated generating an SBOM during the build process, which provides precise dependency details, including versions, licenses, and hashes for integrity verification. This approach, integrated into Maven or Gradle, ensures accuracy over post-build scanning tools like Snyk, enabling developers to identify vulnerabilities, check license compliance, and verify component integrity before production.
Thomas further showcased Dependency-Track, an OWASP project, to analyze SBOMs and flag vulnerabilities, such as a critical issue in SnakeYAML. He introduced the Vulnerability Exploitability Exchange (VEX) standard, which complements SBOMs by documenting whether vulnerabilities affect an application. In his demo, Thomas marked a SnakeYAML vulnerability as a false positive due to Spring Boot’s safe deserialization, demonstrating how VEX communicates security decisions to stakeholders, reducing unnecessary alerts and ensuring compliance with emerging regulations.
Building Secure Artifacts with Reproducible Builds
The build phase, Thomas explained, is another critical juncture for security. Using Spring Boot as an example, he outlined three packaging methods: JAR files, native executables, and container images. He critiqued Dockerfiles for introducing non-determinism and maintenance overhead, advocating for Cloud Native Buildpacks as a reproducible, secure alternative. In a demo, Thomas built a container image with Buildpacks, highlighting its fixed creation timestamp (January 1, 1980) to ensure identical outputs for unchanged inputs, enhancing security by eliminating variability. This reproducibility, coupled with SBOM generation during the build, ensures artifacts are both secure and traceable.
Signing and Verifying Artifacts with SLSA
To ensure artifact integrity, Thomas introduced the SLSA framework, which provides guidelines for securing software artifacts across the supply chain. He demonstrated signing container images with Sigstore’s Cosign tool, using a keyless approach to avoid managing private keys. This process, integrated into a GitHub Actions pipeline, ensures that artifacts are authentically linked to their creator. Thomas further showcased SLSA’s provenance generation, which documents the artifact’s origin, including the Git commit hash and build steps. By achieving SLSA Level 3, his pipeline provided non-falsifiable provenance, ensuring traceability from source code to deployment.
Securing Deployments with Policy Enforcement
The final stage, deployment, requires validating artifacts to ensure they meet security standards. Thomas demonstrated using Cosign and the SLSA Verifier to validate signatures and provenance, ensuring only trusted artifacts are deployed. On Kubernetes, he introduced Kyverno, a policy engine that enforces signature and provenance checks, automatically rejecting non-compliant deployments. This approach ensures that production environments remain secure, aligning with the principle of validating metadata to prevent unauthorized or tampered artifacts from running.
Conclusion: A Holistic Approach to Supply Chain Security
Thomas’s session at Devoxx Belgium 2023 provided a robust framework for securing Java application supply chains. By addressing source code integrity, dependency management, build reproducibility, artifact signing, and deployment validation, he offered a comprehensive strategy to mitigate risks. His practical demonstrations, grounded in open-source tools and standards like SLSA and VEX, empowered developers to adopt these practices without overwhelming complexity. Thomas’s emphasis on asking “why” at each step encouraged attendees to tailor security measures to their context, ensuring both compliance and resilience in an increasingly regulated landscape.
Links:
[DevoxxBE2023] REST Next Level: Crafting Domain-Driven Web APIs by Julien Topçu
At Devoxx Belgium 2023, Julien Topçu, a technical coach at Shadow, delivered a compelling session on elevating REST APIs by embedding domain-driven design principles. With a rich background in crafting software using Domain-Driven Design (DDD), Extreme Programming, and Kanban, Julien illuminated the pitfalls of traditional REST implementations and proposed a transformative approach to encapsulate business intent within APIs. His talk, centered around a fictional space travel booking system, demonstrated how to align APIs with user actions, preserve business workflows, and enhance consumer experience through hypermedia controls. Through a blend of theoretical insights and practical demonstrations, Julien showcased a methodology to create APIs that are not only functional but also semantically rich and workflow-driven.
The Pitfalls of Traditional REST APIs
Julien began by highlighting a pervasive issue in software architecture: the loss of business intent when translating domain logic into REST APIs. Typically, business logic resides in the backend to avoid duplication across consumers like web or mobile applications. However, REST’s uniform interface, with its limited vocabulary of CRUD operations (Create, Read, Update, Delete), often distorts this logic. For instance, in a train reservation system, a user’s intent to “search for trains” is reduced to “create a search resource,” stripping away domain-specific semantics like destinations or schedules. This mismatch, Julien argued, stems from REST’s standardized approach, formalized by Roy Fielding in his PhD thesis, which prioritizes simplicity over application-specific needs. As a result, APIs lose expressiveness, forcing consumers to reconstruct business workflows, leading to what Julien termed “accidental complexity of adaptation.”
To illustrate, Julien presented a scenario where a user performs a search for space trains from Earth to the Moon. The traditional REST API translates this into a POST request to create a search resource, devoid of domain context. This not only obscures the user’s intent but also couples consumers to the backend’s implementation, making changes—like switching from “bound” to “journey index” for multi-destination trips—disruptive. Julien’s live demo underscored this fragility: altering a request parameter broke the API, highlighting the risks of tight coupling between consumers and backend models.
Encapsulating Business Intent with Semantic Endpoints
To address these shortcomings, Julien proposed aligning REST endpoints with user actions rather than backend models. Instead of exposing implementation details, such as updating a sub-resource like “selection” within a search, APIs should reflect behaviors like “select a space train with a fare.” This approach involves using classifiers in URLs, such as POST /searches/{id}/spacetrains/{number}/fares/{code}/select, which clearly convey the intent of selecting a fare for a specific train. Julien emphasized that this does not violate REST principles, debunking the myth that verbs in URLs are forbidden. As long as verbs align with HTTP methods (e.g., POST for creating a resource), they enhance semantic clarity without breaking the uniform interface.
This shift decouples consumers from the backend’s internal structure. For example, changing the backend’s data model (e.g., using booleans instead of a selection object) no longer impacts consumers, as the API exposes behaviors rather than state. Julien’s demo further showcased this by demonstrating how a frontend could adapt to backend changes (e.g., from “bound” to “journey index”) without modification, thanks to semantic endpoints. This approach not only preserves business intent but also simplifies consumer logic, reducing the cognitive load of interpreting CRUD-based APIs.
Encapsulating Workflows with Hypermedia Controls
A critical challenge Julien addressed is the lack of workflow definition in traditional REST APIs. Typically, consumers must hardcode business workflows, such as the sequence of selecting outbound and inbound trains before booking. This leads to duplicated logic and potential errors, like displaying a booking button prematurely. Julien introduced hypermedia controls, specifically HATEOAS (Hypermedia As The Engine Of Application State), as a solution. By embedding links in API responses, the backend can guide consumers through the workflow dynamically.
In his demo, Julien showed how a search response includes links like select-outbound and all-inbounds, which guide the consumer to the next valid actions. For instance, after selecting an outbound train, the response provides a link to select an inbound train, ensuring only compatible options are available. This encapsulation of workflow logic in the backend eliminates the need for consumers to understand the sequence of actions, reducing errors and enhancing maintainability. Julien highlighted that this approach, part of the Richardson Maturity Model’s Level 3, makes APIs discoverable and resilient to backend changes, as consumers rely on links rather than hardcoded URLs.
Practical Implementation and Limitations
Julien’s live coding demo brought these concepts to life, showcasing a Spring Boot backend in Kotlin that dynamically generates links based on the application state. For example, the create-booking link only appears when the selection is complete, ensuring consumers cannot book prematurely. This dynamic guidance, facilitated by Spring HATEOAS, allows the frontend to display UI elements like the booking button based solely on available links, streamlining development and enhancing user experience.
However, Julien acknowledged limitations. For complex forms requiring extensive user input, the hypermedia approach may need supplementation with predefined payloads, as consumers must know what data to send. Additionally, long URLs, while not a practical issue in Julien’s experience at Expedia, could pose challenges in some contexts. Despite these constraints, the approach excels in domains with well-defined workflows, offering a robust framework for building expressive, maintainable APIs.
Conclusion: A New Paradigm for REST APIs
Julien’s session at Devoxx Belgium 2023 offered a transformative vision for REST APIs, emphasizing the power of domain-driven design and hypermedia controls. By aligning endpoints with user actions, encapsulating behaviors, and guiding workflows through links, developers can create APIs that are both semantically rich and resilient to change. This approach not only enhances consumer experience but also aligns with the principles of DDD, ensuring that business intent remains at the forefront of API design. Julien’s practical insights and engaging demo left attendees inspired to rethink their API strategies, fostering a deeper appreciation for REST’s potential when infused with domain-driven principles.
Links:
[SpringIO2023] Managing Spring Boot Application Secrets: Badr Nass Lahsen
In a compelling session at Spring I/O 2023, Badr Nass Lahsen, a DevSecOps expert at CyberArk, tackled the critical challenge of securing secrets in Spring Boot applications. With the rise of cloud-native architectures and Kubernetes, secrets like database credentials or API keys have become prime targets for attackers. Badr’s talk, enriched with demos and real-world insights, introduced CyberArk’s Conjur solution and various patterns to eliminate hard-coded credentials, enhance authentication, and streamline secrets management, fostering collaboration between developers and security teams.
The Growing Threat to Application Secrets
Badr opened with alarming statistics: in 2021, software supply chain attacks surged by 650%, with 71% of organizations experiencing such breaches. He cited the 2022 Uber attack, where a PowerShell script with hard-coded credentials enabled attackers to escalate privileges across AWS, Google Suite, and other systems. Using the SALSA threat model, Badr highlighted vulnerabilities like compromised source code (e.g., Okta’s leaked access token) and build processes (e.g., SolarWinds). These examples underscored the need to eliminate hard-coded secrets, which are difficult to rotate, track, or audit, and often exposed inadvertently. Badr advocated for “shifting security left,” integrating security from the design phase to mitigate risks early.
Introducing Application Identity Security
Badr introduced the concept of non-human identities, noting that machine identities (e.g., SSH keys, database credentials) outnumber human identities 45 to 1 in enterprises. These secrets, if compromised, grant attackers access to critical resources. To address this, Badr presented CyberArk’s Conjur, an open-source secrets management solution that authenticates workloads, enforces policies, and rotates credentials. He emphasized the “secret zero problem”—the initial secret needed at application startup—and proposed authenticators like JWT or certificate-based authentication to solve it. Conjur’s attribute-based access control (ABAC) ensures least privilege, enabling scalable, auditable workflows that balance developer autonomy and security requirements.
Patterns for Securing Spring Boot Applications
Through a series of demos using the Spring Pet Clinic application, Badr showcased five patterns for secrets management in Kubernetes. The API pattern integrates Conjur’s SDK, using Spring’s @Value annotations to inject secrets without changing developer workflows. The Secrets Provider pattern updates Kubernetes secrets from Conjur, minimizing code changes but offering less security. The Push-to-File pattern stores secrets in shared memory, updating application YAML files securely. The Summon pattern uses a process wrapper to inject secrets as environment variables, ideal for apps relying on such variables. Finally, the Secretless Broker pattern proxies connections to resources like MySQL, hiding secrets entirely from applications and developers. Badr demonstrated credential rotation with zero downtime using Spring Cloud Kubernetes, ensuring resilience for critical applications.
Enhancing Kubernetes Security and Auditing
Badr cautioned that Kubernetes secrets, being base64-encoded and unencrypted by default, are insecure without etcd encryption. He introduced KubeScan, an open-source tool to identify risky roles and permissions in clusters. His demos highlighted Conjur’s auditing capabilities, logging access to secrets and enabling security teams to track usage. By centralizing secrets management, Conjur eliminates “security islands” created by disparate tools like AWS Secrets Manager or Azure Key Vault, ensuring compliance and visibility. Badr stressed the need for a federated governance model to manage secrets across diverse technologies, empowering developers while maintaining robust security controls.
Links:
[SpringIO2023] Going Native: Fast and Lightweight Spring Boot Applications with GraalVM
At Spring I/O 2023 in Barcelona, Alina Yurenko, a developer advocate at Oracle Labs, captivated the audience with her deep dive into GraalVM Native Image support for Spring Boot 3.0. Her session, a blend of technical insights, live demos, and community engagement, showcased how GraalVM transforms Spring Boot applications into fast-starting, lightweight native executables that eliminate the need for a JVM. By leveraging GraalVM’s ahead-of-time (AOT) compilation, developers can achieve significant performance gains, reduced memory usage, and enhanced security, making it a game-changer for cloud-native deployments.
GraalVM: Beyond a Traditional JDK
Alina began by demystifying GraalVM, a versatile platform that extends beyond a standard JDK. While it can run Java applications using the OpenJDK HotSpot VM with an optimized Graal compiler, the spotlight was on its Native Image feature. This AOT compilation process converts a Spring Boot application into a standalone native executable, stripping away runtime code loading and compilation. The result? Applications that start in fractions of a second and consume minimal memory. Alina emphasized that GraalVM’s ability to include only reachable code—application logic, dependencies, and necessary JDK classes—reduces binary size and enhances efficiency, a critical advantage for cloud environments where resources are costly.
Performance and Resource Efficiency in Action
Through live demos, Alina illustrated GraalVM’s impact using the Spring Pet Clinic application. On her laptop, the JVM version took 1.5 seconds to start, while the native executable launched in just 0.3 seconds—a fivefold improvement. The native version was also significantly smaller, at roughly 50 MB without compression, compared to the JVM’s bulkier footprint. To stress-test performance, Alina ran a million requests against a simple Spring Boot app, comparing JVM and native modes. The JVM achieved 80k requests per second, while the native image hit 67k. However, with profile-guided optimizations (PGO), which mimic JVM’s runtime profiling at build time, the optimized native version reached 81k requests per second, rivaling JVM peak throughput. These demos underscored GraalVM’s ability to balance startup speed, low memory usage, and competitive throughput.
Security and Compact Packaging
Alina highlighted GraalVM’s security benefits, noting that native images eliminate runtime code loading, reducing attack vectors like those targeting just-in-time compilation. Only reachable code is included, minimizing the risk of unused dependencies introducing vulnerabilities. Dynamic features like reflection require explicit configuration, ensuring deliberate control over runtime behavior. On packaging, Alina showcased how native images can be compressed using tools like UPX, achieving sizes as low as a few megabytes, though she cautioned about potential runtime decompression trade-offs. These features make GraalVM ideal for deploying compact, secure applications in constrained environments like Kubernetes or serverless platforms.
Practical Integration with Spring Boot
The session also covered GraalVM’s seamless integration with Spring Boot 3.0, which graduated Native Image support from the experimental Spring Native project to general availability in November 2022. Spring Boot’s AOT processing step optimizes applications for native compilation, reducing reflective calls and generating configuration files for GraalVM. Alina demonstrated how Maven and Gradle plugins, along with the GraalVM Reachability Metadata Repository, simplify builds by automatically handling library configurations. For developers, this means minimal changes to existing workflows, with tools like the tracing agent and Spring’s runtime hints easing the handling of dynamic features. Alina’s practical advice—develop on the JVM for fast feedback, then compile to native in CI/CD pipelines—resonated with attendees aiming to adopt GraalVM.
Links:
[SpringIO2023] Anatomy of a Spring Boot App with Clean Architecture: Steve Pember
In a thought-provoking session at Spring I/O 2023, Steve Pember, a seasoned developer from Boston-based startup Stavi, explored the principles of Clean Architecture and their application within Spring Boot applications. Drawing from Robert Martin’s influential book, Steve demonstrated how Clean Architecture, inspired by patterns like Ports and Adapters and Hexagonal Architecture, fosters readable, flexible, and maintainable codebases. Through a reference application and practical insights, he provided a roadmap for developers to structure Spring Boot apps that remain resilient to change and scalable for large teams.
The Case for Software Architecture
Steve began by addressing the often-misunderstood role of software architecture, challenging the stereotype of architects as mere whiteboard enthusiasts. He likened software architects to their building counterparts, who design every detail from high-level structures to minute specifics. Without proper architecture, Steve warned, systems devolve into unmaintainable “big balls of mud,” slowing development and hindering competitiveness. He highlighted the benefits of well-architected systems—separation of concerns, modularity, testability, and maintainability—arguing that these guardrails enable teams to maintain velocity over time, even if they initially slow development.
Principles of Clean Architecture
Delving into Clean Architecture, Steve outlined its core concepts: SOLID principles, component design, boundaries, and dependency rules. He clarified SOLID principles, such as single responsibility (supporting one user type per class) and dependency inversion (using interfaces), as foundational to clean code. Components, he explained, should be independently developable and loosely coupled, aligning with domain-driven design or microservices. The defining feature of Clean Architecture is its layered structure, where dependencies point inward to a core of business logic, encapsulated by interfaces that shield it from external details like databases or third-party services. This ensures the core remains agnostic, enhancing flexibility and testability.
Implementing Clean Architecture in Spring Boot
Steve demonstrated how to apply Clean Architecture in Spring Boot using a reference shoe store application. He proposed a multi-module structure with three components: core (housing business logic, entities, and services), details (containing database and third-party integrations), and app (where Spring configuration and integration occur). By using interfaces for repositories and gateways, the core remains independent of external systems, allowing seamless swaps, such as replacing a PostgreSQL repository with DynamoDB. Steve emphasized minimal controllers and service classes, advocating for specific, single-responsibility services like CustomerOrderQueryService. He also highlighted the importance of integration tests, using tools like Testcontainers to validate interactions with external systems.
Treating Details as Deferrable
A key takeaway was Steve’s mantra that “everything not in core is a detail.” Databases, environments, input mechanisms, and even Spring itself should be treated as implementation details, deferrable until necessary. He cautioned against premature database schema design, urging developers to prioritize business logic over storage concerns. By encapsulating details behind interfaces, applications become adaptable to changes, such as switching databases or input methods (e.g., HTTP to Kafka). Steve’s demo showcased this flexibility, swapping a PostgreSQL order repository for DynamoDB with minimal code changes, proving the power of Clean Architecture’s plug-in approach.
Links:
[SpringIO2022] Major Migrations Made Easy with OpenRewrite
Tim te Beek’s Spring I/O 2022 session introduced OpenRewrite, a powerful tool for automating large-scale Java migrations. As a Java consultant at JDriven, Tim shared his passion for updating outdated technology stacks, using OpenRewrite to streamline upgrades across frameworks, libraries, and languages. His talk, delivered on his birthday, combined a compelling narrative with a live demo, showcasing how OpenRewrite transforms tedious migrations into quick, safe operations.
The Migration Challenge: Keeping Up with Open Source
Tim opened with a decade-long perspective on Java and Spring evolution, from Spring Framework 2.5 in 2009 to Java 17 and Spring Boot 2 in 2022. Each release—Java 8’s lambdas, Spring Boot’s reduced boilerplate, JUnit 5, or Java 11’s JAX-B dependencies—introduced valuable features but required manual upgrades across multiple services. Vulnerabilities like Log4Shell further necessitate rapid migrations, often under pressure. For large organizations with thousands of services, manual updates are impractical, making automation essential.
OpenRewrite addresses this by leveraging an abstract syntax tree (AST) to perform precise, safe refactorings. Unlike simple search-and-replace, it understands code context, preserving formatting and ensuring functional integrity. Tim emphasized its ability to handle migrations like JUnit 4 to 5, Log4j to SLF4J, or Spring Boot 1 to 2, reducing technical debt in minutes.
How OpenRewrite Works: Recipes and AST Magic
OpenRewrite’s core strength lies in its recipe-based approach. Recipes are modular, reusable transformations—implemented as Java visitors—that modify the AST. Tim explained how recipes range from simple (changing imports) to complex (converting JUnit 4’s expected exceptions to JUnit 5’s assertThrows). These can be combined into modules for tasks like framework upgrades or style enforcement. The tool supports Java, Groovy, YAML, and XML, enabling changes to Maven/Gradle builds and Spring configurations.
A key differentiator is OpenRewrite’s type attribution and format preservation, ensuring changes blend seamlessly with existing code. Tim’s demo illustrated this by migrating a Spring Pet Clinic project from Spring Boot 1.5 (Java 8) to Spring Boot 2.5 (Java 17). Using Maven’s OpenRewrite plugin, he applied recipes to update dependencies, imports, annotations, and properties, completing the migration in under 15 seconds per step, with only two minor test failures requiring manual fixes.
Spring Boot Migrator: Enhancing OpenRewrite
Tim introduced Spring Boot Migrator, an experimental Spring project built on OpenRewrite, designed to simplify migrations to Spring Boot. Initiated by VMware Labs in 2020 and led by Fabian Krüger, it offers an opinionated API for Spring-specific migrations, such as Java EE to Spring or NetWeaver to Spring Integration. Unlike OpenRewrite’s fully automated recipes, Spring Boot Migrator provides an interactive workflow, generating HTML reports to guide developers through component identification and transformation steps.
Looking ahead, Spring Boot Migrator aims to support Spring Framework 6 and Spring Boot 3, expected in November 2022, and facilitate cloud migrations to GraalVM. Tim encouraged community contributions, noting its role in easing enterprise migrations for VMware customers.
Impact and Community: Scaling Automation
OpenRewrite’s open-source model, backed by Moderne, ensures all recipes are Apache-licensed, fostering community-driven development. Tim highlighted its use in fixing static analysis issues (e.g., Checkstyle, Sonar), enforcing code style, and contributing to open-source projects like WireMock and Apache Maven. He shared his experience migrating thousands of unit tests, urging attendees to explore OpenRewrite’s web interface (app.moderne.io) and contribute recipes.
Tim’s talk inspired developers to embrace automation, reducing migration pain and enabling focus on innovation. His enthusiasm for OpenRewrite’s potential to transform development workflows resonated strongly with the audience.
Links:
[SpringIO2022] Cloud-Native Healthcare Data Integration with Dapr
Jake Smolka’s Spring I/O 2022 talk offered a compelling case study on building a cloud-native healthcare data integration platform using Dapr, the Distributed Application Runtime. As a health information specialist, Jake shared his journey transforming a Spring Boot prototype into a Kubernetes-based microservice architecture, leveraging Dapr to simplify complexity. His session blended domain insights with technical depth, appealing to both microservice novices and seasoned developers.
Healthcare Data: The Complexity of Interoperability
Jake began with a primer on healthcare data, emphasizing its role in improving clinical outcomes. Clinical data, like blood pressure readings, supports primary care (e.g., diagnoses) and secondary use (e.g., research in university hospitals). However, interoperability remains a challenge due to legacy systems and incompatible standards. Hospitals often manage decades-old data alongside modernized systems, complicating data exchange between clinics. Jake highlighted two standards: OpenEHR, which focuses on semantic interoperability through clinical modeling, and FHIR, designed for lean data exchange. In Catalonia, where the conference was held, public healthcare is shifting to OpenEHR, underscoring its growing importance.
The complexity arises from mismatched standards and real-world data deviations, as illustrated by a colleague’s meme about idealized specifications versus chaotic reality. Jake’s project, FireConnect, aims to bridge OpenEHR and FHIR, enabling bidirectional data mapping for reusable clinical concepts like medication dosages or growth charts. This domain knowledge set the stage for the technical challenges of building a scalable, interoperable solution.
From Prototype to Microservices: The Spring Boot Journey
Jake recounted FireConnect’s evolution, starting as a monolithic Spring Boot application written in Kotlin with Apache Camel for integration. This prototype validated the concept of mapping clinical data but lacked scalability and future-proofing. Stakeholders soon demanded cloud-native features, agnostic deployment, and customer flexibility. Jake adopted Spring Cloud to introduce microservices, incorporating service discovery, load balancing, and distributed configuration. However, the resulting architecture grew unwieldy, with complex internal dependencies (illustrated by a “horror show” diagram). He found himself spending more time managing infrastructure—Kafka, resiliency, and configurations—than writing business logic.
Spring Cloud’s JVM-centric nature limited its agnosticism in mixed-language environments, and its binders (e.g., for Kafka or RabbitMQ) introduced dependencies. Jake realized that while Spring Cloud suited homogeneous Spring ecosystems, FireConnect needed a more flexible, infrastructure-agnostic solution to meet diverse customer needs and simplify development.
Dapr: Streamlining Distributed Systems
Enter Dapr, a Cloud Native Computing Foundation project that abstracts microservice complexities through a sidecar model. Jake introduced Dapr’s building blocks—state management, pub/sub, service invocation, and more—accessible via a simple HTTP/gRPC API. These pluggable components allow applications to switch backends (e.g., RabbitMQ to AWS SQS) without code changes, supporting any language or framework. Dapr’s sidecar offloads tasks like retries, timeouts, and distributed tracing, freeing developers to focus on logic. Observability is built-in, with OpenTelemetry for tracing and metrics, and resiliency features like circuit breakers are preconfigured.
In a demo, Jake showcased a pub/sub quickstart, where a Spring Boot application published orders to a queue, processed by another service via Dapr’s sidecar. The Java SDK’s @Topic annotation integrated seamlessly with Spring, requiring minimal configuration. This setup highlighted Dapr’s ability to simplify communication and ensure portability across clouds or on-premises environments, aligning with FireConnect’s agnostic deployment goals.
FireConnect’s Dapr-Powered Future
Applying Dapr to FireConnect, Jake rearchitected the application for simplicity and scalability. The core translation component now communicates via Dapr’s pub/sub and state management, with pluggable facades for FHIR or OpenEHR APIs. External triggers, like Azure Event Hubs, integrate effortlessly, enhancing flexibility. The leaner architecture reduces infrastructure overhead, allowing Jake to prioritize clinical data mapping over managing glue components. Deployable on Kubernetes or bare metal, FireConnect meets customer demands for platform choice.
Jake’s talk inspired attendees to explore Dapr for distributed systems and consider healthcare data challenges. As his first conference presentation, it was a passionate call to bridge technology and healthcare for better patient outcomes.
Links:
[SpringIO2022] JobRunr: Simplifying Distributed Job Scheduling with Spring
At Spring I/O 2022 in Barcelona, Ronald Dehuysser introduced JobRunr, an open-source Java library designed to streamline distributed background job processing. His engaging session, blending practical insights with live coding, showcased how JobRunr empowers developers to transform Java 8 lambdas into scalable, fault-tolerant jobs without complex infrastructure. Tailored for businesses handling moderate data volumes, Ronald’s talk highlighted JobRunr’s seamless integration with Spring and its potential to revolutionize job scheduling.
The Genesis of JobRunr: Solving Real-World Challenges
Ronald, a contractor from Belgium, kicked off by sharing the origins of JobRunr, born from a challenging “greenfield” fintech project. Tasked with building an invoicing platform on Google Cloud, he encountered a microservice architecture plagued by issues: no retry mechanisms, poor monitoring, and lost invoices due to untracked failures. The project’s eight microservices led to code duplication, prompting Ronald to question the microservice hype and advocate for simpler, modular monoliths. Frustrated by the lack of developer-friendly, open-source job scheduling tools, he created JobRunr to address these gaps, emphasizing ease of use, existing infrastructure, and automatic retries.
JobRunr’s philosophy is rooted in simplicity and practicality. Unlike solutions requiring heavy infrastructure like Apache Kafka or vendor-specific cloud services, JobRunr leverages SQL or NoSQL databases for persistence, making it embeddable with a single JAR. Ronald stressed that most businesses don’t need to process terabytes daily like tech giants. Instead, JobRunr targets complex business processes with gigabytes of data, offering a plug-and-play solution with built-in monitoring and fault tolerance.
Core Features: From Lambdas to Distributed Jobs
The heart of JobRunr lies in its ability to convert Java 8 lambdas into distributed background jobs. Ronald demonstrated this with a Spring service example, where a static BackgroundJob.enqueue method schedules jobs without altering existing code. Jobs are serialized as JSON, stored in a database, and processed by BackgroundJobServer instances across JVMs, enabling horizontal scaling in Kubernetes. A dashboard provides real-time insights into job status, with automatic retries (up to 10 by default) using an exponential backoff policy to handle failures gracefully.
For scheduling flexibility, JobRunr supports immediate, delayed, or recurring jobs. Ronald showcased the schedule API for jobs running after a delay (e.g., 24 hours) and the scheduleRecurrently method for daily tasks, using a readable Cron class to simplify cron expressions. The dashboard allows manual triggering of recurring jobs for testing, enhancing developer control. To prevent duplicate processing, JobRunr offers mutex support, though advanced features like this are part of the paid Pro version, balancing open-source accessibility with sustainability.
Under the Hood: Bytecode Magic and Spring Native
Delving into JobRunr’s internals, Ronald revealed its use of ASM for bytecode manipulation, translating lambdas into executable jobs. While some criticized this as “black magic,” he countered with assurances of binary compatibility, backed by Oracle’s Java Language Specification and his participation in Oracle’s Quality Outreach Program. JobRunr’s compatibility spans Java 8 to 17, tested across JVMs using Testcontainers, ensuring robustness. The introduction of JobRequest and JobRequestHandler in version 4 further simplifies job definition, aligning with the command handler pattern for explicit job processing.
A highlight was JobRunr’s integration with Spring Native, enabling compilation to GraalVM native images for millisecond startup times and low memory usage. Ronald collaborated with the Spring team to ensure reflection compatibility, making JobRunr a natural fit for cloud-native deployments. The live coding demo, despite minor hiccups, showcased JobRunr’s ease of use: Ronald built an uptime monitoring service, scheduling recurring website checks with a few lines of code, monitored via the dashboard. This practicality resonated with attendees, who appreciated JobRunr’s developer-friendly approach.
Impact and Future: Empowering Developers
JobRunr’s adoption spans medical image processing, web crawling, and document generation, with 30,000 monthly Maven downloads. Ronald shared a compelling anecdote: a company reported a 20% developer productivity boost by using the dashboard’s requeue feature for first-line support, reducing interruptions. Looking ahead, JobRunr aims to enhance GraalVM support, add OpenID Connect for dashboard authentication, and incorporate community-driven features. The Pro version funds development, with 5% of profits supporting environmental causes like tree planting.
Ronald’s session underscored JobRunr’s mission to simplify distributed job scheduling, making it an invaluable tool for Spring developers tackling real-world business challenges with minimal overhead.
Links:
[SpringIO2019] Zero Downtime Migrations with Spring Boot by Alex Soto
Deploying software updates without disrupting users is a cornerstone of modern DevOps practices. At Spring I/O 2019 in Barcelona, Alex Soto, a prominent figure at Red Hat, delivered a comprehensive session on achieving zero downtime migrations in Spring Boot applications, particularly within microservices architectures. With a focus on advanced deployment techniques and state management, Alex provided actionable insights for developers navigating the complexities of production environments. This post delves into his strategies, enriched with practical demonstrations and real-world applications.
The Evolution from Monoliths to Microservices
The shift from monolithic to microservices architectures has transformed deployment practices. Alex began by contrasting the simplicity of monolithic deployments—where a single application could be updated during off-hours with minimal disruption—with the complexity of microservices. In a microservices ecosystem, services are interconnected in a graph-like structure, often with independent databases and multiple entry points. This distributed nature amplifies the impact of downtime, as a single service failure can cascade across the system.
To address this, Alex emphasized the distinction between deployment (placing a service in production) and release (routing traffic to it). This separation is critical for zero downtime, allowing teams to test new versions without affecting users. By leveraging service meshes like Istio, developers can manage traffic routing dynamically, ensuring seamless transitions between service versions.
Blue-Green and Canary Deployments
Alex explored two foundational techniques for zero downtime: blue-green and canary deployments. In blue-green deployments, a new version (green) is deployed alongside the existing one (blue), with traffic switched to the green version once validated. This approach minimizes disruption but risks affecting all users if the green version fails. Canary deployments mitigate this by gradually routing a small percentage of traffic to the new version, allowing teams to monitor performance before a full rollout.
Both techniques rely on robust monitoring, such as Prometheus, to detect issues early. Alex demonstrated a blue-green deployment using a movie store application, where a shopping cart’s state was preserved across versions using an in-memory data grid like Redis. This ensured users experienced no loss of data, even during version switches, highlighting the power of stateless and ephemeral state management in microservices.
Managing Persistent State
Persistent state, such as database schemas, poses a significant challenge in zero downtime migrations. Alex illustrated this with a scenario involving renaming a database column from “name” to “full_name.” A naive approach risks breaking compatibility, as some users may access the old schema while others hit the new one. To address this, he proposed a three-step migration process:
- Dual-Write Phase: The application writes to both the old and new columns, ensuring data consistency across versions.
- Data Migration: Historical data is copied from the old column to the new one, often using tools like Spring Batch to avoid locking the database.
- Final Transition: The application reads and writes exclusively to the new column, with the old column retained for rollback compatibility.
This methodical approach, demonstrated with a Kubernetes-based cluster, ensures backward compatibility and uninterrupted service. Alex’s demo showed how Istio’s traffic management capabilities, such as routing rules and mirroring, facilitate these migrations by directing traffic to specific versions without user impact.
Leveraging Istio for Traffic Management
Istio, a service mesh, plays a pivotal role in Alex’s strategy. By abstracting cross-cutting concerns like service discovery, circuit breaking, and security, Istio simplifies zero downtime deployments. Alex showcased how Istio’s sidecar containers handle traffic routing, enabling techniques like traffic mirroring for dark launches. In a dark launch, requests are sent to both old and new service versions, but only the old version’s response is returned to users, allowing teams to test new versions in production without risk.
Istio also supports chaos engineering, simulating delays or timeouts to test resilience. Alex cautioned, however, that such practices require careful communication to avoid unexpected disruptions, as illustrated by anecdotes of misaligned testing efforts. By integrating Istio with Spring Boot, developers can achieve robust, scalable deployments with minimal overhead.
Handling Stateful Services
Stateful services, particularly those with databases, require special attention. Alex addressed the challenge of maintaining ephemeral state, like shopping carts, using in-memory data grids. For persistent state, he recommended strategies like synthetic transactions or throwaway database clusters to handle mirrored traffic during testing. These approaches prevent unintended database writes, ensuring data integrity during migrations.
In his demo, Alex applied these principles to a movie store application, showing how a shopping cart persisted across blue-green deployments. By using Redis to replicate state across a cluster, he ensured users retained their cart contents, even as services switched versions. This practical example underscored the importance of aligning infrastructure with business needs.
Lessons for Modern DevOps
Alex’s presentation offers a roadmap for achieving zero downtime in microservices. By combining advanced deployment techniques, service meshes, and careful state management, developers can deliver reliable, user-focused applications. His emphasis on tools like Istio and Redis, coupled with a disciplined migration process, provides a blueprint for tackling real-world challenges. For teams like those at Red Hat, these strategies enable faster, safer releases, aligning technical excellence with business continuity.