Posts Tagged ‘devops’
[MunchenJUG] Navigating the JVM Ecosystem: A Safari Through Distributions (16/Sep/2024)
Lecturer
Gerrit Grunwald is a highly regarded software engineer and advocate with four decades of experience in the technology sector. He is a prominent figure in the Java community, recognized as a Java Champion and a JavaOne Rockstar. Gerrit is deeply committed to open-source software, having contributed to and led numerous projects such as JFXtras, TilesFX, Medusa, and JDKMon. He founded and leads the Java User Group Münster and is a frequent speaker at international conferences. Currently, Gerrit serves as a Developer Advocate at Azul.
Abstract
This article provides an analytical overview of the modern Java Virtual Machine (JVM) landscape, distinguishing between the OpenJDK project and its various commercial and community distributions. It evaluates the shift in Java’s release cadence and the implications for long-term support (LTS) in corporate environments. A significant portion of the analysis is dedicated to the optimization of Java runtimes through modularity and the jlink tool, demonstrating how developers can significantly reduce deployment sizes and enhance security. Finally, the article categorizes the plethora of available JDK distributions—from major cloud providers like Amazon and Alibaba to specialized runtimes like GraalVM—offering a guide for selecting the appropriate distribution based on specific use cases.
The Distinction Between OpenJDK and Distributions
A fundamental misunderstanding in the Java community is the conflation of “OpenJDK” with the software installed on a user’s machine. OpenJDK is not a downloadable product but rather the open-source project hosted on GitHub that contains the source code for the Java Platform, Standard Edition (Java SE). What developers actually utilize are “builds” or “distributions” of this source code.
The OpenJDK ecosystem is characterized by its collaborative nature, with significant contributions from tech giants such as Oracle, Amazon, ARM, Google, Intel, and IBM. This multi-corporate backing ensures the longevity and stability of the platform, preventing it from becoming a “one-man show”. Since moving to GitHub with JDK 16, the transparency and accessibility of the source code have further improved, allowing for faster build times and broader community involvement.
Release Cadence and Support Models
The evolution of Java’s release model marks a critical transition from multi-year development cycles to a predictable six-month cadence. Historically, long gaps between releases (such as the five years between JDK 6 and JDK 7) led to massive, overwhelming updates that were difficult for organizations to adopt.
The current model classifies releases into two categories:
- Feature Releases: Released every six months, these versions typically receive support for only half a year.
- Long-Term Support (LTS) Releases: These versions are designated for extended support, often spanning a decade or more, providing the stability required by enterprise applications.
This dual-track approach allows the language to innovate rapidly through feature releases while providing a safe harbor for production environments on LTS versions.
Efficiency through Modularity: The jlink Revolution
One of the most underutilized innovations introduced in JDK 9 is the modularization of the Java runtime. By breaking the monolithic JDK into 69 distinct modules, Oracle enabled developers to create custom, stripped-down runtimes tailored to specific applications.
The tool jlink allows for the creation of a custom Java Runtime Environment (JRE) containing only the modules necessary for a particular application. The impact on deployment size is profound:
- A full JDK 21 installation requires approximately 340 MB.
- A standard JRE for the same version takes about 150 MB.
- A
jlink-optimized runtime for a simple application (like a push notification server) can be as small as 48 MB.
echo Example of using jdeps to find required modules
jdeps --ignore-missing-deps --print-module-deps MyProject.jar
echo Example of using jlink to create a custom runtime
jlink --add-modules java.base,java.logging --output custom-runtime
Beyond storage savings, modular runtimes enhance security by reducing the attack surface. If a vulnerability exists in a module that has been excluded from the custom runtime (such as the desktop module in a server-side application), the application remains unaffected.
Mapping the Distribution Jungle
The JVM landscape is populated by numerous distributions, each offering different levels of support, licensing, and platform optimizations.
Community and Vendor Builds
- Eclipse Temurin (formerly AdoptOpenJDK): A widely used community build that is TCK (Technology Compatibility Kit) compliant.
- Amazon Corretto: A no-cost, multiplatform distribution used internally by Amazon for its AWS services.
- Azul Zulu: A TCK-compliant distribution offering broad platform support.
- Oracle OpenJDK: The free, GPL-licensed build provided by Oracle.
Region-Specific and Specialized Distributions
In the Asian market, distributions like Alibaba’s Dragonwell, Huawei’s Bi Sheng, and Tencent’s Kona are dominant. These often include specific optimizations for the cloud infrastructures of their respective parent companies.
Advanced Runtimes: GraalVM and Beyond
GraalVM represents a specialized branch of the JVM ecosystem, offering high-performance polyglot capabilities and “Native Image” compilation. Native images allow Java applications to start in milliseconds by compiling them into platform-specific executables, though this comes at the cost of peak performance and longer build times compared to the standard JIT (Just-In-Time) compilation used by the HotSpot JVM.
Conclusion: Strategy for Selection
Choosing the right JVM distribution is a strategic decision based on support requirements, cost, and technical constraints. For most production environments, sticking to an LTS version from a reputable vendor (like Azul, Amazon, or the Eclipse Foundation) ensures stability. Meanwhile, developers should leverage modern tools like jlink to ensure their deployments remain lean and secure, regardless of the distribution chosen.
Links:
[DevoxxBE2025] Not Just Code: Abusing Claude Code for Non-Coding Tasks
Lecturer
Barry van Someren operates a compact DevOps hosting and consulting enterprise named CoffeeSprout ICT Services. Previously engaged as a dedicated Java programmer, he now oversees Java-based systems and develops in-house solutions. Barry positions himself as an expert in averting common operational pitfalls such as memory exhaustion or storage shortages.
Abstract
This article scrutinizes the unconventional deployment of Claude Code, an AI-driven coding aide, in domains extending far beyond software creation. It probes into Barry’s methodologies for leveraging the tool in operational duties, infrastructure orchestration, and ad hoc automations, grounded in tangible scenarios. The examination encompasses the inception of these applications, practical executions, triumphs alongside mishaps, and ramifications for forthcoming AI-facilitated workflows in DevOps landscapes.
Inception and Justification for Extended Applications
The genesis of employing Claude Code for purposes unrelated to programming emerged from routine engagements with large language models in configuration oversight. Barry initially harnessed these models to craft Ansible playbooks, a YAML-centric framework for delineating system states. Ansible facilitates the depiction of desired configurations, enabling automated enforcement across servers. During one such interaction, the model proposed executing a command to ascertain a file path, sparking the realization that Claude could transcend mere suggestion to active participation in debugging and setup on development platforms.
This pivot stems from the acknowledgment that numerous operational elements mirror code structures. Infrastructure configurations, for instance, can be codified, while fleeting assignments may not warrant full-fledged scripting. Recurring chores often reveal themselves post hoc, prompting Barry to instruct Claude to formulate reusable scripts after task completion. Notably, this approach eschews intricate prompt crafting; initiating a dialogue within Claude’s interface, refining directives iteratively, suffices for efficacious outcomes.
Furthermore, the rationale hinges on friction reduction in learning novel utilities. Barry recounts configuring a rudimentary virtual machine, where Claude undertook preparatory steps, thereby expediting assimilation of unfamiliar technologies. This proves particularly advantageous in conference settings like Devoxx, where novel concepts abound, allowing practitioners to experiment swiftly without exhaustive manual setup.
Claude Code’s allure lies in its subscription framework, mitigating earlier credit-based expenditures that could escalate to substantial sums daily. The advent of affordable plans democratizes access, rendering it viable for exploratory uses. Its acumen in encoding and tool proficiency outpaces contemporaries, although rivals like ChatGPT’s Codex narrow the disparity. Consequently, Barry advocates for its adoption in streamlining DevOps, transforming mundane operations into efficient processes.
Methodological Executions and Illustrative Cases
Barry’s technique involves granting Claude terminal access within controlled environs, such as virtual machines or containers, to execute commands and scripts. This necessitates safeguards: employing disposable instances, restricting privileges via non-root users, and isolating sensitive data. For demonstration, he configures a Spring Pet Clinic application on Ubuntu, commencing with package updates and Java installation.
In one instance, Claude autonomously installs PostgreSQL, initializes a database, and integrates it with the application by modifying configuration files. It generates passwords—albeit simplistic ones—and applies them consistently, showcasing its aptitude for cross-file correlation. Another example entails heap analysis on a Java application; Claude employs jmap to capture heap dumps, analyzes them with jhat, and identifies memory leaks, all while navigating command-line intricacies.
A compliance scenario highlights versatility: adhering to energy conservation regulations, Claude devises scripts to throttle CPU frequencies during off-hours, generates audit logs, and verifies adherence, yielding a 15% reduction in power consumption. Similarly, it processes Excel sheets to execute scripts per user, excluding managerial roles, demonstrating data handling prowess.
These cases underscore repeatability without elaborate guidance. Barry emphasizes commencing with explicit plans, segmenting tasks, and verifying outputs. For Git repositories, Claude clones projects, inspects commit histories, and pinpoints version-specific issues. In Kubernetes contexts, it traverses namespaces, scrutinizes deployments, and peruses pod logs expeditiously.
However, executions demand vigilance. Barry recounts an episode where Claude rebooted a machine prematurely, failing to update boot configurations correctly, underscoring the imperative for output scrutiny. Nonetheless, the tool’s self-correction upon feedback enhances reliability.
Evaluation of Outcomes and Derived Insights
Assessing these applications reveals both efficacies and deficiencies. Successes include adept repository analysis, where Claude discerned alterations across versions, aiding troubleshooting. Its proficiency in interlinking configurations—such as database credentials in application properties—proves invaluable for intricate setups. Moreover, it accelerates tool acquisition, beneficial for client engagements involving novel technologies.
In Kubernetes diagnostics, Claude’s rapid log inspection outpaces manual efforts, facilitating swift resolutions. Log analysis on sanitized files identifies anomalies effectively, while test data generation populates schemas comprehensively. One-off automations address procrastinated tasks, and local container setups streamline development without advanced frameworks.
Conversely, pitfalls abound. Premature completion declarations necessitate clear doneness criteria and measurable objectives. Reading comprehension lapses, as in the misinterpretation of grub update outputs, mimic human errors but require intervention. Context exhaustion precipitates erratic behavior, mandating task fragmentation.
Barry advises defining scopes meticulously, verifying successes, and managing contexts to avert spirals. Despite these, the tool’s utility in DevOps outweighs risks when confined to non-production realms.
Ramifications and Prospective Trajectories
The implications extend to redefining DevOps workflows, where AI aides like Claude diminish manual toil, permitting focus on strategic endeavors. This fosters agility, particularly in compliance and reporting, where generated artifacts ensure regulatory adherence efficiently.
Looking ahead, the convergence of open-source models like Mistral with frontier capabilities portends broader accessibility. Barry speculates that simpler deployments may soon operate on local models, reducing dependency on proprietary services. Tools like Aider, permitting model selection, herald this shift.
In essence, Claude Code’s repurposing exemplifies AI’s potential in operational spheres, promoting efficiency while necessitating prudent governance. As models evolve, their integration into daily practices promises transformative, albeit cautious, advancements in technology management.
Links:
- Lecture video: https://www.youtube.com/watch?v=nPoC6m3axeU
- Barry van Someren on LinkedIn: https://www.linkedin.com/in/barryvansomeren
- Barry van Someren on Twitter/X: https://twitter.com/bvansomeren
- CoffeeSprout ICT Services website: https://www.coffeesprout.nl/
[AWSReInvent2025] Supercharging DevOps with AI-Driven Observability: The Next Frontier in SRE
Lecturer
Elizabeth Fuentes is a Senior Developer Advocate at Amazon Web Services (AWS), specializing in the intersection of Artificial Intelligence and DevOps practices. With extensive experience in cloud architecture and software engineering, Elizabeth focuses on how Generative AI can streamline complex CI/CD pipelines and enhance Site Reliability Engineering (SRE). She is a key contributor to AWS educational initiatives, having co-developed advanced courses on AI-driven automation. Joining her is Laas Alina, a software architect and open-source enthusiast who focuses on implementing multi-agent systems and the Model Context Protocol (MCP) to solve observability challenges at scale.
Abstract
As software systems grow increasingly distributed and complex, traditional observability—centered on manual log analysis and reactive dashboards—is becoming insufficient. This article explores the paradigm shift toward AI-driven observability, where Generative AI serves not just as a query tool, but as an active participant in failure detection, correlation, and resolution. By leveraging Amazon Bedrock and Amazon Q, organizations can transition from “reactive” to “predictive” DevOps. The discussion analyzes the methodology of building AI agents that simulate architectural stress, automatically explain multi-layered failures, and provide traceable, actionable recommendations. We examine the implementation of the Model Context Protocol (MCP) in establishing sophisticated multi-agent systems (MAS) that transform raw data into contextual understanding, ultimately reducing the Mean Time to Resolution (MTTR) and enhancing systemic resilience.
The Evolution of Observability: From Metrics to Contextual Understanding
The traditional pillars of observability—metrics, logs, and traces—provide the “what” of a system’s state but often fail to provide the “why” in real-time. In high-velocity DevOps environments, the sheer volume of telemetry data can overwhelm human operators, leading to “alert fatigue” and delayed responses to critical incidents. Elizabeth posits that the integration of Generative AI marks the fourth pillar of observability: Contextual Intelligence. This evolution moves the industry beyond simple threshold-based monitoring toward systems that understand the semantic relationship between a failed deployment, a spike in latency, and a specific line of code.
By utilizing Large Language Models (LLMs) through Amazon Bedrock, DevOps teams can ingest vast amounts of unstructured log data and receive summaries that highlight anomalies that might be missed by traditional regex-based filters. The methodology involves training the AI to recognize “normal” operational patterns and identifying deviations not just by value, but by the intent of the system’s behavior. This contextual layer allows for a more nuanced interpretation of system health, where the AI can distinguish between a benign resource spike and a precursor to a cascading failure.
Architecting AI Agents for Predictive Troubleshooting
The transition to AI-driven observability is characterized by the deployment of “Micro-agents”—specialized AI entities designed to handle specific segments of the DevOps lifecycle. These agents operate within a Multi-Agent System (MAS), where they collaborate to solve complex incidents. For instance, a “Monitoring Agent” might detect a performance degradation and immediately trigger a “Diagnosis Agent” to correlate the event with recent CI/CD pipeline changes.
Elizabeth and Laas Alina emphasize the importance of the Model Context Protocol (MCP) in this architecture. MCP acts as the communication backbone, allowing agents to share context without losing the “lineage” of a decision. When an AI agent recommends a specific architectural change or a rollback, it must provide clear traceability. This is crucial for maintaining trust in automated systems. The agents do not operate in a vacuum; they interact with tools like Amazon Q to provide developers with instant explanations of failures directly within their Integrated Development Environment (IDE) or chat interface.
// Example of an AI-driven Observability Agent Configuration
agent:
name: "IncidentDiagnosticAgent"
provider: "AmazonBedrock"
model: "claude-3-sonnet"
capabilities:
- log_analysis
- metric_correlation
- trace_summarization
mcp_config:
protocol_version: "1.0"
shared_context: "deployment_metadata"
safety_guardrails:
- max_token_usage: 4000
- human_in_the_loop_required: true
Transforming CI/CD through Generative AI and Simulation
Beyond reactive troubleshooting, AI-driven observability empowers proactive system design. One of the most innovative concepts discussed is the use of AI agents to simulate “stress-test” scenarios within a digital twin of the production environment. These agents can intentionally inject failures—similar to Chaos Engineering—and then observe how the observability stack responds. This creates a feedback loop where the AI helps engineers identify “blind spots” in their monitoring before a real incident occurs.
Furthermore, Generative AI transforms the CI/CD pipeline by automatically generating “failure explanations.” Instead of a developer sifting through a 5,000-line build log, Amazon Q can provide a concise summary: “The build failed because the new database schema in commit X is incompatible with the connection pool settings in environment Y.” This level of automated insight accelerates the “inner loop” of development, allowing engineers to focus on innovation rather than infrastructure archeology.
The Human-AI Partnership: Strategic Implications
A common concern in the industry is the replacement of human engineers by AI. However, Elizabeth argues that the future belongs to the “augmented engineer.” AI is a force multiplier that automates the repetitive, “drudge work” of observability—log parsing and initial triage—allowing human experts to focus on high-level strategy and complex architectural decisions. The goal is to transform teams from being “reactive” (fighting fires) to “proactive” (preventing fires).
Implementing these systems requires a cultural shift toward AI-literacy within DevOps teams. Organizations must establish safety guardrails to ensure that AI-driven recommendations are validated and that automated actions (like auto-remediation) have clear rollback paths. By embracing AI as a strategic tool, DevOps and SRE teams can achieve a level of operational excellence that was previously unattainable, ensuring that as systems grow in scale, their reliability grows in parallel.
Links:
[MunchenJUG] Strategic API Communication: Enhancing Interaction Between Providers and Consumers (4/Nov/2024)
Lecturer
Enis Spahi is a software architect and consultant with extensive experience in designing and implementing large-scale distributed systems. He is a specialist in API design, microservices architecture, and contract-driven development. Enis is recognized for his contributions to the community regarding API governance and the standardization of machine-to-machine communication. His professional focus involves streamlining the collaboration between backend service providers and frontend or third-party consumers, advocating for “API-First” and “Consumer-Driven” methodologies to reduce integration friction.
Abstract
While APIs are fundamentally engineered for machine-to-machine communication, their development is deeply influenced by human factors, including discoverability, documentation, and interpersonal coordination. This article explores the methodologies for enhancing provider and consumer interaction through standardized specification languages and contract testing. By analyzing the transition from “Code-First” to “API-First” and “Consumer-First” approaches, the discussion highlights the innovations brought by OpenAPI, AsyncAPI, and Pact. The analysis further evaluates the technical implications of automated documentation and contract verification in maintaining system integrity within microservices ecosystems.
The Human Challenge in Technical Interfaces
The primary bottleneck in modern software delivery is often not the implementation of logic, but the communication of how that logic can be accessed. Enis Spahi identifies a recurring problem in the industry: the lack of API discoverability. Even the most technically sound API is useless if a potential consumer cannot find it or understand its requirements. This “Communication Gap” often leads to wasted development cycles, where teams build redundant services or struggle with mismatched expectations.
To address this, the methodology shifts from viewing an API as a technical byproduct to viewing it as a Product. This perspective necessitates a commitment to high-quality documentation and a “Common Language” that both providers and consumers can use to negotiate the interface’s behavior.
Standardization via Specification Languages
A cornerstone of modern API communication is the use of standardized specification languages. These formats provide a machine-readable “source of truth” that can be transformed into human-readable documentation or even executable code.
- OpenAPI (formerly Swagger): This has become the de facto standard for RESTful APIs. It allows providers to define endpoints, request/response formats, and security requirements in a YAML or JSON file.
- AsyncAPI: As architectures move toward event-driven patterns, AsyncAPI provides the same level of rigor for asynchronous communications (e.g., Kafka, RabbitMQ), defining message formats and channel structures.
- Documentation as Code: By maintaining specifications in version control, documentation becomes a living asset. Tools can automatically generate interactive portals (like Swagger UI) where consumers can explore and test the API in real-time.
Comparative Methodologies: Code-First vs. API-First vs. Consumer-First
The strategy chosen for API development significantly impacts the relationship between the provider and the consumer.
- Code-First: Implementation begins immediately, and the specification is generated from the code. While fast for small teams, this often leads to “leaky abstractions,” where internal implementation details are inadvertently exposed to consumers.
- API-First: The specification is designed and agreed upon before any code is written. This allows frontend and backend teams to work in parallel, using the specification to generate mocks. It fosters a more deliberate and consumer-friendly design.
- Consumer-First (Contract Testing): This methodology, exemplified by tools like Pact, takes collaboration a step further. Consumers define their expectations in a “contract.” The provider then verifies its implementation against these contracts. This ensures that a provider never makes a change that would break an existing consumer.
Code Sample: A Simple Pact Consumer Contract
@Pact(consumer = "UserWebClient", provider = "UserService")
public RequestResponsePact createPact(PactDslWithProvider builder) {
return builder
.given("User 123 exists")
.uponReceiving("A request for User 123")
.path("/users/123")
.method("GET")
.willRespondWith()
.status(200)
.body(new PactDslJsonBody()
.stringType("username", "espahi")
.stringType("email", "enis@example.com"))
.toPact();
}
Implications for Scalability and Governance
In a microservices environment, the number of interfaces can grow exponentially. Without a standardized approach to communication, the system becomes a “Distributed Monolith” where every change requires cross-team meetings and manual testing.
Enis emphasizes that adopting these automated tools—OpenAPI generators for client libraries and Pact for contract verification—shifts the burden of compatibility from humans to the CI/CD pipeline. This automation allows for “Independent Deployability,” where teams can release updates with the mathematical certainty that they are not breaking downstream consumers.
Conclusion
Enhancing the interaction between API providers and consumers requires a strategic blend of technical standards and human-centric design. By moving toward API-First and Consumer-Driven methodologies, organizations can bridge the gap between intent and implementation. The use of OpenAPI and Pact transforms APIs from fragile connections into robust, documented, and verified contracts. Ultimately, the success of a distributed system depends not just on how well its machines talk, but on how clearly its human creators communicate their expectations.
Links:
[MiamiJUG] Taming Vulnerabilities and Technical Debt Through Deterministic Refactoring
Lecturer
Kevin Brockhoff is a Director and Consulting Expert at CGI, one of the world’s largest IT and business consulting firms. With decades of experience in the technology industry, Kevin specializes in navigating the complex intersections of cybersecurity, digital transformation, and large-scale enterprise systems. His work at CGI involves helping multinational organizations—spanning sectors such as banking, government, and manufacturing—modernize their legacy infrastructure while maintaining robust security postures. Kevin is a prominent voice in the Miami technology community, frequently sharing insights at the Miami Java User Group (MiamiJUG) regarding automated refactoring and the integration of generative AI in software engineering.
Abstract
As enterprises face an accelerating stream of feature requests and increasingly sophisticated cyber threats, the accumulation of technical debt and security vulnerabilities has become a critical bottleneck. This article examines a deterministic approach to large-scale code remediation using OpenRewrite, an open-source automated refactoring ecosystem. Unlike indeterminate generative AI agents, which can produce inconsistent results and hallucinations, OpenRewrite utilizes Lossless Semantic Trees (LSTs) to ensure predictable, traceable, and scalable code transformations. By combining the creative potential of AI with the reliability of rule-based transformers, organizations can achieve a fourfold increase in productivity for vulnerability remediation. The following analysis explores the methodology of LST-based refactoring, its application across thousands of repositories, and its strategic role in modernizing global IT infrastructure.
The Crisis of Speed and Indeterminacy in Enterprise Software
In the modern software landscape, engineering teams are caught in a perpetual race between delivering new features and mitigating emerging security risks. Kevin emphasizes that speed is the decisive factor in this environment; delays in remediation allow vulnerabilities to proliferate across growing application portfolios. While generative AI agents have been proposed as a solution to this problem, they introduce significant challenges when applied in isolation at an enterprise scale.
The primary issue with relying solely on Large Language Models (LLMs) for code refactoring is their indeterminate nature. Applying an AI agent to the same codebase multiple times may yield different results, and the risk of “hallucinations” necessitates a manual human review of every line of code. Furthermore, current AI tools often struggle with scalability; while they may function effectively on a single repository, managing transformations across 5,000 repositories requires a more structured, traceable mechanism.
OpenRewrite: Deterministic Refactoring via Lossless Semantic Trees
To address the limitations of AI, Kevin advocates for the use of OpenRewrite, a tool sponsored by Moderne that provides a deterministic framework for source code modification. At the heart of OpenRewrite is the Lossless Semantic Tree (LST). While a traditional Abstract Syntax Tree (AST) represents the hierarchical structure of code, the LST incorporates two additional layers of critical information:
- Type Information: Every node in the tree is enriched with comprehensive type data, similar to the output of a compiler.
- Formatting Preservation: Uniquely, the LST captures all original formatting, including whitespace and comments.
This architecture allows OpenRewrite to parse code, apply transformations, and write it back to the source file with character-for-character fidelity to the original style, provided no changes were intended. Most importantly, these modifications are deterministic; a “recipe”—the rule-based transformer used by the engine—will produce identical results every time it is applied, enabling mass application across thousands of repositories without the need for exhaustive manual re-verification.
Methodology: Combining AI with Rule-Based Transformers
The most effective strategy for large-scale remediation involves a hybrid approach that leverages both AI and deterministic tools. In this model, AI agents are used to assist human developers in generating the refactoring recipes themselves. Once a recipe is refined and tested, it acts as a reliable, version-controlled asset that can be executed at scale.
OpenRewrite’s ecosystem is divided into open-source and commercial components. The core engine and a vast catalog of common recipes—covering framework migrations (such as Spring Boot upgrades), security fixes, and stylistic consistency—are available under the Apache license. For large-scale enterprise management, the Moderne platform provides advanced capabilities, including:
- SaaS and On-Premise (DX) Options: These allow for mass refactoring across an entire organization’s source code system.
- Semantic Search: By calculating embeddings on LSTs, the platform enables highly sophisticated code intelligence and search.
- Batch Remediation Tracking: A centralized dashboard for managing the progress of large-scale security and tech debt campaigns.
Implementation and Impact
The practical application of these tools has demonstrated a 4X increase in productivity for security vulnerability remediation at major corporations. Beyond security, use cases include technical modernization, library upgrades, and maintaining architectural standards. By automating the “grunt work” of refactoring, senior engineers can focus on higher-level architectural decisions while the deterministic engine ensures that thousands of microservices remain up-to-date with the latest security patches and framework versions.
Relevant links and hashtags:
[MunchenJUG] Reliability in Enterprise Software: A Critical Analysis of Automated Testing in Spring Boot Ecosystems (27/Oct/2025)
Lecturer
Philip Riecks is an independent software consultant and educator specializing in Java, Spring Boot, and cloud-native architectures. With over seven years of professional experience in the software industry, Philip has established himself as a prominent voice in the Java ecosystem through his platform, Testing Java Applications Made Simple. He is a co-author of the influential technical book Stratospheric: From Zero to Production with Spring Boot and AWS, which bridges the gap between local development and production-ready cloud deployments. In addition to his consulting work, he produces extensive educational content via his blog and YouTube channel, focusing on demystifying complex testing patterns for enterprise developers.
Abstract
In the contemporary landscape of rapid software delivery, automated testing serves as the primary safeguard for application reliability and maintainability. This article explores the methodologies for demystifying testing within the Spring Boot framework, moving beyond superficial unit tests toward a comprehensive strategy that encompasses integration and slice testing. By analyzing the “Developer’s Dilemma”—the friction between speed of delivery and the confidence provided by a robust test suite—this analysis identifies key innovations such as the “Testing Pyramid” and specialized Spring Boot test slices. The discussion further examines the technical implications of external dependency management through tools like Testcontainers and WireMock, advocating for a holistic approach that treats test code with the same rigor as production logic.
The Paradigm Shift in Testing Methodology
Traditional software development often relegated testing to a secondary phase, frequently outsourced to separate quality assurance departments. However, the rise of DevOps and continuous integration has necessitated a shift toward “test-driven” or “test-enabled” development. Philip Riecks identifies that the primary challenge for developers is not the lack of tools, but the lack of a clear strategy. Testing is often perceived as a bottleneck rather than an accelerator.
The methodology proposed focuses on the Testing Pyramid, which prioritizes a high volume of fast, isolated unit tests at the base, followed by a smaller number of integration tests, and a minimal set of end-to-end (E2E) tests at the apex. The innovation in Spring Boot testing lies in its ability to provide “Slice Testing,” allowing developers to load only specific parts of the application context (e.g., the web layer or the data access layer) rather than the entire infrastructure. This approach significantly reduces test execution time while maintaining high fidelity.
Architectural Slicing and Context Management
One of the most powerful features of the Spring Boot ecosystem is its refined support for slice testing via annotations. This allows for an analytical approach to testing where the scope of the test is strictly defined by the architectural layer under scrutiny.
- Web Layer Testing: Using
@WebMvcTest, developers can test REST controllers without launching a full HTTP server. This slice provides a mocked environment where the web infrastructure is active, but business services are replaced by mocks (e.g., using@MockBean). - Data Access Testing: The
@DataJpaTestannotation provides a specialized environment for testing JPA repositories. It typically uses an in-memory database by default, ensuring that database interactions are verified without the overhead of a production-grade database. - JSON Serialization:
@JsonTestisolates the serialization and deserialization logic, ensuring that data structures correctly map to their JSON representations.
This granular control prevents “Context Bloat,” where tests become slow and brittle due to the unnecessary loading of the entire application environment.
Code Sample: A Specialized Controller Test Slice
@WebMvcTest(UserRegistrationController.class)
class UserRegistrationControllerTest {
@Autowired
private MockMvc mockMvc;
@MockBean
private UserRegistrationService registrationService;
@Test
void shouldRegisterUserSuccessfully() throws Exception {
mockMvc.perform(post("/api/users")
.contentType(MediaType.APPLICATION_JSON)
.content("{\"username\": \"priecks\", \"email\": \"philip@example.com\"}"))
.andExpect(status().isCreated());
}
}
Managing External Dependencies: Testcontainers and WireMock
A significant hurdle in integration testing is the reliance on external systems such as databases, message brokers, or third-party APIs. Philip emphasizes the move away from “In-Memory” databases (like H2) for testing production-grade applications, citing the risk of “Environment Parity” issues where H2 behaves differently than a production PostgreSQL instance.
The integration of Testcontainers allows developers to spin up actual Docker instances of their production infrastructure during the test lifecycle. This ensures that the code is tested against the exact same database engine used in production. Similarly, WireMock is utilized to simulate external HTTP APIs, allowing for the verification of fault-tolerance mechanisms like retries and circuit breakers without depending on the availability of the actual external service.
Consequences of Testing on Long-term Maintainability
The implications of a robust testing strategy extend far beyond immediate bug detection. A well-tested codebase enables fearless refactoring. When developers have a “safety net” of automated tests, they can update dependencies, optimize algorithms, or redesign components with the confidence that existing functionality remains intact.
Furthermore, Philip argues that the responsibility for quality must lie with the engineer who writes the code. In an “On-Call” culture, the developer who builds the system also runs it. This ownership model, supported by automated testing, transforms software engineering from a process of “handing over” code to one of “carefully crafting” resilient systems.
Conclusion
Demystifying Spring Boot testing requires a transition from viewing tests as a chore to seeing them as a fundamental engineering discipline. By leveraging architectural slices, managing dependencies with Testcontainers, and adhering to the Testing Pyramid, developers can build applications that are not only functional but also sustainable. The ultimate goal is to reach a state where testing provides joy through the confidence it instills, ensuring that the software remains a robust asset for the enterprise rather than a source of technical debt.
Links:
[NDCOslo2024] Hub-Spoke Virtual Networks in Azure – Bastiaan Wassenaar
In the labyrinthine landscape of Azure’s azure architecture, where connectivity contends with compliance, Bastiaan Wassenaar, a cloud custodian and connectivity connoisseur, clarifies the conundrum of hub-spoke virtual networks. As a Dutch devops dynamo, Bastiaan blueprints the bedrock—endpoints, peering, policies—propelling practitioners past perplexities in private provisioning. His session, a symphony of safeguards and setups, spotlights the saga from service sentinels to spoke sanctuaries, ensuring egress elegance and ingress integrity.
Bastiaan banters on boredom’s behalf: vnet vexations vex veterans, yet victory vaults with vigilance. He heralds history: vnet’s 2014 genesis, endpoints’ evolution, private peers’ precision—pivoting from public perils to partitioned paradises.
Foundations of Fortification: Endpoints and Evolutions
Service endpoints erect ramparts: subnet sentries shielding storage, SQL sans sprawl. Bastiaan bewails bandwidth burdens—10Gbps ceilings—yet blesses them as basics, bridging to private endpoints’ purity: dedicated daisy-chains, DNS delegations demystified.
Hub-spoke’s heartbeat: central hub harboring firewalls, spokes siphoning spokes—peering propagates prefixes, UDRs usher unicast. Bastiaan blueprints: Azure Firewall’s fabric, forced tunneling fortifying flows.
Orchestrating the Orbit: Peering, Policies, and Proxies
Peering’s pact: global gateways, transitive taboos—spokes supplicate hubs for harmony. Bastiaan bemoans BGP’s burdens—bidirectional broadcasts—yet bows to basics: static routes suffice for simplicity.
Policies propel protection: NSGs nestle at NICs, FW’s finesse filters flows. Bastiaan broadcasts best bets: hub’s hegemony, spokes’ seclusion—egress egressing exclusively, ingress inspecting intently.
DNS’s Dominion: Delegations and Dilemmas
DNS dances delicately: private endpoints’ FQDNs, hub’s handlers hijacking queries. Bastiaan bemoans blunders—external IPs eclipsing internals—yet extols overrides: custom configurations, conditional forwarding.
His hack: hosts’ hacks for haste, yet hub’s hegemony harmonizes hordes. Bastiaan broadcasts: reboot realms for resolution—vnet’s vicissitudes vanquished.
Victory’s Vista: Vigilance in Vastness
Bastiaan’s benediction: hub-spoke as haven, harmonizing hazards—history heeded, hurdles hurdled. His hurrah: harness helpers, heed heuristics—Azure’s arsenal awaits.
Links:
[DevoxxFR2025] Alert, Everything’s Burning! Mastering Technical Incidents
In the fast-paced world of technology, technical incidents are an unavoidable reality. When systems fail, the ability to quickly detect, diagnose, and resolve issues is paramount to minimizing impact on users and the business. Alexis Chotard, Laurent Leca, and Luc Chmielowski from PayFit shared their invaluable experience and strategies for mastering technical incidents, even as a rapidly scaling “unicorn” company. Their presentation went beyond just technical troubleshooting, delving into the crucial aspects of defining and evaluating incidents, effective communication, product-focused response, building organizational resilience, managing on-call duties, and transforming crises into learning opportunities through structured post-mortems.
Defining and Responding to Incidents
The first step in mastering incidents is having a clear understanding of what constitutes an incident and its severity. Alexis, Laurent, and Luc discussed how PayFit defines and categorizes technical incidents based on their impact on users and business operations. This often involves established severity levels and clear criteria for escalation. Their approach emphasized a rapid and coordinated response involving not only technical teams but also product and communication stakeholders to ensure a holistic approach. They highlighted the importance of clear internal and external communication during an incident, keeping relevant parties informed about the status, impact, and expected resolution time. This transparency helps manage expectations and build trust during challenging situations.
Technical Resolution and Product Focus
While quick technical mitigation to restore service is the immediate priority during an incident, the PayFit team stressed the importance of a product-focused approach. This involves understanding the user impact of the incident and prioritizing resolution steps that minimize disruption for customers. They discussed strategies for effective troubleshooting, leveraging monitoring and logging tools to quickly identify the root cause. Beyond immediate fixes, they highlighted the need to address the underlying issues to prevent recurrence. This often involves implementing technical debt reduction measures or improving system resilience as a direct outcome of incident analysis. Their experience showed that a strong collaboration between engineering and product teams is essential for navigating incidents effectively and ensuring that the user experience remains a central focus.
Organizational Resilience and Learning
Mastering incidents at scale requires building both technical and organizational resilience. The presenters discussed how PayFit has evolved its on-call rotation models to ensure adequate coverage while maintaining a healthy work-life balance for engineers. They touched upon the importance of automation in detecting and mitigating incidents faster. A core tenet of their approach was the implementation of structured post-mortems (or retrospectives) after every significant incident. These post-mortems are blameless, focusing on identifying the technical and process-related factors that contributed to the incident and defining actionable steps for improvement. By transforming crises into learning opportunities, PayFit continuously strengthens its systems and processes, reducing the frequency and impact of future incidents. Their journey over 18 months demonstrated that investing in these practices is crucial for any growing organization aiming to build robust and reliable systems.
Links:
- Alexis Chotard: https://www.linkedin.com/in/alexis-chotard/
- Laurent Leca: https://www.linkedin.com/in/laurent-leca/
- Luc Chmielowski: https://www.linkedin.com/in/luc-chmielowski/
- PayFit: https://payfit.com/
- Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
- Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
- Devoxx France Website: https://www.devoxx.fr/
[DotJs2024] Becoming the Multi-armed Bandit
In the intricate ballet of software stewardship, where intuition waltzes with empiricism, resides the multi-armed bandit—a probabilistic oracle guiding choices amid uncertainty. Ben Halpern, co-founder of Forem and dev.to’s visionary steward, dissected this gem at dotJS 2024. A full-stack polymath blending code with community curation, Ben recounted its infusions across his odyssey—from parody O’Reilly covers viralizing memes to mutton-busting triumphs—framing bandits as bridges between artistic whimsy and scientific rigor, aligning devs with stakeholders in pursuit of optimal paths.
Ben’s prologue evoked dev.to’s genesis: Twitter-era jests birthing a creative agora, bandit logic A/B-testing post formats for engagement zeniths. The archetype—casino levers, pulls maximizing payouts—mirrors dev dilemmas: UI variants, feature rollouts, content cadences. Exploration probes unknowns; exploitation harvests proven yields. Ben advocated epsilon-greedy: baseline exploitation (1-ε pulls best arm), exploratory ventures (ε samples alternatives), ε tuning via Thompson sampling for contextual nuance.
Practical infusions abounded. Load balancing: bandit selects origins, favoring responsive backends. Feature flags: variants vie, metrics crown victors. Smoke tests: endpoint probes, failures demote. ML pipelines: hyperparameter hunts, models ascend via validation. Ben’s dev.to saga: title A/Bs, bandit-orchestrated, surfacing resonant headlines sans bias. Organizational strata: nascent projects revel in exploration—ideation fests yielding prototypes; maturity mandates exploitation—scaling victors, pruning pretenders. This lexicon fosters accord: explorers and scalers, once at odds, synchronize via phases, preempting pivots’ friction.
Caution tempered zeal: bandits thrive on voluminous outcomes, not trivial toggles; overzealous testing paralyzes. As AI cheapens variants—code gen’s bounty—feedback scaffolds intensify, bandits as arbiters ensuring quality amid abundance. Ben’s coda: wield judiciously, blending craft’s flair with datum’s discipline for endeavors audacious yet assured.
Algorithmic Essence and Variants
Ben unpacked epsilon-greedy’s equilibrium: 90% best-arm fealty, 10% novelty nudges; Thompson’s Bayesian ballet contextualizes. UCB (Upper Confidence Bound) optimism tempers regret, ideal for sparse signals—dev.to’s post tweaks, engagement echoes guiding refinements.
Embeddings in Dev Workflows
Balancing clusters bandit-route requests; flags unleash cohorts, telemetry triumphs. ML’s parameter quests, smoke’s sentinel sweeps—all bandit-bolstered. Ben’s ethos: binary pass-fails sideline; array assays exalt, infrastructure for insight paramount.
Strategic Alignment and Prudence
Projects arc: explore’s ideation inferno yields scale’s forge. Ben bridged divides—stakeholder symposia in bandit vernacular—averting misalignment. Overreach warns: grand stakes summon science; mundane mandates art’s alacrity, future’s variant deluge demanding deft discernment.
Links:
[DevoxxFR2025] Simplify Your Ideas’ Containerization!
For many developers and DevOps engineers, creating and managing Dockerfiles can feel like a tedious chore. Ensuring best practices, optimizing image layers, and keeping up with security standards often add friction to the containerization process. Thomas DA ROCHA from Lenra, in his presentation, introduced Dofigen as an open-source command-line tool designed to simplify this. He demonstrated how Dofigen allows users to generate optimized and secure Dockerfiles from a simple YAML or JSON description, making containerization quicker, easier, and less error-prone, even without deep Dockerfile expertise.
The Pain Points of Dockerfiles
Thomas began by highlighting the common frustrations associated with writing and maintaining Dockerfiles. These include:
– Complexity: Writing effective Dockerfiles requires understanding various instructions, their order, and how they impact caching and layer size.
– Time Consumption: Manually writing and optimizing Dockerfiles for different projects can be time-consuming.
– Security Concerns: Ensuring that images are built securely, minimizing attack surface, and adhering to security standards can be challenging without expert knowledge.
– Lack of Reproducibility: Small changes or inconsistencies in the build environment can sometimes lead to non-reproducible images.
These challenges can slow down development cycles and increase the risk of deploying insecure or inefficient containers.
Introducing Dofigen: Dockerfile Generation Simplified
Dofigen aims to abstract away the complexities of Dockerfile creation. Thomas explained that instead of writing a Dockerfile directly, users provide a simplified description of their application and its requirements in a YAML or JSON file. This description includes information such as the base image, application files, dependencies, ports, and desired security configurations. Dofigen then takes this description and automatically generates an optimized and standards-compliant Dockerfile. This approach allows developers to focus on defining their application’s needs rather than the intricacies of Dockerfile syntax and best practices. Thomas showed a live coding demo, transforming a simple application description into a functional Dockerfile using Dofigen.
Built-in Best Practices and Security Standards
A key advantage of Dofigen is its ability to embed best practices and security standards into the generated Dockerfiles automatically. Thomas highlighted that Dofigen incorporates knowledge about efficient layering, reducing image size, and minimizing the attack surface by following recommended guidelines. This means users don’t need to be experts in Dockerfile optimization or security to create robust images. The tool handles these aspects automatically based on the provided high-level description. Thomas might have demonstrated how Dofigen helps in creating multi-stage builds or incorporating user and permission best practices, which are crucial for building secure production-ready images. By simplifying the process and baking in expertise, Dofigen empowers developers to containerize their applications quickly and confidently, ensuring that the resulting images are not only functional but also optimized and secure. The open-source nature of Dofigen also allows the community to contribute to improving its capabilities and keeping up with evolving best practices and security recommendations.
Links:
- Thomas DA ROCHA: https://www.linkedin.com/in/thomasdarocha/
- Lenra: https://www.lenra.io/
- Dofigen on GitHub: https://github.com/lenra-io/dofigen
- Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
- Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
- Devoxx France Website: https://www.devoxx.fr/