[VoxxedDaysBucharest2026] Mastering Performance Optimization in Java: Roberto Cortez on Writing Efficient Code
Lecturer
Roberto Cortez is a Senior Software Engineer at Red Hat and a prominent contributor to the Quarkus project, with particular expertise in configuration systems, startup performance, and runtime efficiency optimizations. With years of experience in Java development and cloud-native technologies, Roberto focuses on making Java applications faster, more resource-efficient, and better suited for modern deployment environments.
Abstract
In many development projects, functional delivery takes precedence while performance considerations are deferred until bottlenecks become apparent. Roberto Cortez challenges this approach through a detailed examination of efficient Java coding practices. Using real-world examples from Quarkus development, he demonstrates essential tools including Async Profiler for visualization, JMH for benchmarking, and Java Flight Recorder. Through iterative optimization of concrete code examples, he illustrates the importance of measurement, analysis, and continuous refinement.
The Perils of Assumption and the Imperative of Measurement
Roberto draws from his extensive work on Quarkus configuration loading to highlight how seemingly minor implementation details can have outsized performance impacts. He gently critiques the common misinterpretation of Donald Knuth’s famous quote about premature optimization, clarifying that while not every piece of code requires micro-optimization, developers must remain vigilant about critical execution paths that significantly affect user experience or resource consumption.
A central example involves a simple string prefixing operation implemented using Java Streams. While the code appears clean and idiomatic, profiling reveals substantial hidden costs in object allocations and temporary structures. This serves as a powerful reminder that intuition alone is insufficient — empirical measurement must guide optimization decisions.
Profiling with Async Profiler and Flame Graphs
Async Profiler emerges as a key tool due to its low overhead and rich visualization capabilities. When attached to a running Quarkus endpoint responsible for generating lists of names, the resulting flame graphs clearly highlight hotspots in StringBuilder usage and intermediate object creation. These visualizations prove invaluable for understanding complex runtime behavior where application code often represents only a small fraction of total execution time due to framework, JVM, and library interactions.
Roberto demonstrates practical usage patterns and interpretation techniques that enable developers to quickly identify and address performance bottlenecks.
Benchmarking with JMH for Rigorous Comparison
For precise, statistically sound measurements, Roberto turns to the Java Microbenchmark Harness (JMH). He presents detailed benchmarks comparing multiple implementations of the prefixing task: traditional Streams, parallel Streams, manual for-loops, and optimized versions reusing StringBuilder instances. Results across different Java versions (17, 21, and experimental 25) reveal how JVM improvements can render certain hand-optimizations obsolete or even counterproductive.
Additional demonstrations focus on environment variable resolution in Quarkus, where iterative refinements including custom equals and hashCode implementations yield substantial gains in both startup time and memory consumption.
Sustained Vigilance, Real-World Impact, and Lessons Learned
Performance optimization is portrayed as an ongoing discipline rather than a one-time activity. Roberto shares how optimizations introduced in Quarkus 3.5 required revisiting and partial reversion in version 3.6 due to upstream changes. The famous “One Billion Row Challenge” serves as an inspiring example of extreme creativity and technical depth in pursuit of performance.
Key takeaways include focusing optimization efforts on high-impact areas, balancing readability and maintainability concerns, and maintaining rigorous measurement practices throughout the development lifecycle. Developers are encouraged to cultivate a performance-aware mindset while avoiding premature or counterproductive optimizations.
Links:
[DevoxxFR2026] GitHub Actions as a Supply Chain Security Time Bomb: Real-World Attacks and Defensive Strategies
Lecturer
Thierry Abalea is the co-founder and CEO of Shipfox, a French AI Factory platform specializing in coding agent workflows. With a background in software development and security, he focuses on practical approaches to securing modern CI/CD pipelines in cloud-native environments.
Abstract
GitHub Actions has become a cornerstone of modern CI/CD practices, yet it remains insecure by default. Recent supply chain attacks such as those targeting tj-actions, s1ngularity, GhostAction, and Shai-Hulud have demonstrated how adversaries systematically exploit workflows to exfiltrate secrets and compromise downstream projects. This presentation dissects concrete attack vectors observed in 2025, explains why traditional mitigations fall short, and outlines actionable defenses including scoped secrets with approval workflows, minimal GITHUB_TOKEN permissions, egress controls, runner hardening, and runtime protection tools. Attendees gain a clear understanding of the current threat landscape and practical steps to secure their pipelines.
The Critical Role and Inherent Risks of CI/CD in Modern Development
Continuous integration and continuous deployment pipelines manage extraordinarily sensitive assets: source code manipulation, secret handling for production access, and package publishing. Any compromise here can lead to widespread downstream damage. Thierry Abalea emphasizes that while GitHub Actions provides powerful automation, its permissive default configuration creates a vast attack surface. Workflows often run with broad permissions, handle long-lived secrets, and interact with external networks without sufficient restrictions.
The 2025 attack wave—including Singularity targeting Nx builds, Shai-Hulud as the first npm-propagating worm, and multiple incidents against Trivy—highlighted how GitHub Actions serves as both an entry point for initial compromise and a vector for secret exfiltration and lateral movement. These incidents affected hundreds of organizations, underscoring that CI/CD security can no longer be treated as secondary to application security.
Dissecting Major Supply Chain Attacks via GitHub Actions
Several high-profile incidents illustrate common exploitation patterns. The Singularity attack combined batch injection vulnerabilities in pull request workflows with the pull_request_target trigger. This allowed attackers to exfiltrate secrets from forked repositories, including NPM tokens used to publish malicious packages. Downstream consumers of the compromised Nx tool were subsequently affected.
Shai-Hulud represented a novel worm-like propagation through npm. Attackers gained secrets via similar workflow vulnerabilities, published malicious packages, and leveraged maintainer permissions across multiple projects. This created cascading compromises as infected packages spread through dependency trees.
Trivy, a widely used open-source security scanner, suffered repeated attacks. Initial exploitation via pull_request_target and unsafe interpolation led to remote code execution, secret exfiltration (including high-privilege GITHUB_TOKENs), repository privatization, and deletion of releases. A follow-up attack succeeded due to incomplete secret rotation, enabling further malicious package publications.
These cases reveal recurring themes: overly permissive triggers, secret exposure in workflows, and insufficient isolation between CI environments and production assets.
Why Default GitHub Actions Security Falls Short
GitHub Actions operates with broad defaults that favor convenience over security. Workflows can trigger on untrusted events like pull_request_target, granting access to repository secrets. The GITHUB_TOKEN often possesses excessive permissions, especially in repositories created before 2023. Actions referenced by mutable tags (e.g., v3) can be hijacked by attackers controlling upstream repositories. Self-hosted runners, if not properly isolated, allow one compromised job to affect the entire machine.
Network egress remains largely unrestricted, enabling easy data exfiltration to attacker-controlled servers or even private repositories. Traditional advice—pinning actions and limiting secrets—proves insufficient against sophisticated chained exploits.
Practical Defenses: Hardening GitHub Actions Workflows
Effective protection requires a defense-in-depth approach. Begin by scoping secrets with approval rules, ensuring only necessary workflows can access them. Minimize GITHUB_TOKEN permissions on a per-workflow basis, adhering to the principle of least privilege. Implement egress controls to restrict outbound connections from runners.
For self-hosted runners, enforce ephemeral instances and strong isolation. Tools like Step Security provide runtime hardening and firewall-like controls around runners, while GitHub’s upcoming Level 7 runner protections promise kernel-level isolation outside the runner’s reach.
Static analysis tools such as CodeQL (free for open source) and Zizmor detect workflow vulnerabilities. Dependency review bots help manage pinned versions. Organizations should treat CI/CD as production-equivalent, applying the same scrutiny to workflows as to application code.
Runtime protections and regular secret rotation further reduce the blast radius of potential breaches. Automation of security scanning within pull requests ensures issues are caught early.
Conclusion: Treating CI/CD as Production Infrastructure
GitHub Actions represents both a productivity powerhouse and a significant supply chain risk. By understanding real attack patterns and implementing layered defenses—from minimal permissions and scoped secrets to runtime controls and automated analysis—teams can substantially reduce their exposure. Security must be integrated from the outset of workflow design rather than bolted on afterward. As attackers increasingly target the CI layer, proactive hardening becomes essential for maintaining trust in modern software delivery pipelines.
Links:
[AWSReInvent2025] Beyond Migration: Transforming Global Automotive Retail with SAP and Pan-Amazon Services
Lecturer
Sunnuk Kim is the Vice President and Head of the IT Strategy and Planning Division at Hyundai Motor Group. Based in Seoul, he is a primary architect of the group’s digital strategy, focusing on integrating legacy industrial operations with modern cloud intelligence to redefine the automotive lifecycle. Mahesh Shrivastava is a Director and Global Leader for SAP on AWS. He specializes in enterprise-scale digital transformation, helping multinational corporations move beyond infrastructure optimization to achieve true business model innovation through cloud-native ecosystems.
Abstract
The modern enterprise technology landscape is undergoing a fundamental shift where global organizations no longer view cloud migration as an isolated technical objective but rather as a catalyst for comprehensive business transformation. This article examines the strategic collaboration between Hyundai Motor Group and Amazon Web Services (AWS) to modernize its mission-critical SAP environment through the integration of “Pan-Amazon” services. By moving beyond traditional “lift-and-shift” methodologies, Hyundai has adopted a “clean core” strategy that bridges the gap between back-office ERP functions and front-end consumer touchpoints. The analysis explores how the integration of Amazon Business, Prime logistics, and multi-channel fulfillment centers with SAP allows Hyundai to optimize global sales, inventory management, and personalized retail experiences. This transformation signifies the evolution of the automotive industry into a data-driven, customer-centric retail model.
The Strategic Shift: From Infrastructure Migration to Business Evolution
Historically, large-scale enterprises approached the cloud with the narrow objective of reducing capital expenditure by transitioning physical data centers to virtualized environments. For a global manufacturer like Hyundai, the initial focus was often on the stability and performance of SAP systems that manage the “heartbeat” of production and finance. However, as market dynamics evolved toward direct-to-consumer models and digital-first interactions, the group identified that true value lay in how cloud-native capabilities could solve complex business challenges. This realization prompted a move away from simply “running” SAP in the cloud toward “transforming” the business through the cloud.
The strategic pivot was driven by an urgent need for customer-centricity, requiring Hyundai to provide seamless, omnichannel experiences that mirror the speed and predictability of modern e-commerce. Furthermore, the limitations of rigid, monolithic legacy architectures necessitated a “clean core” approach. This methodology allows the organization to maintain a stable, standard ERP foundation while rapidly innovating through extensions and external integrations. By breaking down the long-standing silos between manufacturing data and external consumer insights, Hyundai has positioned itself to make real-time decisions that directly impact global sales volume and customer retention.
Methodology: Integration of the Pan-Amazon Ecosystem
A core innovation in Hyundai’s transformation is the sophisticated utilization of “Pan-Amazon” services, a broad collection of Amazon’s diverse business units that are now integrated directly into the AWS cloud platform. This strategy extends far beyond typical compute and storage services. For instance, the integration of Amazon Business has allowed Hyundai to streamline indirect procurement and supply chain management directly within the SAP workflow, reducing manual overhead and improving spend visibility.
Furthermore, the application of Amazon Prime and its global fulfillment network to the automotive sector represents a significant methodology shift. By leveraging these world-class logistics models, Hyundai can manage automotive parts and vehicle accessories with unprecedented efficiency. This creates a “Y process” where product portfolio management and sales volume planning converge. In this model, the back-office operations managed by SAP are directly connected to the front-end retail experience. This integration ensures that when a customer interacts with a digital retail channel, the system can provide real-time data on vehicle availability, delivery timelines, and personalized configuration options, all backed by a robust, cloud-native logistics engine.
Technical Analysis of Modernized Operations
The transition from legacy environments to an AWS-integrated SAP landscape has yielded transformative results across several key performance indicators. In terms of scalability, the previous architecture was constrained by fixed capacity and physical hardware limitations, whereas the current AWS-integrated system offers elastic scaling that adapts to real-time demand spikes without manual intervention. Global inventory management has transitioned from fragmented data silos, which often suffered from latency and inaccuracies, to a unified system providing real-time visibility across all global fulfillment centers.
Customer experience has seen a similar leap in sophistication. What was once a linear and offline-heavy journey has been replaced by an integrated omnichannel digital retail platform that provides consumers with the speed and reliability they expect from modern digital platforms. This operational efficiency at scale is further supported by the ability to access the world’s largest online marketplace and fulfillment network. The technical result is a modular environment where the core ERP remains upgradable and stable while a vast array of custom, cloud-native services drive innovation on the periphery. This architecture ensures that even as the company expands into new geographic regions or business channels, the underlying infrastructure remains resilient and performant.
Implications for Global Automotive Retail and Beyond
The consequences of Hyundai’s “Go to Cloud” strategy are profound for the broader automotive sector. The industry is moving toward a state of direct-to-consumer readiness, where traditional dealership models are being augmented by digital platforms that offer complete transparency and predictability. This shift is enabled by the ability to treat vehicle sales not as a one-time transaction, but as a continuous relationship supported by digital services and efficient parts logistics.
The success of this project also highlights the importance of data-driven innovation. By analyzing vast amounts of data across the combined SAP and Amazon ecosystem, Hyundai can better forecast market trends and optimize production cycles accordingly. This represents a broader trend of Industry 4.0, where the lines between manufacturing, retail, and technology are increasingly blurred. The ability to achieve such high levels of operational agility while maintaining a secure and compliant global footprint sets a new benchmark for enterprise-scale digital transformation.
Conclusion
The collaboration between Hyundai Motor Group and AWS serves as a comprehensive blueprint for how large enterprises can successfully navigate the complexities of modernizing mission-critical systems. By prioritizing the customer experience and leveraging the full breadth of the Pan-Amazon ecosystem, Hyundai has evolved from a traditional manufacturer into a leader in digital automotive retail. The journey underscores that the future of enterprise IT is defined not just by the technology itself, but by the intelligent integration of diverse services to create tangible business value. As global competition intensifies, the move toward a “clean core” SAP environment supported by cloud-native logistics and AI will be the defining factor for sustainable growth and innovation.
Links:
[VoxxedDaysAmsterdam2026] Framework Desktop and Incus OS: An Efficient Setup for Local LLM Deployment
Lecturer
Peter Smink works with Team Roxy and collaborates with AMD on advanced hardware solutions. He focuses on practical approaches to running AI workloads locally, emphasizing privacy, cost control, and energy efficiency through modern container and virtualization technologies.
Abstract
Running large language models locally addresses critical concerns around data privacy, operational costs, and environmental impact, yet requires careful hardware and software configuration. Peter Smink presents the combination of Framework Desktop hardware with Incus OS as a compelling solution for local LLM deployment. The discussion covers the advantages of this setup, practical implementation steps, encountered challenges, and real-world performance characteristics. Through detailed examination of the installation process, GPU passthrough configuration, and model execution, the presentation demonstrates how this approach enables efficient, private, and sustainable AI development while maintaining flexibility for broader container and virtual machine workloads.
Advantages of Local LLM Deployment with Modern Hardware and Virtualization
Local execution of large language models offers distinct benefits compared to cloud-based alternatives. Privacy concerns are eliminated when sensitive data never leaves organizational infrastructure. Operational costs become predictable without recurring API charges or token-based billing. Energy consumption can be monitored and optimized at the hardware level, supporting sustainability goals. Additionally, local setups provide greater control over model selection and experimentation, unconstrained by provider limitations or network dependencies.
The Framework Desktop platform, powered by AMD Ryzen processors with integrated AI capabilities, delivers high performance within a compact and power-efficient form factor. Configurations supporting up to 128 GB of memory and efficient power envelopes ranging from 80 watts upward make it suitable for demanding workloads while maintaining reasonable energy profiles. The modular design allows for future upgrades and ensures hardware longevity beyond specific AI use cases.
Incus OS complements this hardware by providing a modern, secure, and flexible virtualization and containerization layer. Built on immutable Linux foundations with secure boot and TPM support, it offers robust isolation for workloads. The system includes built-in update mechanisms and supports both containers and virtual machines through a unified command-line interface. This versatility allows teams to run AI inference alongside other development or production services on the same infrastructure.
Implementation Process and Configuration Details
Setting up the environment begins with client preparation. The Incus client must be installed and configured with appropriate certificates for secure communication with the target system. This client serves as the primary interface for managing the remote Incus instance.
Image creation follows, utilizing the flasher tool to generate a customized Incus OS image. Configuration files specify critical parameters including the target disk, graphics drivers for AMD hardware, and PCI passthrough settings for GPU access. The process ensures that the resulting image includes necessary drivers and security configurations tailored to the Framework Desktop hardware.
On the hardware side, BIOS preparation involves enabling secure boot and clearing existing certificates to accommodate the new installation. CPU and memory settings are optimized for the installation phase. Once the USB image is created and booted, the automated installation process configures the system according to the provided specifications.
Post-installation steps focus on network configuration and virtual machine setup. A dedicated network is established for VM connectivity. The AI server virtual machine is then created with substantial memory allocation and direct GPU passthrough. This configuration enables the virtual machine to leverage hardware acceleration for model inference.
Within the virtual machine, environment preparation includes kernel updates, installation of necessary tools, and configuration of user groups for GPU access. The latest AMD graphics drivers ensure optimal performance. Verification steps confirm that the GPU is properly recognized and accessible to the inference software.
Operational Characteristics and Performance Considerations
The resulting setup demonstrates strong performance for local inference tasks. Token generation rates vary based on model size and configuration, with observed averages ranging from 25 to 60 tokens per second and peaks approaching 90 tokens per second under optimal conditions. Power consumption remains efficient, typically between 18 and 130 watts depending on workload intensity.
The combination supports models that may exceed the capacity of individual graphics cards by leveraging system memory and CPU resources effectively. Privacy is maintained as all processing occurs locally without external data transmission. Cost predictability eliminates concerns about variable cloud pricing or usage spikes.
The platform’s reusability adds significant value. Should AI-specific requirements evolve, the hardware remains fully functional as a general-purpose server or development workstation. This contrasts with specialized AI accelerators that may become obsolete or underutilized outside narrow use cases.
Challenges and Lessons Learned
Several practical challenges emerge during implementation. Certificate and client configuration require precise sequencing to ensure secure connectivity. Incorrect order or missing privileges can result in systems that fail to communicate properly. GPU passthrough configuration demands careful attention to hardware and driver compatibility.
Kernel updates and driver installations must align with the specific hardware platform. Recent changes in driver APIs have occasionally created compatibility hurdles, though newer versions have improved stability significantly. Memory and storage requirements for both the host system and virtual machines necessitate careful planning to avoid resource contention.
Despite these considerations, the overall setup process proves manageable with appropriate documentation and systematic verification at each stage. The modular nature of both hardware and software components allows for iterative refinement as requirements evolve.
Strategic Value for AI Development and Beyond
This hardware and software combination addresses multiple strategic objectives simultaneously. Privacy-conscious organizations gain a viable alternative to cloud services without sacrificing performance. Development teams benefit from rapid iteration cycles and direct hardware access for experimentation. Cost-sensitive projects maintain predictable operational expenses while avoiding vendor lock-in.
The solution extends beyond pure AI inference. The underlying Incus platform supports diverse workloads, making the infrastructure adaptable to changing organizational needs. Teams can experiment with different models, quantization techniques, and inference engines while maintaining consistent operational procedures.
Energy efficiency aligns with growing sustainability requirements in technology operations. The ability to monitor and control power consumption at the hardware level supports both environmental goals and operational cost management.
As AI adoption continues across industries, solutions that balance capability, control, and efficiency become increasingly valuable. The Framework Desktop paired with Incus OS represents one practical approach to achieving these objectives while maintaining flexibility for future requirements.
Links:
[DevoxxGR2026] GenAI on Kubernetes: Training, Inference, and Serving in Production Environments
Lecturer
Alessandro Vozza is a seasoned cloud-native advocate and technologist with deep expertise in Kubernetes and AI/ML operations. He contributes actively to open-source communities and focuses on practical, scalable deployments of generative AI workloads. As a speaker and practitioner, Alessandro emphasizes operational excellence, resource efficiency, and the integration of modern AI tools within established cloud-native platforms.
Abstract
In this hands-on tutorial at Devoxx Greece 2026, Alessandro Vozza guides developers through the complete lifecycle of running generative AI workloads on Kubernetes. From distributed training jobs with GPU scheduling to optimized inference and scalable model serving, the session demonstrates how to leverage operators, autoscaling, vector stores, and frameworks like KServe, Ray, vLLM, and Kubeflow. Attendees gain actionable insights into designing efficient GPU clusters, fine-tuning models securely, and deploying production-grade architectures that integrate seamlessly with existing Kubernetes expertise.
The Convergence of Kubernetes and Generative AI
Kubernetes has evolved into the de facto platform for orchestrating complex, resource-intensive workloads, including those powered by generative AI. Vozza begins by contextualizing the challenges: training large models demands massive parallel computation across GPUs, inference requires low-latency serving under variable traffic, and the entire pipeline must remain observable, secure, and cost-effective. Traditional approaches struggle with these demands, but Kubernetes patterns—scheduling, autoscaling, and declarative resource management—provide a robust foundation.
The session highlights how the community has responded with specialized tools. Projects like Kubeflow address the full ML lifecycle, while KServe and vLLM focus on high-performance inference. These build upon core Kubernetes capabilities, allowing teams to treat AI workloads with the same rigor applied to microservices.
Distributed Training and GPU Orchestration
Training generative models is computationally intensive and benefits enormously from Kubernetes’ scheduling strengths. Vozza demonstrates launching distributed training jobs, emphasizing GPU-aware scheduling through device plugins and resource requests. Nodes are labeled with GPU capacity, enabling the scheduler to place pods on suitable hardware.
The tutorial covers hyperparameter tuning with tools like Katib, which automates experimentation across multiple configurations. Fine-tuning involves augmenting base models with domain-specific data, a process that Kubernetes orchestrates reliably through persistent volumes and checkpointing. Attendees learn to monitor training progress using built-in observability and handle failures gracefully with retries and job controllers.
Resource efficiency emerges as a key theme. Techniques such as multi-instance GPU (MIG) partitioning allow a single physical GPU to support multiple smaller workloads, maximizing utilization without over-provisioning expensive hardware.
Inference Serving and Model Deployment
Once trained, models must be served efficiently. Vozza walks through deploying inference endpoints with KServe, which abstracts the complexities of scaling and routing. vLLM serves as the high-throughput inference engine, leveraging continuous batching and paged attention for superior performance.
The architecture supports multi-model serving, where a single deployment handles various models based on request characteristics. Gateway API extensions make the ingress layer LLM-aware, enabling intelligent routing based on factors like key-value cache state or model specialization. This ensures optimal resource allocation and minimal latency.
Autoscaling plays a critical role. Horizontal Pod Autoscaler (HPA) combined with KEDA reacts to custom metrics such as queue depth or tokens processed per second, dynamically adjusting replicas to match demand while controlling costs.
Operational Considerations and Best Practices
Production readiness demands comprehensive observability. Vozza integrates Prometheus exporters and logging to track token throughput, latency, and GPU utilization. Security best practices include least-privilege access for model endpoints and encrypted communication.
The tutorial addresses common pitfalls: managing model registries for versioning, handling cold starts through caching, and ensuring reproducibility across environments. By treating models as first-class Kubernetes citizens, teams achieve consistent deployments from development to production.
Practical Roadmap and Future Directions
Participants receive a working reference setup they can adapt immediately. Vozza encourages starting small—perhaps with a single-model inference service—before scaling to distributed training and multi-model architectures. The session reinforces that Kubernetes knowledge directly transfers to AI operations, lowering the barrier for traditional platform teams.
Looking ahead, evolving features like dynamic resource allocation and improved GPU topology awareness will further streamline GenAI workloads. The message is clear: Kubernetes is not merely compatible with generative AI; it is becoming the preferred operational layer for the entire lifecycle.
Links:
[GoogleIO2025] Google’s AI stack for developers
Keynote Speakers
Joana Carrasqueira holds the position of Head of Developer Relations at Google DeepMind, where she leads efforts to empower developers with AI tools and resources. With an MBA from IE Business School and a background transitioning from pharmaceutical science to technology, she focuses on bridging research and practical applications to foster innovation.
Josh Gordon serves as the lead for AI Developer Relations at Google, guiding the adoption of machine learning technologies. Holding a degree from Columbia University, he brings over 15 years of experience in AI, emphasizing accessible tools for developers across various domains.
Abstract
This scholarly review examines Google’s comprehensive AI ecosystem, spanning infrastructure, frameworks, and developer tools designed to facilitate robust AI applications. It analyzes foundational models like Gemini and Gemma, alongside frameworks such as JAX and Keras, elucidating their architectural designs, integration strategies, and contributions to fields like robotics and healthcare. By evaluating demonstrations and strategic alignments, the discussion highlights implications for collaborative innovation, ethical AI deployment, and accelerated research-to-reality transitions in a developer-centric landscape.
Infrastructure and Model Foundations
Joana Carrasqueira and Josh Gordon open by outlining Google’s AI stack, rooted in decades of leadership from TensorFlow’s open-sourcing in 2015 to transformative research like Transformers in 2017, culminating in the Gemini era. Carrasqueira emphasizes the stack’s flexibility, combining infrastructure with cutting-edge research to enable real-world impacts across industries.
Central are foundation models, with Gemini’s multimodal native design processing text, images, video, audio, and code seamlessly. Gordon details Gemini’s families: Pro for balanced performance, Flash for efficiency, and Ultra for complex tasks. Innovations like 2.5 Pro’s long-context reasoning and audio understanding advance agentic capabilities, while Gemma’s lightweight variants—3N at 3B parameters—run on edge devices with audio features.
Methodologies involve pre-training on diverse datasets, yielding state-of-the-art benchmarks. Contexts include democratizing AI, with implications for inclusive access, though necessitating safeguards against biases.
Domain-specific models like Med-Gemma analyze medical images, while robotics variants incorporate physical actions. These extend multimodal reasoning to practical domains, implying transformative applications in healthcare and automation.
Frameworks for Research and Application
Gordon transitions to frameworks, with JAX suiting researchers via NumPy-like APIs and just-in-time compilation for high-performance computations. Its composability—via transformations like grad and vmap—facilitates gradient computations and vectorization.
Code sample for JAX gradient:
import jax
import jax.numpy as jnp
def f(x):
return jnp.sin(x) * x
grad_f = jax.grad(f)
print(grad_f(3.0))
Keras, for applied AI, offers intuitive layers, with Keras 3 supporting backends like JAX, TensorFlow, and PyTorch. Its multi-backend nature implies cross-framework portability.
PyTorch collaborations enhance interoperability, with implications for unified ecosystems reducing vendor lock-in.
Developer Tools and Community Engagement
Carrasqueira highlights tools like AI Studio for no-code prototyping and Gemini API for multimodal integrations. Features like system instructions and caching optimize interactions.
Vertex AI provides enterprise-grade capabilities, with agents orchestrating tasks via tools. Implications include scalable production deployments.
Community resources—cookbooks, forums—foster collaboration, implying accelerated innovation through shared knowledge.
Breakthroughs and Future Directions
Gordon showcases AlphaFold 3’s molecular predictions and Alpha Evolve’s material discoveries, demonstrating AI’s scientific acceleration. Robotics models enable dexterous actions, implying industrial transformations.
The stack’s end-to-end nature—from models to tools—implies seamless pipelines, with ethical considerations paramount for societal benefits.
Links:
[DevoxxFR2026] Common Expression Language (CEL): A Fast, Portable, and Secure Expression Language for Modern Applications
Lecturer
Alex Snaps is a Tech Lead at Red Hat working on the Quarkus project. He maintains the Rust implementation of CEL and contributes to the broader ecosystem, bringing deep expertise in language runtimes, performance, and secure extensibility.
Abstract
Alex Snaps introduces the Common Expression Language (CEL), a domain-agnostic expression language designed for safe, high-performance evaluation within larger applications. Originating from Google, CEL emphasizes strong typing, sandboxed execution, and extensibility while maintaining portability across implementations in Go, Java, C++, Rust, and others. Through syntax exploration, type checking, cost estimation, and practical integration examples, the talk demonstrates why CEL excels for policy enforcement, validation, filtering, and authorization in cloud-native and API-driven environments.
Origins and Design Philosophy of CEL
CEL emerged from Google’s need for a lightweight, embeddable expression evaluator capable of running safely in performance-critical paths. First released around 2017 (with earlier internal variants), it targets scenarios where user-provided or configuration-driven logic must execute with predictable latency and strict safety guarantees. Unlike general-purpose scripting languages, CEL deliberately restricts Turing-completeness to prevent denial-of-service through infinite loops or excessive computation.
Core tenets include:
- Strong Static Typing: All expressions are type-checked before evaluation.
- Predictable Performance: Cost estimation and constant folding occur at check time.
- Portability: Abstract Syntax Tree (AST) format enables cross-language evaluation.
- Extensibility: Custom functions, macros, and types can be added per domain.
These properties make CEL ideal for Kubernetes (Custom Resource Definition validation), API gateways, authorization systems, and configuration engines.
Syntax and Core Language Features
CEL syntax resembles a blend of C-style expressions and modern collection comprehensions. Basic operations, conditionals, and field access feel familiar:
- Arithmetic and comparisons
- Logical operators
- Ternary expressions
- Optional chaining with
?andor - Collection operations via macros like
exists,all,map
Notable features include:
- Macros:
all(resources, r, r.startsWith('email'))binds variables and applies predicates. - Optional Navigation:
obj.?field.or(0)safely accesses potentially absent fields. - Message Construction: Direct construction of Protocol Buffer messages within expressions.
- Strict Typing: No implicit coercion;
uint(1) == 1fails type checking.
The language integrates seamlessly with Protocol Buffers, treating well-known types like timestamps and durations as first-class citizens.
The Evaluation Pipeline: Parse, Check, Evaluate
CEL processing follows a clear separation optimized for control-plane versus data-plane workloads:
- Parse: Validates syntax and produces an AST. Feature flags can disable risky syntax (e.g., optional navigation).
- Check: Performs type resolution, overload selection, constant folding, and cost estimation. This phase catches errors early and enables optimization.
- Evaluate: Executes the (potentially optimized) AST against a bound environment in the hot path.
Environments declare variables and functions available to expressions. Cost limits prevent expensive evaluations in production.
Portability shines here: an AST checked in one language can be evaluated in another, facilitating polyglot systems.
Extensibility and Real-World Integration
CEL’s power emerges through domain-specific extensions. Custom functions, member overloads, and macros allow tailoring to specific needs without compromising safety.
In the Quarkus/Gateway API context, CEL evaluates policies attached to Kubernetes resources. Expressions navigate complex object graphs, enforce authorization, and implement fine-grained controls. The Rust implementation (maintained by Snaps) demonstrates low-level integration, including trait-based value handling and flexible indexing.
Examples illustrate adding domain functions like isPrime or complex policy logic matching gateways and routes.
Performance, Security, and Ecosystem Maturity
CEL achieves high performance through ahead-of-time type checking, constant folding, and minimal runtime overhead. Implementations in Go and Java (reference) are mature; Rust and others continue evolving toward full specification compliance.
Security model emphasizes sandboxing: no arbitrary code execution, bounded computation, and explicit environment control. This makes CEL suitable for untrusted user input in API filters, validation rules, and authorization decisions.
The ecosystem includes playgrounds, conformance test suites, and codelabs across languages, lowering the barrier to adoption.
Conclusion
Common Expression Language offers a compelling balance of expressiveness, safety, and speed for embedding dynamic logic in applications. Its strong typing, cost awareness, and extensibility address real challenges in cloud-native policy and configuration management. As organizations seek safer alternatives to full scripting engines, CEL provides a mature, battle-tested solution that continues gaining traction across diverse technology stacks.
Links:
[AWSReInforce2025] Eliminating blind spots in your security monitoring strategy (TDR203)
Lecturer
Andrew Krug leads Security Advocacy and Research at Datadog, directing initiatives that bridge observability and security through runtime context, threat research, and open-source tooling. His team publishes annual State of Cloud Security reports and maintains detection content for AWS environments.
Abstract
The session constructs a comprehensive monitoring framework that eliminates coverage gaps across generative AI, Kubernetes, and SaaS ecosystems. By combining cloud audit logs with runtime telemetry and behavioral enrichment, it enables precise threat detection while reducing alert fatigue through contextual prioritization.
Modern Cloud Attack Surface Expansion
Emerging technologies introduce new blind spots:
- Generative AI: Prompt injection, model theft via API
- Kubernetes: Container escape, privileged pod execution
- SaaS Platforms: Shadow IT, over-permissive API tokens
Traditional log-based detection misses runtime context—process lineage, file system activity, network connections—that reveals true intent.
Runtime Security Instrumentation Patterns
Datadog implements multi-layered telemetry:
collectors:
- ebpf_process_tracking
- container_runtime_socket
- cloud_api_polling
- dns_query_capture
eBPF programs capture system calls without kernel module deployment. Integration with AWS services provides:
- CloudTrail → API activity
- VPC Flow Logs → network relationships
- GuardDuty → threat intelligence
Contextual Detection Engineering
Rules incorporate runtime signals:
if process.name == "curl" and
parent.process.name == "sh" and
network.destination.ip in known_c2:
trigger_alert(severity="HIGH")
Behavioral baselining identifies anomalies—legitimate developers use curl; cryptominers spawn it from compromised containers.
OCSF Standardization Benefits
Adoption of Open Cybersecurity Schema Framework enables:
{
"activity_id": 1,
"category_name": "network",
"class_name": "dns_activity"
}
- Vendor-agnostic rule authoring
- Simplified parser maintenance
- Portable detection content
Datadog contributes 200+ OCSF-normalized rules to the community.
Alert Prioritization and Noise Reduction
Runtime context transforms alerts:
Raw Event: S3 bucket made public
+ Runtime: No process accessed bucket in 90 days
= Low Priority (likely misconfiguration)
Raw Event: S3 bucket made public
+ Runtime: Ransomware process enumerating objects
= Critical Priority (active compromise)
This approach reduces false positives by 70% while maintaining detection efficacy.
Integrated Response Workflows
Security teams operationalize through:
- Triage: Unified dashboard with process trees
- Containment: One-click instance isolation
- Investigation: Session replay with system call tracing
- Remediation: Automated patch deployment
Conclusion: Observability as Security Foundation
Runtime security complements rather than replaces logging strategies. The fusion of behavioral telemetry, standardized schemas, and cloud-native context creates a monitoring fabric that scales with innovation velocity. Organizations achieve comprehensive coverage without sacrificing signal quality.
Links:
[AWSReInvent2025] Transforming Integrated Diagnostics: Philips’ AI-Driven Evolution on AWS
Lecturer
Sam Cool is a Director and Global Lead for Healthcare Solutions at Amazon Web Services (AWS), where he focuses on accelerating digital transformation for global health organizations. With extensive experience in cloud architecture and clinical workflows, Sam works with industry leaders to dismantle data silos and implement scalable AI solutions. Jared Nicks is a Principal Solutions Architect at AWS, specializing in medical imaging and Health-IT. His work is instrumental in developing the AWS HealthImaging service, which provides high-performance storage and retrieval for large-scale medical datasets. Wilson Toe serves as a Senior Product Manager at AWS, focusing on the intersection of Generative AI and healthcare analytics. Dr. Praeloski is a Senior Clinical Scientist at Philips, bringing decades of expertise in diagnostic imaging, pathology, and cardiology. He leads Philips’ efforts to integrate multi-modal data into a unified platform that enhances clinical decision-making. Together, these experts have pioneered a collaboration that leverages cloud-native technologies to redefine the diagnostic landscape.
Abstract
Modern healthcare is characterized by an explosion of diagnostic data, yet this information remains largely fragmented across disparate systems for radiology, cardiology, and pathology. This fragmentation hampers the ability of clinicians to form a holistic view of the patient, leading to diagnostic delays and suboptimal treatment planning. This article examines the strategic journey of Philips in transforming integrated diagnostics through its partnership with AWS. By shifting from on-premises infrastructure to a cloud-native architecture, Philips has successfully integrated diverse data streams, with a particular focus on the emerging frontier of digital pathology. The discussion explores the technical implementation of AWS HealthImaging, the transition to standardized DICOM formats for pathology, and the application of Generative AI to streamline clinical reporting. Ultimately, this framework enables global collaboration and real-time diagnostic consensus, moving the needle toward truly personalized and precise medicine.
The Paradox of Fragmented Diagnostic Intelligence
The clinical diagnostic process is the cornerstone of patient care, influencing over 70% of medical decisions. However, the current infrastructure supporting these decisions is often a patchwork of “black boxes.” A patient’s journey typically involves multiple diagnostic touchpoints: an X-ray in radiology, an ECG in cardiology, and a tissue biopsy in pathology. Historically, each of these domains has operated in a silo, utilizing proprietary data formats and isolated storage systems. Sam observes that while the volume of data is increasing—driven by higher-resolution imaging and molecular diagnostics—the “intelligence” derived from that data remains localized.
For a clinician, this fragmentation means navigating multiple interfaces and manually correlating reports, a process prone to error and inefficiency. The transition to integrated diagnostics is not merely a technical upgrade; it is a clinical necessity. By centralizing these streams in the cloud, healthcare providers can move from a reactive, department-centric model to a proactive, patient-centric one. Philips’ vision for integrated diagnostics centers on breaking down these silos to provide a “single source of truth” for every patient, regardless of where the data was generated.
Digital Pathology: The Final Frontier of Digitalization
While radiology and cardiology have been digital for decades, pathology—the study of tissue samples—has remained stubbornly analog. For over a century, pathologists have relied on glass slides and manual microscopy. The sheer scale of the data involved has been the primary barrier; a single high-resolution digital slide can exceed several gigabytes in size, and a single patient case may involve dozens of slides.
Dr. Praeloski highlights that digital pathology represents the next great shift in clinical innovation. By digitizing these slides, Philips enables pathologists to work in an environment that is “born digital,” allowing for the application of computer vision and machine learning. This transition is facilitated by the adoption of the DICOM (Digital Imaging and Communications in Medicine) standard for pathology images. Standardizing these massive datasets allows them to be treated with the same rigor and interoperability as traditional radiological images, enabling them to be stored, shared, and analyzed within the same AWS-backed ecosystem.
Architecting for High-Throughput Imaging with AWS HealthImaging
The technical challenge of managing millions of high-resolution pathology slides requires an infrastructure that can handle extreme throughput and low-latency retrieval. Standard object storage, while durable, often struggles with the specific access patterns required for medical imaging, where a clinician needs to “zoom and pan” through a multi-gigabyte image in real-time.
To solve this, Philips leverages AWS HealthImaging. This purpose-built service allows for the ingestion of medical images at scale while providing sub-second access to specific image frames. By decoupling storage from the viewing application, AWS HealthImaging ensures that clinicians can access images from any device, anywhere in the world, without the need for high-powered local workstations.
'''# Conceptual example of fetching metadata for a DICOM image set'''
import boto3
health_imaging = boto3.client('healthimaging')
def get_image_metadata(datastore_id, image_set_id):
response = health_imaging.get_image_set_metadata(
datastoreId=datastore_id,
imageSetId=image_set_id
)
return response['metadata']
Jared emphasizes that this architecture is foundational for “high-throughput” clinical environments. In a traditional setup, moving a slide from storage to a viewer could take minutes; with HealthImaging, it takes milliseconds. This efficiency is critical in pathology, where time-to-diagnosis directly impacts patient outcomes in oncology and acute care.
Empowering Clinicians through Generative AI and Automated Reporting
Once diagnostic data is centralized and accessible, the next challenge is synthesis. Pathologists and radiologists spend a significant portion of their day dictating and transcribing findings. Generative AI offers a transformative solution by automating the creation of structured reports and summarizing complex longitudinal patient histories.
Wilson explains how Philips integrates Amazon Bedrock to assist in the “last mile” of the diagnostic process. By analyzing the metadata and AI-detected features of an image, the system can draft a preliminary report that the clinician then reviews and validates. This doesn’t replace the expert; rather, it removes the “blank page” problem and ensures that reports follow a standardized, high-quality format. Furthermore, LLMs (Large Language Models) can scan years of a patient’s prior records to highlight relevant changes—such as the growth of a lesion over time—that might be missed in a manual review.
Global Collaboration and the Future of Consensus
One of the most profound impacts of shifting integrated diagnostics to the cloud is the enablement of global collaboration. In the analog world, seeking a second opinion on a rare pathology case required physically shipping glass slides across borders—a process that was slow, expensive, and risky.
Through Philips’ cloud-native platform, a specialist in New York can consult on a case in London in real-time. The digital platform supports “shared view” sessions where multiple clinicians can annotate the same slide simultaneously. Dr. Praeloski notes that in recent surveys, 100% of pathologists using the digital system reported that it facilitated reaching a diagnostic consensus more effectively than manual methods. This democratization of expertise is particularly vital for underserved regions, where access to specialized sub-pathologists is limited.
Conclusion: A Paradigm Shift in Precision Medicine
The journey of Philips and AWS illustrates that the future of healthcare is not just about “better machines,” but about “smarter data.” By integrating radiology, cardiology, and pathology into a unified cloud-native framework, they have laid the groundwork for the next generation of precision medicine. This evolution reduces clinical burnout by automating administrative tasks, improves diagnostic accuracy through AI assistance, and accelerates the pace of care through global collaboration. As the system continues to scale, the data captured today will become the training ground for the cures of tomorrow, proving that when diagnostic intelligence is integrated, the potential for clinical innovation is limitless.
Links:
[MiamiJUG] Decoupling Business Logic via Ports and Adapters Architecture
Lecturer
Dr. Alistair Cockburn is an internationally recognized expert in software methodology and a co-author of the Agile Manifesto. Named one of the “42 Greatest Software Professionals of All Time” in 2020, Alistair has spent decades refining project management and software architecture patterns. He is the creator of the “Hexagonal Architecture,” more formally known as the Ports and Adapters pattern, which he developed to address the chronic issue of technology “leakage” in enterprise software.
Abstract
This article examines the Ports and Adapters architecture (Hexagonal Architecture) as a solution for isolating business logic from external technical dependencies. By treating an application as a self-contained component surrounded by a “test moat,” developers can ensure that core logic remains technology-agnostic and highly maintainable. The analysis covers the methodology of separating driving and driven actors, the benefits of automated regression testing in isolation, and the structural implementation of this pattern in modern development environments.
The Rationale for Isolation
The primary motivation behind Ports and Adapters is the frustration caused by software that cannot easily swap databases, drivers, or user interfaces. Traditional architectures often allow I/O concerns—such as SQL queries or framework-specific logic—to bleed into the business core. When these external technologies become obsolete or unavailable, the business logic is held hostage by the technical debt.
Alistair characterizes the application as a “component in a component library” that should know nothing about the outside world. By isolating the logic, teams can protect their code from the instability of external dependencies, such as an unavailable database or a required technology upgrade.
Ports, Adapters, and the “Inside-Outside” Divide
The architecture is structured around two primary concepts that define the boundary of the application core:
- Ports: These are interfaces defined by the core that specify what the application needs to interact with the world.
- Adapters: These are implementation-specific wrappers that translate between the port’s interface and external technologies (e.g., a REST API or a PostgreSQL database).
This separation distinguishes between Driving Adapters (primary actors that initiate actions in the core, like a CLI or GUI) and Driven Adapters (secondary actors that the core uses, like a database or external service). This distinction creates a “test moat” that allows the application to be run in isolation using mock adapters, enabling 100% automated regression testing without live external systems.
Implementation Strategy and Sequence
Effective implementation of Ports and Adapters requires a disciplined folder structure that explicitly separates the “Inside” (Domain/Core) from the “Outside” (Adapters). This allows for a “development sequence” where the business logic is written and fully tested first, using in-memory mock adapters. Only after the core logic is verified are the actual production adapters—such as the database implementation or the web front-end—developed. This approach ensures that the most valuable part of the software remains flexible and resistant to technology leakage over time.