How Millennium Bcp Leverages Radius To Empower Developer + Operator... Nuno Guedes & Jonathan Smith

How Millennium Bcp Leverages Radius To Empower Developer + Operator Collaboration

Speakers: Nuno Guedes, Head of Public Cloud, Millennium BCP; Jonathan Smith, Head of Product Management, Azure Open Source Incubations team, Microsoft

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=ZmcZlDCYDgE

Overview

This talk, presented by Nuno Guedes from Millennium BCP and Jonathan Smith from Microsoft, introduces Radius, an open-source, cloud-agnostic cloud-native application platform designed to bridge the gap between application development and infrastructure provisioning within modern internal developer platforms (IDPs). The core premise is that while many robust open-source tools exist for infrastructure as code, continuous delivery, and compliance, there has been a significant missing piece: a unified, first-class application model that allows developers to reason about and interact with their applications as a cohesive entity, rather than a collection of disparate infrastructure components.

The speakers argue that this lack of a clear application model contributes significantly to the cognitive load on developers in complex distributed systems environments. Radius aims to alleviate this by providing a declarative way to define applications once and deploy them consistently across various environments, including on-premise, AWS, and Azure. Millennium BCP's real-world adoption of Radius showcases its practical benefits, demonstrating how it empowers developers to focus on business logic while enabling operators to maintain control and ensure compliance through standardized infrastructure definitions.

The talk highlights how Radius facilitates improved collaboration between developer and operations teams. Developers benefit from a self-service experience and reduced infrastructure concerns, while operators can define infrastructure recipes that codify best practices and security policies. By integrating Radius into their IDP, Millennium BCP has been able to accelerate service delivery, standardize deployments, and achieve their ambitious goal of reducing deployment times from days to minutes, underscoring Radius's critical role in modern cloud-native development workflows.

Background

▶ Watch: Introduction to Radius and the application model gap (0:00)

The journey towards modernizing software delivery at Millennium BCP began in 2021 with an ambitious program titled "from 8 days to 8 minutes." The objective was to drastically reduce the time from build to deployment for a microservice across all environments, aiming for a maximum of eight minutes. This initiative was driven by the critical need to accelerate service delivery and eliminate the common bottleneck where developers waited for operators to provision specific infrastructure resources for their applications. Despite this, the program recognized the necessity to respect the distinct life cycles of application development and infrastructure management.

Millennium BCP, as a regulated industry company, faced comprehensive IT life cycle requirements, including application registration in the CMDB and stringent compliance. While they had established robust practices for infrastructure as code, leveraging an extensive library of Terraform modules and various toolsets for continuous compliance and drift reconciliation, a crucial element was missing: a first-class API for the application itself. Developers needed a way to define their applications and their infrastructure dependencies in a structured, versionable manner, akin to how software development handles code.

Initially, Millennium BCP built a system where developers used a web UI to select application templates, define business domains, topologies, technologies, and dependencies (e.g., caches, databases, messaging). This information was captured in a JSON file stored in the application's code repository. This JSON file detailed application specifics, operations, SLOs, messaging schemas, roles, and persistency requirements. A part of this JSON definition was then converted into an Open Application Model (OAM) definition and integrated into their GitOps workflows, utilizing tools like Flux and various infrastructure as code toolsets. However, despite these efforts, a significant gap persisted. This gap lay in providing a seamless, application-centric user experience and easily definable, user-managed custom resource types – precisely what Radius was designed to address. The realization of this missing piece led to extensive collaboration and whiteboarding, culminating in the adoption of Radius to unify their application and infrastructure definitions.

Key Findings

▶ Watch: Radius: a cloud-native application platform definition (4:00)

The adoption and capabilities of Radius, as presented in this talk, reveal several key findings critical for modern cloud-native development and IDP implementation:

• First-Class Application Model: Radius provides a much-needed application model that treats the application as a central, definable entity. This directly addresses the cognitive load on developers by allowing them to focus on application logic rather than intricate infrastructure details, a critical gap identified in existing IDP landscapes.
• Environment-Agnostic Deployment with Recipes: Radius enables defining an application once and deploying it consistently across diverse environments (on-prem, AWS, Azure). This is achieved through infrastructure recipes, which are operator-defined templates (e.g., using Bicep or Terraform) that provision environment-specific infrastructure while presenting a unified abstraction to developers. For instance, a "cache" request might deploy a Redis cache on Kubernetes locally but AWS MemoryDB in the cloud.
• Enhanced Developer-Operator Collaboration: Radius fosters better collaboration by clearly separating concerns. Developers declare their application's needs, while operators define how those needs are met through recipes, ensuring compliance and best practices. This empowers developers with self-service capabilities for infrastructure while maintaining operational control.
• Extensibility through Custom Resources: Platform engineers can extend Radius by defining custom application resource types and catalogs. This allows them to expose specialized resources (e.g., a "small" or "large" storage, or an OpenAI integration) in a highly customized and simplified manner, acting as a clear contract between developers and the platform.
• Operational Visibility with the Application Graph: Every Radius deployment generates an application graph that visually represents all components of an application (containers, databases, caches, frontends, backends) and their explicit connections. This powerful feature significantly improves operational visibility for SREs, developers, architects, and operators, especially in complex distributed systems.
• Seamless GitOps Integration: Radius integrates smoothly with existing GitOps workflows, supporting tools like Flux (with Argo support planned). This ensures that application and infrastructure definitions are version-controlled and deployed consistently through automated, declarative processes.
• Accelerated Delivery and Standardization: Millennium BCP's experience demonstrates that Radius directly contributes to accelerating service delivery by standardizing infrastructure provisioning and reducing manual intervention, moving towards their "from 8 days to 8 minutes" goal. It enables versioning infrastructure as part of the application, aligning its maturity with code pushes.

Technical Deep Dive

▶ Watch: Core design principles: open-source, GitOps, extensibility (5:00)

Radius functions as a cloud-native application platform that allows for a declarative definition of an application, facilitating its deployment across heterogeneous environments. At its core, Radius introduces several key concepts that enable this functionality.

The primary mechanism is the application definition itself. Developers define their applications using a simple, declarative language (e.g., YAML or Bicep). This definition focuses on application components like containers, databases, and caches, abstracting away the underlying infrastructure complexities. For example, a frontend container definition includes its image and port, but crucially, it includes a connection property. These connections are a powerful feature, enabling Radius to automatically inject necessary details, such as connection strings and credentials, into the container as environment variables, allowing the application to connect to its dependencies regardless of where they are deployed.

Infrastructure recipes are central to Radius's environment-agnostic capabilities. These are predefined templates created by platform engineers or operators, specifying how particular infrastructure resources should be provisioned in different environments. For instance, a recipe for a "cache" might use a Bicep template to deploy a Redis cache on a Kubernetes cluster for an on-premise deployment, while a Terraform recipe would provision an AWS MemoryDB cluster for an AWS deployment. Developers simply request a "cache," and Radius, guided by the chosen recipe and environment, provisions the appropriate infrastructure. This allows operators to enforce architectural patterns, compliance, and security standards centrally.

Radius is highly extensible through custom application resource types. Platform engineers can define new resource types tailored to their organization's needs, such as mycompany.app/openAI or a custom "web service." These definitions include properties, which can range from concrete configurations to abstract concepts like "capacity" (e.g., small, medium, large). Once defined and uploaded to Radius via the resource type create command, these custom resources become first-class citizens in the Radius API. This means developer tooling, such as VS Code with Copilot, can recognize and provide auto-completion for these custom properties, streamlining the developer experience. A recipe is then registered for each custom resource, detailing how to provision the underlying cloud services (e.g., an Azure OpenAI GPT turbo model for the openAI resource).

Another significant technical contribution is the application graph. Whenever a Radius application is deployed, the platform automatically generates a graph that visualizes every component – containers, databases, caches, frontends, backends – and their explicit connections. This real-time, visual representation is invaluable for understanding complex distributed applications, aiding in debugging, auditing, and collaboration among diverse team members, from SREs to architects.

Millennium BCP's integration of Radius into their existing ecosystem demonstrates its practical application. They are transitioning from their custom JSON application definitions to Radius's YAML-based deployment templates. These templates are designed to be embedded within existing Helm charts or integrated into GitOps pipelines using tools like Flux or Customize. This approach allows them to version infrastructure as an integral part of the application, ensuring that the infrastructure delivered is precisely aligned with the application version. Furthermore, Radius can leverage existing infrastructure management tools like Crossplane and Terraform through its recipe mechanism, providing flexibility and avoiding the need to entirely re-architect existing infrastructure-as-code investments. The local Radius control plane also enables developers to run and test applications with their associated infrastructure locally, even when calling out to external services like OpenAI, before deploying to shared environments.

Demo / Proof of Concept

▶ Watch: How Radius improves collaboration and self-service for teams (6:00)

Jonathan Smith presented two compelling demonstrations showcasing Radius's core capabilities: cross-environment deployment and extensibility via custom resources.

Demo 1: Seamless Cross-Environment Application Deployment

The first demo illustrated how Radius enables deploying an application consistently across different environments without modifying the application code.

• Application: A simple To-Do list application consisting of a frontend container and a cache.
• Environments: An on-premise Kubernetes cluster and an AWS environment.
• Radius Setup: A Radius control plane was pre-configured for both environments, creating separate workspaces.
• Recipes:
• For the on-premise environment, a Bicep recipe was defined to deploy a Redis cache onto the Kubernetes cluster.
• For the AWS environment, a Terraform recipe was used to provision AWS MemoryDB.
• Developer Workflow:
• The application definition was shown, highlighting a connection between the frontend container and the Redis cache. This connection is crucial as Radius automatically injects details like connection strings and credentials as environment variables into the container.
• Initially, the application was deployed locally using the rad run command, which also provided a port forward. The demo showed the application functioning, and the Radius dashboard (a Backstage-based UI) displayed the application graph, a simple two-node representation of the frontend and cache, clearly showing their explicit connection.
• Next, the application was deployed to AWS using rad deploy.
• Key Observation: A comparison of the rad app graph output in both environments revealed that while the frontend container's configuration remained identical, the underlying infrastructure differed significantly. On-premise utilized Kubernetes resources for Redis, whereas AWS deployed a MemoryDB cluster and associated subnet groups, demonstrating Radius's ability to abstract infrastructure while maintaining application consistency.

Demo 2: Extending Radius with a Custom AI Resource

The second demo focused on Radius's extensibility, showing how platform engineers can create custom resource types to provide tailored developer experiences.

• Goal: To add an AI-powered feedback feature to the To-Do list application.
• Problem: Initially, the "feedback" button in the app failed because no AI support was integrated.
• Custom Resource Creation:

1. A new resource type definition was created for an openAI resource within a custom namespace (mycompany.app). This definition included boilerplate code and a crucial capacity property, allowing developers to choose a "t-shirt size" (small, medium, or large) for their AI instance. This abstracts complex configuration into a simple choice.
2. The definition was uploaded to Radius using the rad resource type create command, effectively extending the Radius API to recognize this new resource.
3. A recipe was registered for this openAI resource. This recipe was templated to deploy a GPT turbo model using Azure OpenAI, specifying the actual cloud infrastructure to be provisioned.

• Developer Workflow:

1. As a developer, the new openAI resource was added to the application definition.
2. The demo highlighted how developer tooling like VS Code and Copilot immediately recognized the new openAI resource and prompted for its required properties, including the capacity (e.g., medium).
3. A connection was established between the frontend container and the new AI resource.
4. The application was deployed to Azure using rad run. Radius provisioned the necessary Azure-specific infrastructure: an Azure OpenAI model, Azure Cache for Redis (for the cache), and the frontend container on a Kubernetes cluster, along with a service account and exposed service.

• Result: The UI's container info tab showed new environment variables injected due to the AI connection. The "feedback" button now successfully interacted with the newly provisioned Azure OpenAI model, demonstrating the seamless integration of a custom, platform-defined resource.

These demos effectively illustrated Radius's power in abstracting infrastructure details from developers, standardizing deployments across diverse cloud environments, and empowering platform engineers to create highly customized and efficient developer experiences.

Defensive Implications

▶ Watch: First demo: deploying applications across on-prem and AWS (8:00)

The adoption of Radius carries significant defensive implications, enhancing the security posture of organizations by standardizing infrastructure provisioning, improving visibility, and fostering a clearer separation of concerns.

Firstly, standardized infrastructure provisioning through infrastructure recipes is a critical security benefit. Operators can define these recipes to embed security best practices, compliance requirements, and approved configurations directly into the deployment process. This means that every instance of a database, cache, or other service provisioned via Radius will adhere to a predefined secure baseline, reducing the risk of misconfigurations, open ports, or incorrect access policies that often lead to vulnerabilities. This shifts security left, ensuring that infrastructure is "secure by design" from the outset.

Secondly, Radius helps in reducing the attack surface by abstracting away low-level infrastructure details from developers. Developers declare their application's needs (e.g., "I need a cache" or "I need an AI service") rather than specifying intricate cloud provider configurations. This minimizes the chances of developers inadvertently introducing security flaws through incorrect or insecure infrastructure settings. The operator-defined recipes act as a security guardrail, ensuring that even self-service provisioning remains secure.

Thirdly, the application graph provides unparalleled visibility and auditability. By visually mapping all application components and their explicit connections, security teams gain a comprehensive, real-time understanding of what is deployed, how components interact, and what dependencies exist. This is invaluable during security audits, incident response, and threat modeling. It allows defenders to quickly identify the scope of an attack, pinpoint affected services, and understand potential lateral movement paths within a compromised application.

Furthermore, Radius promotes consistent security policies across diverse environments. Since the same application definition can be deployed on-premise, AWS, or Azure, the underlying infrastructure recipes ensure that equivalent security controls and compliance standards are applied uniformly. This eliminates environment-specific security drift, simplifying compliance efforts for regulated industries like Millennium BCP.

The independent life cycle enabled by Radius also has defensive benefits. Infrastructure teams can update, patch, and secure underlying resources (e.g., upgrading a Kubernetes version or applying a security patch to a database service) through their recipes without directly disrupting application development workflows. Conversely, developers can iterate on their application code without needing to modify infrastructure definitions unless their application's resource requirements fundamentally change. This clear separation allows security teams to focus on infrastructure hardening and patching independently, ensuring that the foundational layers remain robust.

Finally, the ability to version infrastructure as part of the application ensures that security configurations are tied directly to application versions. This means that if a vulnerability is discovered in a specific infrastructure setup, security teams can trace it back to the exact application version that deployed it and quickly roll back to a known secure configuration if necessary. This deterministic deployment process greatly aids in managing security risks throughout the application lifecycle.

Key Takeaways

• Radius addresses a critical gap in IDPs by providing a first-class application model, enabling developers to define applications as cohesive entities rather than disparate infrastructure components, thereby reducing cognitive load.
• Infrastructure recipes empower operators to standardize and secure infrastructure provisioning, ensuring compliance and best practices are automatically applied across diverse environments (on-prem, AWS, Azure) while offering developers a self-service experience.
• Custom application resource types allow platform engineers to create highly tailored and simplified developer experiences, abstracting complex cloud services into intuitive, domain-specific options (e.g., "small" or "large" AI capacity).
• The application graph provides invaluable operational visibility, mapping all application components and their connections, which significantly aids in collaboration, debugging, and security auditing for complex distributed systems.
• Millennium BCP's successful adoption of Radius demonstrates its real-world impact, enabling them to accelerate service delivery, standardize deployments, and achieve their ambitious "from 8 days to 8 minutes" goal by unifying application and infrastructure management.
• Radius fosters improved developer-operator collaboration by clearly separating concerns, allowing developers to focus on business logic and operators to maintain control over infrastructure definitions and security.

About the Speaker(s)

Nuno Guedes serves as the Head of Public Cloud at Millennium BCP. In this role, Nuno leads the strategic adoption and management of public cloud initiatives within the bank, playing a pivotal role in driving modernization efforts such as the "from 8 days to 8 minutes" program. His work focuses on leveraging cloud-native technologies like Radius to enhance developer productivity, accelerate service delivery, and ensure operational excellence within a regulated industry context.

Jonathan Smith is the Head of Product Management for the Azure Open Source Incubations team at Microsoft. His team is responsible for developing and contributing open-source projects to the cloud-native ecosystem, including well-known projects like Dapr and KEDA, and newer initiatives such as Radius. Jonathan's expertise lies in understanding the challenges faced by platform engineers and building solutions that bridge gaps in the cloud-native landscape, particularly around application modeling and developer experience.