On May 18 and 19, Michael Tabolsky, Marco Gatti, Federico Vidali, and I, members of Bitrock’s DevOps and Engineering team, traveled to Bologna for the fifth edition of Cloud Native Days Italy, a community-driven event dedicated to cloud native and open source technologies.
The event was born from the passion of the Italian tech community and brings together developers, early adopters, and enthusiasts to connect, learn, and grow together. Now in its fifth edition, it has become a key reference point where professionals from different backgrounds and experience levels meet, share insights, and help shape the direction of cloud native in Italy. It was two intense days, marked by parallel talks and the constant challenge of choosing which session to prioritize.
Below is a summary of the ones that stood out to us most.
Agentic AI: From Experiment to Platform Component
The theme running through most of the first day’s sessions was agentic AI in practice: how to bring into production a system that reasons, plans, and acts on real infrastructure.
William Rizzo‘s talk, Agentic AI in Platforms: Verticalizing Intelligence for Regulated Domains, addressed exactly this. The central thesis was that emerging patterns from OpenAI, Google, Microsoft, and FINOS are converging toward multi-agent systems orchestrated on shared, governed context — not isolated sub-agents. The most relevant part for our work was verticalization. The session discussed how these primitives (agent runtime, context layer, tool gateway, policy and evaluation pipelines) can be assembled into agent-specific platforms for domains such as fintech, healthcare, and telco. The concept of “context engineering as a first-class element in platform engineering” was the session’s most original contribution — a precise formulation of something many were already beginning to sense.
Mauricio Salatino approached the question from a complementary angle in his talk From Cloud Native to Agentic Applications: Workflows & Observability. The starting point was clear: distributed cloud native applications are already complex to observe, and agentic applications introduce new protocols and architectural patterns that the community has not yet consolidated. Salatino showed how Dapr Workflows and OpenTelemetry can support the building of observable, resilient agentic systems. Particularly useful was the focus on the new protocols currently being introduced: having a reference framework while the industry is still evolving is a concrete advantage.
The CERN Keynote: Open Source as Organizational Practice
Among the second day’s keynotes, Giacomo Tenaglia‘s Open Source at CERN — on the organization’s experience with open source — generated more discussion than almost any other session. CERN, the world’s largest physics laboratory and home to the Large Hadron Collider, has established a dedicated Open Source Program Office. Tenaglia walked through the path that led to its creation: not a top-down decision, but a structured response to a real problem — making contributions to and use of open source at CERN consistent, sustainable, and aligned with best practices.
The most interesting aspect wasn’t the institutional narrative itself, but the operational dimension: how do you govern open source in an organization with thousands of researchers, heterogeneous projects, and critical infrastructure? CERN is historically considered the birthplace of the World Wide Web — their relationship with open source runs deep. The talk addressed current and emerging challenges without glossing over unresolved issues, which made the session particularly substantive.
Argo Rollouts and Agentic AI: Self-Correcting Production Releases
Kevin Dubois presented a directly relevant use case for anyone managing deployments on critical systems. The talk, Fix Production Rollouts on the Fly with Agentic AIOps, started from a solid premise: Argo Rollouts is already an effective tool for progressive delivery and automatic rollback. The proposal was to take this logic a step further by integrating agentic AI agents into the release cycle.
The concrete mechanism: when a rollout fails, rather than halting the process and waiting for manual intervention, the system delegates to a model the analysis of logs, identification of root causes, and subsequent action — modifying code or deploy manifests, opening a PR, sending notifications. The live demo showed a working flow. The current limitations — agent latency, reliability of automated actions on critical systems — were stated explicitly, a transparency that is far from guaranteed in presentations on similar topics.
High Availability Is Not Enough: The Failure Modes Managed Services Don’t Cover
Enrico La Sala‘s talk, High Availability is Not Enough: Surviving Failure in Cloud-Native Architectures, was the most technically dense session and probably the one with the most immediate implications for those operating distributed systems in production. The premise was uncomfortable but true: cloud native environments promise high availability, yet large-scale systems continue to fail in ways that standard patterns don’t prevent — cascading retries, latency spikes in dependencies, partial outages that only surface under real load.
La Sala illustrated concrete failure scenarios drawn from real incidents, and analyzed how patterns such as circuit breaker, bulkhead, and graceful degradation behave under stress. The throughline was the role of observability in containing incidents before they propagate. The value of the session lay in the concreteness of the trade-offs discussed and the anti-patterns identified — not universal solutions, but decisions that have produced measurable differences in production.
One Repository to Rule Them All: Sveltos and GitOps on Heterogeneous Clusters
The final session worth highlighting is the one by Stefano Sibilla and Gianluca Mardente, One Repo to Rule Them All: Managing Heterogeneous Clusters with Sveltos and GitOps. Anyone who has managed Kubernetes infrastructure spread across multiple cloud providers knows the complexity of the problem: how do you distribute cert-manager, Kyverno, and Ingress controllers across every cluster while handling different configurations for AWS NLB and GCP static IPs? How do you restrict the deployment of specific services — such as LiteLLM — to certain environments?
The solution presented adopted a two-level hub-and-spoke approach, with Sveltos as the distribution engine and ArgoCD as the delivery layer for CRDs. The label-based opt-in model for target cluster selection and configuration layering were the most architecturally significant elements. This was an approach already in use in production, not a simple proof of concept — and the concreteness of the technical details confirmed it.
Conclusion
We came back with a list of technologies to explore further and more questions than we brought with us — which is probably the best sign that it was worth attending. You don’t leave these events with ready-made certainties, but with a clearer picture of where the industry is heading, which problems the community is actively working on, and which ones remain unresolved.
For Bitrock’s DevOps team, this kind of hands-on update is essential: making direct contact with people facing the same challenges in real production environments — and seeing up close how the community is solving them — is one of the most effective ways to maintain and grow our expertise over time.
Author: Matteo Gazzetta, DevOps Manager @ Bitrock