The Cloud Native AI Summit is landing in Melbourne (Oct.28-29) and Paris (Dec.2-3) and we are excited to announce that our Call For Papers open and is running until August 14th!

As a technical independent conférence, we will ask one big question: how do we build the Cloud Native foundations to power the AI Era?

Our editorial Manifesto will be serve as a readmap.

We’ll follow a strong focus on large-scale corporations, multinational organizations and industry leaders to address technical depth,  share cutting-edge innovations and real use cases.

Our Editorial Manifesto has been crafted for Practitioners and scope the whole discussion.

To ensure every session meets the highest technical standards, our agenda is strictly vendor-neutral and carefully curated by Chris Mazur, AAIF & CNCF Ambassador and original founder of the Cloud Native Summit, and Mehdi Medjaoui, Apidays CEO.

To explore this, we are looking for talks across our three core tracks:

Our audience is made of Platform or Infrastructure Engineer, DevOps/SRE, Network or Software Architect, AI & Application Developer, Security Professional, mostly senior working in large-scale organizations.

So, if you are working on the convergence of cloud-native foundations and the AI imperative, we want you on board!

Critical dates to keep in mind:

Looking forward to hearing from you!

Community Spotlight

Gareth Faull heads the shared API platform at the London Stock Exchange Group, where he works as a platform product manager. Before LSEG, he was one of the first product hires at Modulr, a B2B payments fintech, where he took on developer experience for its APIs. That is also where he learned that versioning an API is not like versioning software, and that the goal is to avoid versioning at all where possible, given the impact on customers.

A central theme in his thinking is that APIs are moving from a technical integration concern to a business product. He has been making this point for years and thinks much of the shift has yet to happen. AI may push it along, mainly by giving business people the confidence and the means to build. In that model, the platform moves beyond controlling an API gateway and becomes the main interface for managing the full API lifecycle. The more important shift, in his view, is the ability of non-engineers to create and manage APIs without relying on a development team.

He is also direct about how AI fits within a large, regulated enterprise. Firms that were cautious about AI, often for good reason, are now working to catch up, and enterprise agreements with providers such as OpenAI and Anthropic have made it possible to use these tools within work contexts. On governance, his view is that AI should go through the same processes as any other technology and, in some respects, needs more scrutiny, particularly regarding what data is sent to where. He would rather organizations keep their context in-house and treat the models as a tool.

One practical gap he keeps returning to is deployment. It is easy to build something and hard to connect it to anything, because launching into a real environment means clearing architectural approvals that deter most non-engineers. His proposed answer is what he calls "sandcastles": a way to roll an app into an environment that already holds the necessary permissions, run it temporarily, and let it wash away once the work is done.

Faull has also flagged the European push for sovereign cloud as a shift few people have fully registered. A SaaS provider domiciled in the United States, he argues, will need a genuinely separate European entity that stores everything in Europe, not a US parent with a subsidiary attached. For API providers, that points toward infrastructure that is far more explicit about where a gateway physically sits, and toward European consumers getting a distinctly European instance of a service, even if the change is invisible at the point of use.

Tarun Kalwani is a Principal Engineer at Verizon with more than 19 years of experience working on enterprise systems across telecom, airline, and financial services industries. His work has focused on modernizing systems that cannot simply be switched off and replaced. Projects attributed to him include Verizon’s Prepay NSA and Bill Pay Kiosk modernization programs, as well as the migration of a Delta Air Lines load-and-balance application to AWS Lambda. The common constraint is changing infrastructure that remains responsible for live, business-critical transactions throughout the migration.

A recurring theme in his work is consolidating systems built separately for different brands, products, or operating teams. Large enterprises often accumulate overlapping applications, each with its own data models, release processes, and licensing costs. Moving these systems into shared services can reduce duplication, but only when the new architecture is organized around stable business capabilities. Splitting a monolith into smaller components without resolving their dependencies can leave an organization with the same coupling spread across more systems.

That makes service boundaries one of the most consequential decisions in a modernization program. A service built around a temporary organizational structure or a narrow section of code may become obsolete as teams and products change. A service built around a durable function such as payments, customer identity, provisioning, or account management is more likely to remain useful. It also gives other applications a stable interface even when the underlying databases, vendors, or processing systems are replaced.

Kalwani’s portfolio shows substantial operating improvements. Platform consolidation and reduced dependence on licensed software lowered annual operating costs by approximately $9 million, real-time processing changes reduced transaction latency by around 25%, and modernized transaction flows increased success rates from 88% to 98%. These figures show the business outcomes his modernization work is intended to produce: lower operating costs, faster transactions, and fewer failed customer interactions.

The operational challenge is not limited to writing new services. Teams must often run old and new systems in parallel, reconcile differences between them, migrate data gradually, and create rollback paths for failures. They also have to prevent every downstream application from building its own interpretation of the same customer, payment, or transaction data. Without that discipline, the new environment can reproduce the inconsistency and maintenance burden of the system it was meant to replace.

His work also extends into research and peer review. Kalwani has published a comparative study of approaches to migrating from monolithic systems to microservices. The study evaluates strategies including Big Bang migration, the Strangler Fig pattern, and Parallel Run using a synthetic dataset of migration scenarios.

The broader lesson from his work is that modernization is about managing dependencies. Legacy systems remain difficult to change because business rules, customer journeys, vendor contracts, and operational processes have accumulated around them over many years. The value of a stronger architecture lies in reducing those dependencies gradually while keeping the underlying service available. At telecom scale, where a small failure can affect large transaction volumes, the quality of the migration is measured not only by the architecture that emerges but by how little customers notice while it is being built.

API Feed

Big Story

For much of software history, building an API was only part of the challenge. Making it discoverable was equally important. An interface that could not be found, understood, or trusted was unlikely to be reused, regardless of how well it had been designed. Over the past three decades, API discovery has evolved through several distinct generations, each reflecting the way software systems communicated at the time. The progression from UDDI registries to developer portals, OpenAPI specifications, and now Model Context Protocol (MCP) illustrates how the industry has repeatedly adapted discovery mechanisms to meet new patterns of consumption.

The first generation emerged in the late 1990s with Universal Description, Discovery, and Integration (UDDI). The ambition was to create a centralized directory where organizations could publish and locate web services. Built alongside SOAP-based architectures, UDDI attempted to bring the structure of a business registry to distributed software. In practice, however, adoption remained limited. Maintaining centralized registries proved difficult, service descriptions became outdated, and most enterprises continued to rely on internal documentation and direct collaboration between teams.

The rise of REST APIs fundamentally changed the problem. Instead of centralized registries, organizations published APIs through developer portals, documentation websites, SDKs, and API marketplaces. As APIs proliferated across enterprises, the emphasis shifted toward clear documentation, consistent naming, searchable catalogs, and reusable standards that allowed developers to integrate services more efficiently.

That shift is reflected in industry adoption data. According to the 2025 State of the API Report, 82% of organizations have adopted some level of an API-first approach, while 25% now describe themselves as fully API-first, a 12% increase over the previous year. At the same time, 89% of developers report using AI, yet only 24% are actively designing APIs for AI agents. The numbers indicate that organizations have embraced APIs as products, but many have not yet adapted them for machine-driven discovery and consumption.

OpenAPI specifications helped close part of that gap. Rather than describing APIs primarily for humans, OpenAPI introduced a structured, machine-readable contract that development tools could validate, document, test, and generate automatically. API discovery became metadata-driven. Catalogs could be searched programmatically. Documentation could be generated automatically. Governance tools could validate consistency before APIs reached production.

The emergence of large language models introduces another transition. AI agents do not browse documentation in the way human developers do. They depend on structured descriptions of capabilities, parameters, authentication requirements, and expected behavior. This is where the Model Context Protocol (MCP) represents an important evolution. MCP provides a standardized way for AI systems to discover available tools, understand their capabilities, and invoke them without relying on custom integrations for every application.

Every generation has addressed the same underlying question: how do systems discover and trust one another? UDDI relied on centralized registries. REST emphasized human-readable documentation. OpenAPI standardized machine-readable contracts. MCP extends that principle by enabling AI agents to discover and use APIs via structured interfaces designed for autonomous execution. API discovery has never been static. Each architectural shift has changed how software systems locate and interact with capabilities across organizations. The next phase is making them more discoverable, interpretable, and governable for both human developers and autonomous systems.

Resources & Events

apidays Munich brings together API architects, platform engineers, and enterprise technology leaders for two days focused on API strategy, platform operations, and AI-driven enterprise systems. The 2026 program includes sessions on API lifecycle management, developer experience, event-driven architectures, and the operational challenges of managing APIs across distributed environments. Designed for teams scaling enterprise API programs, the event combines technical discussions, practitioner-led case studies, and platform engineering perspectives on how APIs are evolving alongside automation and AI-connected workflows. Details →

apidays India brings together API architects, platform engineers, developers, and enterprise technology leaders for two days focused on the next generation of API-driven systems. The 2026 program explores how APIs are evolving to support AI agents, autonomous workflows, and machine-driven ecosystems, alongside sessions on API monetization, security, governance, platform strategy, and AI-driven automation. Designed for teams building and operating modern digital platforms, the event combines technical deep dives, practitioner-led case studies, and real-world discussions on how APIs are being designed, secured, and managed in an AI-connected world. Details →

You can find a list of all Apidays events here

Apply to speak at Apidays Singapore, NY, London, Paris, and more here

API Platform Conference brings together developers, maintainers, software architects, and engineering teams working with API Platform and the wider PHP and Symfony ecosystem. The two-day program features talks in both French and English covering API development, framework architecture, performance, security, tooling, and practical implementation lessons from teams using API Platform in production. For developers and platform teams, the conference offers a focused view of how the framework is evolving and how organizations build and operate modern API-based applications. Details →

This paper proposes a security-first framework that embeds Zero Trust principles throughout the API delivery lifecycle. It outlines a five-pillar approach that covers governance and planning, secure API design, continuous testing, pipeline controls, and runtime protection and is aligned with industry guidance such as the OWASP API Security Top 10 and the NIST Secure Software Development Framework. The researchers argue that treating security as a continuous engineering discipline can significantly reduce vulnerabilities before production, reinforcing the idea that API security depends as much on development processes as on runtime defenses. Read →

Insight of the Week

API governance has traditionally focused on two stages: design time, where teams define standards and review specifications, and runtime, where gateways enforce authentication, security, and traffic policies. Kin Lane argues that AI agents introduce a third layer, the consumer. As autonomous systems discover, combine, and invoke APIs independently, governance can no longer stop at the provider. It must also shape how APIs are exposed, consumed, and constrained for machine-driven interactions. The implication is that API governance is evolving beyond publishing well-designed interfaces to governing the context in which AI agents consume them.

For the Commute

In this session, Erik Wilde explores how AI is reshaping the role of API descriptions. He argues that OpenAPI remains the foundation for describing endpoints, schemas, authentication, and operations, but AI agents require richer context to consume APIs effectively. Beyond technical specifications, they need to understand an API's intent, typical workflows, business semantics, and the relationships between operations. Wilde highlights emerging standards such as Arazzo and OpenAPI Overlays, which extend existing specifications to better support AI-driven consumption while maintaining interoperability.

Stay tuned for bold ideas, fresh perspectives, and the next wave of API innovation

-The Apidays Team