© Mapbox, © OpenStreetMap
Carles Arnal

Carles Arnal

Principal Software Engineer at IBM

Barcelona, Spain

Actions

Carles Arnal is a core maintainer of Apicurio Registry (CNCF sandbox). A Principal Software Engineer at IBM, he contributes to Quarkus, Apache Kafka, Strimzi, Debezium, and other open source projects. Carles is also an associate professor at BarcelonaTech (UPC) and speaks regularly at international conferences on event-driven architectures, real-time data pipelines, and AI-ready platforms.

Area of Expertise

  • Information & Communications Technology

Topics

  • java
  • Programming
  • Software Engineering
  • Software Craftsmanship

Agent Sprawl Is the New Microservice Sprawl: Discovery and Governance for Multi-Agent AI

Five teams. Twenty agents. Three frameworks. No one knows which agents talk to which — or what happens when one team's "minor update" silently breaks four downstream consumers. If this sounds familiar, it should: it's the same discovery and compatibility crisis that hit APIs a decade ago. The difference is that agents evolve faster, fail more silently, and have no contract layer by default.

In this session, I'll show how to apply proven registry-based governance patterns to AI agents using the A2A (Agent-to-Agent) Protocol. In a live demo, you'll see agents publishing discoverable Agent Cards to a central registry, negotiating capabilities at runtime, and failing fast when a breaking change is detected — all before reaching production. The demo uses Apicurio Registry (CNCF sandbox) as the governance backbone, but the patterns apply to any registry infrastructure.

Attendees will walk away with:
- A governance architecture for agent discovery, versioning, and deprecation using A2A Agent Cards
- Concrete patterns for enforcing compatibility rules across independently evolving agents
- A clear comparison of where A2A, MCP, and traditional API governance overlap and diverge

Your Prompts Are Unversioned: Applying Schema Governance to LLM Templates

You version your code. You version your schemas. But your prompt templates live in environment variables, config files, or hardcoded strings — unversioned, ungoverned, and one edit away from breaking your AI application in ways that no test suite catches.

In this session, I'll show how to treat prompt templates as first-class versioned artifacts with compatibility rules — the same governance you already apply to Avro schemas or OpenAPI definitions. Using a live demo of a RAG-powered support chatbot built with LangChain4j and Ollama, I'll walk through what happens when a prompt template change silently degrades downstream behavior, and how registry-enforced validation catches it before production. The demo uses a schema registry as the governance layer, but the patterns work with any artifact store that supports versioning and compatibility checks.

Attendees will leave with:
- A reusable pattern for version-controlling prompt templates with compatibility enforcement
- A working example of a Quarkus + LangChain4j chatbot consuming governed prompts at runtime
- A clear framework for deciding when prompt governance pays off and when it's overkill

When Twenty Agents Talk to Nobody: Contracts, Discovery, and Lifecycle for AI That Scales

Last year your organization shipped one AI agent. This year there are twenty, built by five teams, using three frameworks — and nobody knows which agents depend on which. An "innocent" capability change in one agent cascades into silent failures across four others. This is microservice governance all over again, except agents evolve faster and fail more quietly.

This talk presents a practical governance model for multi-agent AI, built on the same contract-driven patterns that tamed API and schema sprawl. In a live demo, I'll walk through the full lifecycle: agents registering discoverable capability cards via the A2A Protocol, enforcing communication contracts with compatibility rules, and deprecating agent versions without breaking consumers. I'll also show how the Model Context Protocol (MCP) fits alongside A2A — standardizing tool integration where A2A handles agent-to-agent discovery.

Attendees will leave with:
- A working governance model for multi-agent AI: registration, discovery, versioning, and deprecation
- A clear mental model for when to use A2A vs. MCP — and how they compose
- Patterns for preventing cascading failures when agents evolve independently across teams

One Identity Provider, Zero Trust Gaps: Securing Kafka Data Platforms End-to-End

Your Kafka cluster uses one auth mechanism. Your schema registry uses another. Your applications use a third. Each component is "secured" — but the gaps between them are where breaches happen. Attackers don't break your Kafka ACLs; they exploit the credential handoff between Kafka and everything around it.

In this session, I'll show how to collapse three auth mechanisms into one by wiring Keycloak as the single identity provider across a Kafka data platform on Kubernetes. You'll see OAuth2/OIDC replace fragmented credentials, mutual TLS enforce identity across every connection — broker, schema registry, consuming applications — and fine-grained authorization control who can produce, consume, and evolve schemas. The demo runs on Strimzi and Apicurio Registry (CNCF sandbox), but the zero-trust pattern applies to any Kafka deployment with pluggable auth.

Attendees will walk away with:
- A deployable reference architecture for securing Kafka pipelines with centralized identity on Kubernetes
- The specific configuration pitfalls that cause "it works in dev, fails in prod" security setups
- A checklist for moving a data platform from open prototype to audit-ready without slowing down developer workflows

Bad Messages Should Never Reach the Broker: Schema Validation at the Kafka Proxy Layer

Schema validation usually happens at the producer client — but what about legacy producers you can't modify, third-party integrations, or teams that simply skip validation? Those schema-invalid messages still reach Kafka, and by the time a consumer fails on bad data, the damage is done and the offset has moved.

In this session, I'll demo a different approach: enforcing schema validation transparently at the proxy layer using Kroxylicious. A proxy filter intercepts produce requests, validates payloads against a schema registry, and rejects non-compliant messages before they ever reach the broker — with zero changes to producer code. I'll show the setup end to end: deploying the proxy alongside a Kafka cluster on Kubernetes, configuring validation rules, and watching bad messages get rejected in real time.

Attendees will leave with:
- An understanding of Kafka proxy-layer architecture and how Kroxylicious filters work
- A deployable schema validation filter configuration for their own clusters
- A clear decision framework for when proxy-layer validation complements or replaces client-side checks

So You Want to Join the CNCF: A Maintainer's Honest Guide to the Sandbox Process

Getting accepted into the CNCF Sandbox is a milestone — but nobody tells you about the months of governance restructuring, community alignment, and uncomfortable technical decisions that precede it. This talk pulls back the curtain on what the journey actually looks like from a maintainer who went through it.

I'll walk through the concrete steps, the surprises, and the mistakes: aligning project governance with foundation expectations, adapting a contribution model that had worked fine for years, navigating due diligence questions we weren't prepared for, and the technical changes required to meet cloud-native standards. I'll also cover what changed after acceptance — more contributors, more visibility, and more responsibility than we expected.

Attendees will leave with:
- A realistic, step-by-step roadmap for submitting an open-source project to the CNCF Sandbox
- The governance, licensing, and community structure decisions that foundations actually evaluate
- An honest assessment of the benefits and new obligations — so you can decide if it's worth it for your project

Why Your AI Pipeline Broke at 3 AM: Data Contracts for Event-Driven Machine Learning

45% of enterprise AI projects fail because of data quality issues — not model accuracy. The root cause is deceptively simple: producers and consumers in streaming AI pipelines evolve independently, and without formal contracts, a silent schema change in one team's Kafka producer becomes a 3 AM page for another team's inference service.

This talk shows how to apply data contracts to event-driven AI architectures — the same discipline that API contracts brought to microservices, now enforced at the streaming layer. In a live demo with Debezium CDC, Kafka, and a downstream ML inference service, I'll walk through how schema compatibility rules catch breaking changes at produce time, not at prediction time. You'll see a schema evolution that would silently corrupt model inputs get rejected before it ever reaches the broker.

Attendees will leave with:
- A concrete pattern for implementing data contracts in streaming AI architectures
- A comparison of schema evolution strategies (Avro, Protobuf, JSON Schema) and when each fits ML workloads
- A reproducible setup they can deploy to enforce schema governance across their own pipelines

Kill the Nightly Batch: Building a Real-Time Lakehouse with CDC, Kafka, and Apache Iceberg

Batch ETL runs nightly. Your analysts query stale data. Your ML models train on yesterday's features. The streaming-first lakehouse replaces all of that with a single, real-time pipeline — and you can build it entirely with open-source tools on Kubernetes.

In a live demo, I'll build a complete pipeline end to end: Debezium captures row-level changes from PostgreSQL, streams them through Kafka with schema enforcement, and lands them in Apache Iceberg tables — queryable within seconds via Trino or Spark. I'll show how the Flink Dynamic Iceberg Sink handles automatic schema evolution, eliminating the manual DDL changes that plague traditional data lakes. You'll also see what happens when an upstream schema change propagates through the entire pipeline — and how compatibility rules prevent it from corrupting your lakehouse.

Attendees will leave with:
- A deployable CDC-to-Iceberg pipeline architecture using only open-source components on Kubernetes
- Practical patterns for handling schema evolution across the Kafka-to-Iceberg boundary
- A clear framework for when streaming lakehouse replaces batch ETL and where hybrid patterns still win

Carles Arnal

Principal Software Engineer at IBM

Barcelona, Spain

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top