cotalks.dev

The Room of Requirements for Developers: Scaling AI Magic with Internal Portals - Maarten Vandeperre

(link)
Channel: Devoxx

Summary

This talk connects platform engineering and internal developer portals to the challenges of building and operating AI applications at scale. It explains why shifting too many responsibilities left increases developer cognitive load, then shows how a platform team can standardize and automate common capabilities while keeping developers focused on code. Using Backstage, GitOps, Argo CD, and Red Hat’s Janus/developer hub concepts, the speaker demonstrates how an internal portal can centralize services, documentation, APIs, CI/CD status, dependencies, and deployment views. The talk also covers trusted software supply chain practices such as artifact signing, SBOMs, and security scanning, and ties these ideas to digital sovereignty and control over models, data, and infrastructure. The core message is that an internal portal plus a well-designed platform can act like the “Room of Requirements”: a self-service environment that adapts to developer, data scientist, and ops needs without exposing low-level complexity.

Key Takeaways

  • Platform engineering reduces developer cognitive load by centralizing common capabilities such as CI/CD, observability, deployment, and documentation.
  • Internal developer portals like Backstage provide a single pane of glass for services, APIs, documentation, issues, dependencies, and deployment status.
  • GitOps and Argo CD make portal and platform configuration auditable, version-controlled, and easier to sync across Kubernetes environments.
  • Trusted software supply chain practices—image signing, SBOMs, vulnerability scanning, and commit signing—help prevent dependency and container injection risks.
  • Sovereign AI is about keeping control over models, data, inference environments, and infrastructure, not just about running on-premises.
  • Blueprints and software templates should hide complexity behind abstraction layers, so developers can request outcomes without managing low-level infrastructure details.

Sections

Why platform engineering matters for AI and cloud-native teams

The talk starts from the problem of increasing responsibility on developers after the move to cloud-native and DevOps. Teams are expected to handle not just code, but also infrastructure, security, operations, MLOps, and FinOps. That expands cognitive load and creates friction. Platform engineering is presented as a response: create a reusable platform that packages common capabilities and lets teams work through simpler interfaces.

Building a platform recipe with the right stakeholders

A platform begins with a capability list or recipe: what developers, data scientists, and operators actually need in day-to-day work. The speaker stresses that this should not be designed in an ivory tower. Communities of practice, technical leads, security, and platform engineers all need input so the platform matches real workflows. The platform should also be delivered iteratively, not as a large all-at-once project.

Internal developer portals as the single entry point

The portal sits on top of the platform and removes the bookmark hell created by many repositories, pipelines, docs sites, and tools. It becomes the single pane of glass for software teams. The talk uses Backstage as the reference framework and explains how Red Hat’s Janus/developer hub approach introduced dynamic plugins and Kubernetes/YAML-based configuration, reducing the need to modify Backstage React code directly.

GitOps, blueprints, and self-service scaffolding

The demo shows how GitOps and Argo CD can drive portal configuration and application deployment from version-controlled definitions. A blueprint or scaffolding template is used to create a new AI chatbot application with a self-hosted model, generating source and GitOps repositories, deployment configuration, and standard organization defaults. This gives teams self-service while preserving auditability and repeatability.

Portal features beyond deployment status

The portal aggregates more than deployment views. It can show topology, CI/CD status, issues, pull requests, APIs, dependencies, and technical documentation. The talk highlights how this centralization helps developers avoid context switching and reduces delays when waiting for reviews, looking up APIs from other teams, or finding documentation scattered across tools such as Confluence or PDFs.

Trusted software supply chain for secure AI delivery

The CI pipeline is extended into a trusted software supply chain. It includes code scanning, unit and integration tests, image signing, SBOM generation, vulnerability scanning, and runtime policy enforcement. The speaker emphasizes risks from untrusted container images and dependency injection, especially in AI-era workflows where code may be generated automatically. Signed artifacts and validated dependencies are presented as essential safeguards.

Digital sovereignty and keeping options open

The sovereignty discussion focuses on control over data, models, and inference environments rather than simply on-prem deployment. The speaker frames sovereignty as avoiding lock-in and keeping options open across vendors and technologies. The talk links this to AI deployments where model upgrades, cloud limits, or external platform rules can affect behavior and cost. The recommendation is to design architectures that preserve control and portability.

The Room of Requirements analogy

The final analogy ties the ideas together: a room that changes based on what the user needs is compared to a portal plus platform combination. The portal provides the self-service entry point, and the platform provides the abstractions and automation underneath. Together they let teams request outcomes—such as a chatbot, database, or environment—without managing the full complexity of Kubernetes, MLOps, or infrastructure setup.

Keywords: platform engineering, internal developer portal, backstage, gitops, argo cd, kubernetes, openshift, developer portal, trusted software supply chain, sbom, image signing, commit signing, vulnerability scanning, software templates, scaffolding templates, software blueprints, self-service platform, cognitive load, digital sovereignty, sovereign ai, mlops, ci/cd, observability, api catalog, documentation portal

note