Exploring the Future of Cloud Native Platforms
Most platform teams we talk to aren’t stuck on tooling anymore. They have Kubernetes, they have CI/CD, they have a developer portal someone stood up two quarters ago. What they’re actually wrestling with is scale, complexity, and a steady climb in what developers expect the platform to do for them.
AI is now part of that expectation. The temptation is to bolt a model onto the existing platform and call it “AI-native.” In practice, that usually creates more problems than it solves, weaker governance, fuzzier trust boundaries, and automation nobody fully controls. Going AI-native is an architectural decision, not a feature you sprinkle on top.
That’s the gap a new hands-on cohort, Building AI-Native Platform Engineering Systems, sets out to close. Run by Packt in collaboration with FAUN.dev(), it’s aimed at teams who already operate cloud-native platforms and now need to evolve them deliberately without throwing away the operational discipline they’ve built up.
The Questions Every Platform Team Is Now Asking
If you run an internal platform, some version of these questions has probably already landed on your desk:
- How do we introduce AI into internal platforms without weakening governance?
- How do we give teams more autonomy without losing operational control?
- What does an AI-native platform actually look like in practice, beyond the slideware?
- How do developer portals, golden paths, telemetry, and AI agents fit together as one system?
- How do we design self-service experiences that are genuinely usable and secure?
- How do we make this transition without piling on unnecessary risk?
These are hard precisely because they sit at the intersection of architecture, developer experience, and security – three things that are usually owned by different people.
What the Cohort Covers
Rather than staying abstract, the sessions work through the concrete building blocks of an AI-native platform:
- AI-native architecture and platform design – the structural shifts that separate a cloud-native platform from an AI-native one
- Backstage developer portals and self-service platforms — the front door developers actually interact with
- OpenChoreo application delivery workflows — modeling how applications move from commit to production
- CI/CD automation, orchestration, and golden paths — paved roads that keep delivery fast and consistent
- Policy-as-code, governance, and guardrails — control that’s enforced by the platform rather than by documentation
- Telemetry, observability, and platform intelligence — the data and feedback layer that makes “intelligent” platforms possible
A recurring theme is the platform intelligence layer: the data, inference, telemetry, and control pathways that an AI-enabled platform needs in order to be useful without becoming unpredictable.
A Practical Look at Security and Governance
The part I find most valuable is that security isn’t treated as an afterthought. The cohort spends real time on secure-by-default AI platforms, guardrails, trust boundaries, and the actual failure modes captured in the OWASP LLM Top 10. That means thinking seriously about misuse, jailbreaks, and unsafe automation before you hand an agent the keys to your delivery pipeline.
This is the right instinct. The fastest way to lose trust in an internal platform is to ship automation that does something nobody intended. Designing the trust boundaries up front is far cheaper than retrofitting them after an incident.
Who It’s For
The material is pitched at people building scalable, secure, self-service platforms:
- Platform and Cloud Engineers
- DevOps Engineers and SREs
- Architects and Tech Leads
- Engineering Leaders setting platform direction
If you’re earlier in your journey and still standing up your first cloud-native platform, some of this will run ahead of where you are — but it’s a useful map of where things are heading.
What You Walk Away With
By the end, the goal is for attendees to leave with:
- A clear picture of how platform engineering is evolving into AI-native systems, and what that changes for architecture and teams
- The ability to design AI-enabled platform architectures across data, telemetry, and control layers
- Hands-on exposure to modern tools and patterns ~ internal developer portals, OpenChoreo, Crossplane and how they compose
- Practical experience using LLMs in DevOps and platform workflows, including CLI-driven automation
- A working approach to self-service platforms and golden paths that improve developer experience without giving up control
- A real understanding of guardrails, trust boundaries, and the risks in the OWASP LLM Top 10
- Strategies for governance and policy that prevent misuse and unsafe automation
- A framework for defining your own AI-native roadmap and tying it back to developer productivity and business outcomes
The Lineup
The cohort brings together a strong set of voices in platform engineering and architecture: Asanka Abeysinghe, Dr. Gautham Pallapa, Mark Peter, and Thiago Shimada Ramos.
Event Details
- Format: Online, roughly five hours, hands-on
- Date/time as listed: Saturday, May 30 – 9:30 AM–2:29 PM EDT (1:30 PM–6:29 PM UTC)
- Organizer: Packt Publishing, in collaboration with FAUN.dev()
- Bonus: A free e-book of Platform Engineering for Architects — a practical guide to designing internal developer platforms and self-service cloud-native systems
- Registration: Building AI-Native Platform Engineering Systems on Eventbrite
Final Thought
The move from cloud-native to AI-native isn’t really about adding intelligence to your platform. It’s about deciding, deliberately, where intelligence belongs, what it’s allowed to touch, and how you’d know if it went wrong. Teams that treat that as an architecture problem, not a feature request, are the ones who’ll come out of this transition with platforms they can still trust.
Interested in the AI-native platform space? This is a solid place to pressure-test your own thinking against people building these systems in the open.
