For a large organization, the "best" framework is not a single off-the-shelf turnkey product, but rather a deliberate architectural split between the Developer Portal (the "front door" and catalog) and the Platform Orchestrator (the "engine" that provisions and configures infrastructure).

Large organizations fail when they try to force a single tool to do everything or when they build a "black box" that developers cannot debug. The industry consensus leans toward a composable architecture tailored to your enterprise's primary bottleneck.

Phase 1: Understand the Core Distinction

Before choosing a framework, recognize that an IDP consists of two distinct layers:

• The Portal (The Interface): Where developers go to view services, read docs, check scorecards, and kick off self-service actions (e.g., Spotify's Backstage or Port).
• The Orchestrator (The Execution Engine): What actually parses developer requests, runs Terraform/OpenTofu, handles state, and deploys configuration down to Kubernetes or cloud APIs (e.g., Humanitec or Crossplane / Upbound).

Top Framework Options for Large Enterprises

1. The Open-Source Standard (Portal): Backstage

• Best for: Large enterprises with dedicated internal platform engineering capacity who want ultimate customization and ownership.
• Why it fits: Created by Spotify, Backstage holds massive market share as the standard "front door". It provides a centralized Software Catalog, tech docs, and software templates.
• The Catch: Backstage is a framework , not a product. It has no native execution layer. You will need a dedicated team just to maintain the TypeScript/React codebase, manage plugins, and handle upstream breaking changes.

2. The Commercial/No-Code Alternative (Portal): Port or Cortex

• Best for: Organizations that want a catalog-first approach and developer scorecards without spending 12 months writing custom React/Node plugins.
• Why it fits: Highly flexible data models, out-of-the-box scorecards, and rapid time-to-value. They ingest data from Jira, PagerDuty, GitHub, and cloud resources into a unified graph.
• The Catch: They are SaaS/commercial products (cost attached) and still require an underlying orchestration layer to actually provision infrastructure.

3. The Infrastructure Orchestrator: Humanitec

• Best for: Enterprises drowning in complex Terraform sprawl where infrastructure configuration is the main developer bottleneck.
• Why it fits: It acts as a workload orchestrator that maps developer inputs to environment-agnostic configurations, abstracting raw Terraform away from the developer while keeping ops teams in control of the guardrails.
• The Catch: It requires you to plug in a separate portal interface (like Backstage or Port) to give developers a unified UI.

4. The Cloud-Native / Kubernetes Purist: Crossplane (via Upbound)

• Best for: Kubernetes-heavy shops looking to turn clusters into universal control planes.
• Why it fits: Extends the Kubernetes API to manage cloud infrastructure declaratively. Perfect if your large organization standardizes fully on K8s and wants infrastructure-as-data.
• The Catch: Steep learning curve; requires your platform consumers (or the platform team) to think heavily in Kubernetes Custom Resource Definitions (CRDs).

Recommended Strategy for a Large Enterprise

Instead of hunting for a single "best" tool, large organizations generally succeed by adopting a hybrid, decoupled stack:

To help narrow down the ideal architecture, tell me:

• What is your primary cloud environment (AWS, Azure, GCP, or hybrid/on-prem)?
• Is your infrastructure primarily Kubernetes-based or traditional VM/Serverless?
• Do you have dedicated engineering bandwidth to maintain an open-source framework like Backstage?

If your goal is to build a platform engineering team for a large organization, I would not choose a single “IDP product.” I’d build an IDP architecture around a few deliberate layers.

My recommendation

Best overall approach: Backstage + an orchestration layer + your existing infrastructure/CI/CD stack.

A strong enterprise architecture looks roughly like:

                 DEVELOPERS
                     │
          ┌──────────┴──────────┐
          │                     │
       Backstage             CLI / API
     Developer Portal
          │
          ▼
   ┌─────────────────┐
   │ Platform Control│
   │ / Orchestration │
   └────────┬────────┘
            │
     ┌──────┼───────────────┐
     ▼      ▼               ▼
  Kubernetes  Cloud/IaC   CI/CD
     │      Terraform     Argo/GitHub/etc.
     │
     └──────────┬───────────┘
                ▼
       AWS / Azure / GCP /
       Databases / Queues /
       Observability / etc.

Backstage is particularly good for the front door: its catalog, templates, TechDocs and plugin ecosystem make it a strong enterprise developer portal.

But Backstage itself isn't the whole IDP. That's an important distinction. A portal gives developers an interface; the IDP needs to actually provision infrastructure, configure applications, manage environments, enforce policies, and orchestrate deployments.

The shortlist I'd evaluate

1. Backstage — the portal/catalog layer

I'd strongly consider Backstage as the developer-facing layer.

It gives you:

• Service/software catalog
• Ownership and relationships
• Software templates
• Documentation
• Plugin ecosystem
• Developer self-service UI
• A place to expose your organization's "golden paths"

Its plugin architecture is particularly valuable in a large organization because you will inevitably need to integrate existing systems rather than replace everything.

2. Add a real orchestration/control layer

This is where many IDP initiatives go wrong.

You don't want Backstage becoming a giant collection of scripts that directly manipulate Kubernetes, Terraform, AWS, GitHub, databases, etc.

You want something like:

Developer → declarative intent → platform orchestration → infrastructure

For an enterprise that wants to move quickly, I'd seriously evaluate Humanitec Platform Orchestrator.

Humanitec positions its orchestrator as the backend/configuration engine for an IDP: it interprets workload requirements, applies platform rules, provisions resources and manages deployment/environment configuration.

The interesting architectural property is that you don't have to use its portal. You can put Backstage, your CLI, or another developer experience on top of the orchestration layer.

That separation is very attractive for a large organization.

3. Don't replace everything

Your IDP should orchestrate the technologies you already have:

• Kubernetes/OpenShift
• Terraform
• AWS/Azure/GCP
• GitHub/GitLab
• Argo CD or existing CD
• Vault/secrets management
• Databases
• Kafka/message queues
• Observability
• IAM
• Security/policy tooling

The platform team's job is to make those things easy and safe to consume, not necessarily to replace them.

---

If you want an open-source-first architecture

I'd investigate:

Backstage + Crossplane + Terraform + Argo CD + Kubernetes + GitHub/GitLab

with Backstage providing the developer experience and Crossplane/IaC providing infrastructure abstractions.

This gives you tremendous control, but it also means your platform team owns the integration layer. That's powerful, but it creates a substantial long-term engineering commitment.

That's why I would distinguish:

Best framework: Backstage Best architecture: Backstage + orchestration + existing infrastructure Best commercial accelerator: Backstage + a platform orchestrator such as Humanitec Best OSS-heavy route: Backstage + Crossplane + Terraform + Argo CD

More importantly: design the team around products, not tools

For a large organization, I'd structure the platform organization around developer outcomes, rather than "the Kubernetes team" or "the Terraform team."

A reasonable starting organization might be:

Head of Platform Engineering
│
├── Developer Experience
│   ├── Backstage
│   ├── CLI
│   ├── Templates
│   └── Documentation
│
├── Application Platform
│   ├── Kubernetes
│   ├── Runtime
│   ├── Networking
│   └── Service dependencies
│
├── Infrastructure Platform
│   ├── Cloud
│   ├── Terraform/IaC
│   ├── Databases
│   └── Infrastructure provisioning
│
├── Developer Delivery
│   ├── CI/CD
│   ├── Environments
│   ├── Release strategies
│   └── Deployment automation
│
└── Platform Reliability & Security
    ├── SRE
    ├── IAM
    ├── Policy
    ├── Observability
    └── Compliance

The crucial principle is Platform as a Product: developers are your customers, and the platform team owns their experience from request → provision → deploy → operate. This is also consistent with the broader definition of an IDP as an integrated collection of tools and workflows rather than a single product.

What I would build first

Don't start by trying to create an enterprise-wide platform.

Start with one golden path:

"Create a production-ready service." A developer should be able to go from nothing to:

Create service
      ↓
Repository created
      ↓
CI pipeline configured
      ↓
Container built
      ↓
Dev environment created
      ↓
Database/cache provisioned if requested
      ↓
Observability configured
      ↓
Security policies applied
      ↓
Deploy to staging
      ↓
Promote to production

The developer should not need to know whether that involved Terraform, Kubernetes, Helm, Argo, AWS APIs, Crossplane, Vault, etc.

That's your platform's value proposition.

The metric I'd optimize for

Don't measure the platform by:

"How many Backstage plugins have we deployed?" Measure:

• Time to first production deployment
• Deployment frequency
• Lead time for changes
• Change failure rate
• MTTR
• Percentage of workloads using golden paths
• Developer satisfaction
• Reduction in platform/ops tickets
• Percentage of infrastructure provisioned through self-service

In other words, the IDP is successful when developers stop thinking about the IDP.

---

My default enterprise stack

If I were starting your platform team today, I'd initially prototype:

Backstage → developer portal/catalog

Humanitec or Crossplane → orchestration/control plane

Terraform → existing infrastructure modules

Kubernetes/OpenShift → application runtime

Argo CD or existing CD → deployment

GitHub/GitLab → source/CI

Vault/cloud secrets → secrets

OpenTelemetry + existing observability stack → telemetry

OPA/Kyverno/cloud policies → governance

Then I'd expose 5–10 carefully designed golden paths, rather than exposing hundreds of infrastructure primitives.

If you tell me roughly how large the organization is (e.g. 500, 5,000, or 50,000 developers), your cloud strategy (AWS/Azure/GCP/hybrid), Kubernetes/OpenShift usage, and whether you prefer open source vs. commercial, I can give you a concrete enterprise IDP reference architecture, recommended tool stack, and a 6–12 month platform-team roadmap.

A developer should be able to go from nothing to:

Create service
      ↓
Repository created
      ↓
CI pipeline configured
      ↓
Container built
      ↓
Dev environment created
      ↓
Database/cache provisioned if requested
      ↓
Observability configured
      ↓
Security policies applied
      ↓
Deploy to staging
      ↓
Promote to production

The developer should not need to know whether that involved Terraform, Kubernetes, Helm, Argo, AWS APIs, Crossplane, Vault, etc.

That's your platform's value proposition.

The metric I'd optimize for

Don't measure the platform by:

"How many Backstage plugins have we deployed?" Measure:

• Time to first production deployment
• Deployment frequency
• Lead time for changes
• Change failure rate
• MTTR
• Percentage of workloads using golden paths
• Developer satisfaction
• Reduction in platform/ops tickets
• Percentage of infrastructure provisioned through self-service

In other words, the IDP is successful when developers stop thinking about the IDP.

---

My default enterprise stack

If I were starting your platform team today, I'd initially prototype:

Backstage → developer portal/catalog

Humanitec or Crossplane → orchestration/control plane

Terraform → existing infrastructure modules

Kubernetes/OpenShift → application runtime

Argo CD or existing CD → deployment

GitHub/GitLab → source/CI

Vault/cloud secrets → secrets

OpenTelemetry + existing observability stack → telemetry

OPA/Kyverno/cloud policies → governance

Then I'd expose 5–10 carefully designed golden paths, rather than exposing hundreds of infrastructure primitives.

If you tell me roughly how large the organization is (e.g. 500, 5,000, or 50,000 developers), your cloud strategy (AWS/Azure/GCP/hybrid), Kubernetes/OpenShift usage, and whether you prefer open source vs. commercial, I can give you a concrete enterprise IDP reference architecture, recommended tool stack, and a 6–12 month platform-team roadmap.

For a large organization, there is no single out-of-the-box product that magically solves platform engineering. Instead, the industry has converged on a clear distinction: Internal Developer Portals (the UI/UX and catalog layer) versus IDP Orchestration Engines (the backend configuration and provisioning layer).

For large-scale enterprises, the "best framework" depends on whether your strategy is build-and-own or buy-and-configure.

1. The Open-Source Gold Standard (Best for Customization & Scale)

• Backstage (CNCF Graduated Project)
  • Best For: Large engineering organizations that want to own their long-term platform roadmap, have dedicated frontend/backend engineering capacity, and need heavy custom integrations.
  • Why it fits large orgs: Originally created by Spotify, Backstage acts as the central "front door" (Portal) with a robust Software Catalog, template scaffolding, and a massive open-source plugin ecosystem.
  • The Catch: It is a framework, not a turnkey product. You will need a dedicated team just to maintain Backstage, write custom plugins, and handle upgrades.
  • Enterprise alternative: If you love Backstage but need enterprise-grade RBAC, support, and compliance hardening out of the box, look at Red Hat Developer Hub.

2. The Turnkey Portal Leaders (Best for Fast Time-to-Value)

• Port, Cortex , or
  • Best For: Large enterprises that want a rich developer portal, service catalog, and maturity scorecards without spending 12 months writing TypeScript and maintaining a massive Node.js/React backend.
  • Why it fits large orgs: They offer incredibly powerful no-code/low-code data models, robust security scorecards (tracking CVEs, ownership, and golden path adoption), and native self-service actions.
  • The Catch: SaaS subscription costs scale with developer count, and you are bound to their ecosystem roadmap rather than absolute infinite custom code.

3. The Orchestration & Infrastructure Engine (Best for "Paved Paths" to Production)

• • Best For: Orgs focusing heavily on environment management, dynamic configuration, and abstracting complex Kubernetes/cloud setups away from developers.
  • Why it fits large orgs: Humanitec acts as an IDP orchestration engine. It allows platform teams to define strict architectural "paved paths" while giving developers self-service control to spin up ephemeral environments or preview deployments safely.
  • The Catch: It handles the backend engine and workflow coordination exceptionally well, but you will often pair it with a portal (like Backstage or Port) to give developers a unified glass pane.

Strategic Recommendation for a Large Org

Rather than picking one tool blindly, large organizations generally succeed by adopting a two-layer framework:

1. The Portal Layer (The Face): Use Backstage (if you have the engineering bandwidth to code/maintain it) or Port / Cortex (if you want immediate governance, scorecards, and a catalog without building it yourself).
2. The Orchestration Layer (The Engine): Use infrastructure orchestration tools like Humanitec or custom Terraform/Crossplane pipelines triggered via API from your chosen portal.

To help narrow down the right architectural choice, tell me:

• What does your current tech stack look like primarily (e.g., heavily Kubernetes-based, AWS/Azure native, or a mix of legacy and cloud)?
• Do you have dedicated internal engineering resources to build and maintain an open-source tool like Backstge, or do you prefer a fully managed SaaS solution?

If your goal is to build an internal platform engineering team for a large organization, I would not choose an “IDP product” first. I’d choose an IDP architecture and operating model, then select tools that implement it.

My recommendation

For a large enterprise, my default starting architecture would be:

Backstage + Kubernetes + GitOps + Terraform/OpenTofu + a policy layer + your existing CI/CD/cloud stack, with the platform team operating it as a product.

Backstage is particularly attractive as the developer-facing control plane/portal. It is a CNCF project with a large ecosystem, and CNCF's 2026 Technology Radar places Backstage in the “Adopt” category for application delivery technologies.

But there's an important distinction:

Backstage is not the IDP. It is the portal/interface into the IDP. An IDP is the collection of workflows, infrastructure, automation, policies, APIs and developer interfaces that provide your engineers with self-service "golden paths." CNCF explicitly distinguishes the internal developer platform from the developer portal.

The enterprise reference architecture I'd use

                    ┌─────────────────────────┐
                    │       Developers        │
                    └────────────┬────────────┘
                                 │
                     UI / CLI / API / Git
                                 │
                    ┌────────────▼────────────┐
                    │       BACKSTAGE         │
                    │  Catalog • Templates    │
                    │  Docs • Scorecards      │
                    └────────────┬────────────┘
                                 │
                    ┌────────────▼────────────┐
                    │   PLATFORM API /        │
                    │   ORCHESTRATION LAYER   │
                    └─────┬──────┬──────┬─────┘
                          │      │      │
              ┌───────────┘      │      └───────────┐
              ▼                  ▼                  ▼
         Terraform/         Kubernetes          Cloud APIs
         OpenTofu           + Helm/Kustomize     AWS/Azure/GCP
              │                  │
              └──────────┬───────┘
                         ▼
                  GitOps / CI/CD
                  Argo CD / etc.
                         │
                         ▼
              ┌──────────────────────┐
              │   Runtime Platform   │
              │ K8s • VMs • DBs • MQ │
              └──────────────────────┘

       ┌─────────────────────────────────────────┐
       │ Cross-cutting:                         │
       │ IAM • Policy • Security • Observability │
       │ FinOps • Secrets • Compliance • Audit   │
       └─────────────────────────────────────────┘

The important architectural principle is separation of concerns. Developers shouldn't need to understand every layer underneath the platform, but the platform shouldn't become a black box that prevents experienced engineers from accessing underlying capabilities.

CNCF's platform engineering maturity model makes essentially the same point: mature platforms move from custom processes → standard tooling → self-service interfaces → integrated services, while simultaneously treating the platform as a product.

What I'd choose for each layer

I particularly like Backstage + existing infrastructure for a large organization because you can introduce the platform without requiring every engineering group to migrate immediately.

The bigger decision: build vs. buy

There are really three approaches.

1. Backstage-centered platform — my default

Use Backstage as the front door and compose the underlying platform from technologies you already operate.

This is best when you have:

• thousands of developers
• multiple business units
• significant brownfield infrastructure
• multiple clouds or environments
• existing Kubernetes
• existing CI/CD
• significant regulatory/security requirements
• a desire to avoid vendor lock-in

Backstage's plugin architecture, catalog, templates and self-service capabilities are specifically designed for this type of extensible enterprise platform.

2. Commercial platform/orchestrator

Products such as Humanitec can provide a substantial portion of the orchestration layer.

Humanitec, for example, positions its Platform Orchestrator as the configuration engine behind an enterprise IDP, while allowing the portal to be separate.

This can make sense if your priority is:

"We need a platform quickly and don't want to build all of the orchestration machinery ourselves."

I'd seriously evaluate this if your organization has a relatively small platform team but a very large developer population.

3. Full commercial IDP/portal

You can also evaluate commercial developer-platform products such as Port or similar offerings.

The advantage is speed and reduced maintenance. The downside is that you need to examine very carefully how deeply the product integrates with your existing infrastructure, IAM, networking, deployment model, compliance requirements and brownfield estate.

For a large enterprise, I'd avoid selecting a product primarily because its portal looks nicer.

The orchestration and integration model matter much more than the portal UI.

---

The platform team I'd actually build

This is where I think many organizations get IDPs wrong.

Don't create an "internal DevOps team."

Create a platform product organization.

CNCF's maturity model explicitly describes the progression from a dedicated team to treating the platform as a product, with adoption, interfaces, operations and measurement all becoming progressively more mature.

I'd structure the initial team roughly like:

             Head / Director of Platform Engineering
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
 Platform Product       Developer Experience    Platform Runtime
        │                     │                     │
 Product manager        Backstage               Kubernetes
 Product designer       Templates               Networking
 Platform architect     Docs                    Compute
                        Developer workflows     Storage
        │
        └─────────────── Platform Enablement ───────────────┐
                                                             │
                                                Security / IAM / Policy
                                                Infrastructure automation
                                                Observability
                                                Reliability

You don't necessarily need all these as separate teams initially. One cross-functional team of ~6–10 people can build the first genuinely useful platform.

Your first "golden paths"

Don't start by trying to platformize everything.

Start with 3–5 high-value paths.

For example:

Golden Path #1 — New microservice

Developer clicks:

Create Service The platform creates:

Git repository
      ↓
standard service structure
      ↓
CI pipeline
      ↓
container build
      ↓
security scanning
      ↓
deployment configuration
      ↓
dev environment
      ↓
staging
      ↓
production

The developer shouldn't have to open five infrastructure tickets.

Golden Path #2 — Existing service onboarding

This is arguably even more important in an enterprise.

Take an existing application and let the platform establish:

• ownership
• service metadata
• deployment configuration
• observability
• security controls
• dependency information
• production readiness
• operational runbooks

Golden Path #3 — Infrastructure provisioning

Instead of:

"Open a ticket to get a database." Give developers:

Create PostgreSQL database with the platform automatically handling:

• provisioning
• credentials
• networking
• backups
• monitoring
• encryption
• policies
• cost attribution
• lifecycle

The platform should expose capabilities, not infrastructure implementation details.

---

The metric that matters most

Don't measure your IDP by:

• number of Backstage plugins
• number of Kubernetes clusters
• number of Terraform modules
• number of platform engineers
• number of services registered

Measure developer outcomes.

I'd establish a dashboard around:

This aligns closely with CNCF's recommendation to treat platform engineering as a business/product discipline involving people, process, policy and technology—not merely tooling.

One important warning

Don't build "the platform" before you understand your developers.

The most common failure mode is:

Platform team
     ↓
builds giant abstraction
     ↓
announces it
     ↓
developers ignore it
     ↓
platform team adds more features
     ↓
developers ignore it harder

Instead:

Developer pain
     ↓
one golden path
     ↓
10–20 pilot teams
     ↓
measure outcome
     ↓
iterate
     ↓
expand

CNCF's maturity model explicitly recommends this product-style progression: identify a problem, develop a minimum viable solution, iterate based on fit, and then scale it.

My overall recommendation

If I were advising a large enterprise starting from scratch, my stack would be:

Backstage → developer portal/catalog

Git → source of truth

Terraform/OpenTofu → infrastructure provisioning

Kubernetes → standardized runtime where appropriate

Argo CD/GitOps → delivery

Cloud APIs + existing enterprise infrastructure → underlying capabilities

OPA/Kyverno/etc. → guardrails

Existing IAM/security/observability → enterprise integration

Platform APIs/orchestration → the layer that turns all of the above into coherent self-service

And I'd build the organization around Platform as a Product, rather than around a particular vendor.

The key insight is that Backstage is probably the best starting framework for the developer experience, but it is not sufficient by itself to be your enterprise IDP. The IDP is the entire product surrounding it.

If you tell me roughly how many developers you have (e.g. 500 / 5,000 / 20,000), your cloud setup (AWS/Azure/GCP/multi-cloud), whether you already run Kubernetes, and your existing CI/CD tooling, I can lay out a concrete enterprise IDP reference architecture, team structure, technology choices, and 6/12/24-month implementation roadmap.

• ownership
• service metadata
• deployment configuration
• observability
• security controls
• dependency information
• production readiness
• operational runbooks

Golden Path #3 — Infrastructure provisioning

Instead of:

"Open a ticket to get a database." Give developers:

Create PostgreSQL database with the platform automatically handling:

• provisioning
• credentials
• networking
• backups
• monitoring
• encryption
• policies
• cost attribution
• lifecycle

The platform should expose capabilities, not infrastructure implementation details.

---

The metric that matters most

Don't measure your IDP by:

• number of Backstage plugins
• number of Kubernetes clusters
• number of Terraform modules
• number of platform engineers
• number of services registered

Measure developer outcomes.

I'd establish a dashboard around:

This aligns closely with CNCF's recommendation to treat platform engineering as a business/product discipline involving people, process, policy and technology—not merely tooling.

One important warning

Don't build "the platform" before you understand your developers.

The most common failure mode is:

For a large organization, there is no single out-of-the-box product labeled "The Best IDP." Instead, industry consensus and enterprise architecture divide an Internal Developer Platform (IDP) into two distinct layers: the Portal Layer (the user interface and catalog) and the Orchestration Layer (the engine that provisions infrastructure and deployments).

The most successful large organizations approach an IDP as an assembly of robust foundational frameworks rather than a monolithic purchase.

Phase 1: The Portal Layer (The "Front Door")

This is what developers see, use to spin up templates, view documentation, track service ownership, and check security scorecards.

• Backstage (Open Source / CNCF)
  • Best For: Large enterprises with dedicated platform engineering capacity who want total ownership, a rich plugin ecosystem (>200 is greater than 200>2 0 0 plugins), and deep customization.
  • Why it wins at scale: Created by Spotify and now a CNCF incubating project, Backstage is the de facto standard framework for enterprise developer portals. Its software catalog acts as the single source of truth for microservices, and its scaffolder enforces golden paths.
  • The Catch: It is a framework, not a turnkey product; it requires a dedicated team of engineers to host, secure, and write custom plugins.
• Port or Cortex or OpsLevel (Commercial SaaS)
  • Best For: Organizations that want a production-ready portal, dynamic service catalogs, and advanced maturity scorecards without maintaining a React/Node.js microservice architecture in-house.
  • Why it wins at scale: Drastically faster time-to-value. They offer out-of-the-box data modeling, robust role-based access control (RBAC), and gamified engineering scorecards.

Phase 2: The Orchestration Layer (The "Engine")

The portal is useless if it doesn't talk to an execution layer that actually builds, tests, and deploys infrastructure safely.

• The GitOps & IaC Stack (Argo CD, Terraform / OpenTofu , or Crossplane)
  • Best For: Organizations standardizing on Kubernetes and cloud-native infrastructure.
  • Why it wins at scale: Crossplane extends Kubernetes to orchestrate any cloud resource declaratively, while Argo CD handles continuous deployment synchronization.
• Humanitec (Platform Orchestrator)
  • Best For: Enterprises wanting to cleanly separate application configuration from infrastructure provisioning.
  • Why it wins at scale: It acts as the "missing middle," allowing platform teams to define workload specifications and environment dynamics without locking developers into raw Terraform or complex CI/CD scripting.

The Recommended Blueprint for Large Enterprises

Instead of choosing one tool, the winning enterprise pattern is a composable architecture:

1. Portal: Adopt Backstage (or a managed equivalent like Roadie if you want to bypass hosting overhead) to serve as the unified user interface and catalog.
2. Pipelines & CI/CD: Leverage existing enterprise investments like GitHub Actions or GitLab CI for build/test execution.
3. Deployment & Provisioning: Connect Backstage templates to Terraform/Crossplane modules executed via GitOps (Argo CD).
4. Governance: Enforce compliance and quality gates through automated Scorecards and Policy-as-Code.

To help tailor this framework, tell me:

• What is your primary infrastructure target (Kubernetes, AWS/Azure/GCP, or hybrid)?
• Do you have dedicated frontend/platform engineers to build and maintain an open-source tool like Backstage, or do you need a commercial/low-code portal?

If you’re building an internal platform engineering team for a large organization, my recommendation is:

Best overall: Backstage + an orchestration layer

I would make Backstage the developer-facing foundation, rather than trying to make Backstage itself be the entire IDP.

Backstage is an open-source framework from Spotify that is now a CNCF project. It provides a software catalog, ownership model, templates/scaffolding, documentation, search, and an extensible plugin architecture. CNCF describes it as a leading open-source framework for building internal developer portals.

The important distinction is:

Backstage = developer portal / experience
Platform orchestrator = infrastructure and deployment automation
Your platform team = the product organization connecting the two

My recommended enterprise architecture

                    DEVELOPERS
                         │
                         ▼
              ┌─────────────────────┐
              │      BACKSTAGE       │
              │                     │
              │ Catalog              │
              │ Golden paths         │
              │ Scaffolding          │
              │ Documentation        │
              │ Ownership            │
              │ Developer workflows  │
              └──────────┬──────────┘
                         │
                  self-service APIs
                         │
                         ▼
              ┌─────────────────────┐
              │ PLATFORM ORCHESTRATOR│
              │                     │
              │ Environments         │
              │ Deployments           │
              │ Infrastructure        │
              │ Policies              │
              │ Secrets/config        │
              │ Audit/rollback        │
              └──────────┬──────────┘
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
       Kubernetes      Cloud          CI/CD
       /VMs/etc.      AWS/Azure/GCP   GitHub/etc.
          │
          ▼
    Observability / Security / Data

This is preferable to building a giant monolithic "IDP product."

Why Backstage is my #1 choice for a large enterprise

1. It scales organizationally, not just technically.

The catalog gives you a common model for services, libraries, websites, pipelines, ML models, ownership and dependencies. Backstage explicitly supports organizations with thousands of software components.

That's particularly valuable when your problem is no longer "how do I deploy Kubernetes?" but:

What do we own? Who owns it? How is it deployed? What dependencies does it have? Is it compliant? What is the approved way to create another one?

2. Golden paths are first-class.

Backstage Software Templates let you encode organizational standards into reusable scaffolding workflows.

For example:

Create Java service

could automatically produce:

• Git repository
• standard project structure
• CI/CD pipeline
• container configuration
• Kubernetes deployment
• observability
• security scanning
• service catalog registration
• documentation
• ownership metadata
• production readiness checks

That's much more valuable than simply giving developers a prettier Kubernetes UI.

3. It gives you an enterprise integration point.

Large companies almost inevitably have heterogeneous infrastructure: multiple clouds, Kubernetes clusters, legacy VMs, different CI systems, databases, security tooling, ticketing systems, etc.

Backstage's plugin/integration model makes it a reasonable common front door rather than forcing everything underneath it to use one infrastructure stack.

4. The ecosystem matters.

For a large organization, I'd strongly favor a platform with a large ecosystem over a technically elegant but niche solution. Backstage has become a de facto open-source standard in this space, according to CNCF's 2026 assessment.

---

But don't use Backstage alone

This is the most important caveat.

Backstage isn't, by itself, your complete Internal Developer Platform.

It is primarily the portal and platform framework. Your platform still needs an execution/orchestration layer underneath it.

One interesting enterprise option is Humanitec. Its Platform Orchestrator is explicitly designed to be the configuration and orchestration engine behind an IDP, handling infrastructure provisioning, application configuration, deployments, environments and policy.

You could therefore have:

Backstage → Humanitec → Kubernetes/cloud/CI/CD

rather than trying to implement all of that orchestration logic yourself.

---

What about Port, Cortex and OpsLevel?

I'd evaluate them, but my default choice for a large organization with a serious platform engineering team would still be Backstage.

Current industry comparisons similarly tend to distinguish portal/catalog products from orchestration products, rather than treating them as interchangeable.

---

The architecture I'd choose

For, say, 1,000–10,000+ engineers, I'd seriously consider:

Developer experience

Backstage

• Software catalog
• Service ownership
• Golden paths
• Scaffolding
• TechDocs
• Search
• API catalog
• Engineering scorecards
• Links into operational tooling

Backstage's TechDocs also gives you a docs-as-code model where documentation lives alongside the code.

Platform control plane

Choose either:

Option A — Build/control it yourself

Backstage
    ↓
Your platform APIs
    ↓
Crossplane / Terraform / Argo CD / Kubernetes

or:

Option B — Buy more of the orchestration layer

Backstage
    ↓
Humanitec
    ↓
Terraform / Kubernetes / cloud / CI/CD

Infrastructure

I'd keep infrastructure implementation details behind the platform:

• Kubernetes
• Terraform
• Crossplane where appropriate
• Argo CD / another GitOps system
• Cloud APIs
• Vault/secrets
• cloud databases
• observability
• security tooling

The developer shouldn't need to know which combination you're using.

---

The bigger architectural principle

Don't build an "IDP."

Build a product for developers.

CNCF's platform-engineering guidance emphasizes treating the platform as a product and building golden paths that reduce developer cognitive load.

I'd define the platform team's mission as:

Make the organization's preferred way of building and operating software the easiest way.

That leads to a very different design.

Instead of:

"Here's a portal where you can see your Kubernetes resources."

you want:

"I need a production service."

One workflow:

Create service
      ↓
Choose language/runtime
      ↓
Choose data requirements
      ↓
Choose exposure
      ↓
Create
      ↓
Everything provisioned
      ↓
CI/CD configured
      ↓
Security configured
      ↓
Observability configured
      ↓
Catalog + documentation registered
      ↓
Production-ready service

The underlying platform can be extraordinarily complicated. The developer experience should not be.

---

My recommendation by organization size

<200 engineers:
Don't over-engineer it. Backstage may be more platform than you need.

200–1,000:
Backstage or Port + relatively lightweight platform automation.

1,000–5,000:
Backstage + serious orchestration layer is my preferred architecture.

5,000–20,000+:
Backstage + dedicated platform control plane + multiple platform teams, with strong APIs, governance, tenancy boundaries and paved roads.

At that scale, avoid creating one giant central platform team. Large organizations can turn the platform team itself into a bottleneck; CNCF discussions on platform scaling specifically call out this problem.

Bottom line

If you asked me to pick one framework today for a large enterprise, I'd pick Backstage.

But if you asked me to design the actual IDP, I'd choose:

Backstage + platform orchestration + GitOps/IaC + strong golden paths + engineering scorecards.

And I would not build the whole thing as a custom Backstage plugin ecosystem before validating what developers actually need.

If you're starting this platform team from scratch, the next decision I'd make is the reference architecture and team topology—e.g. what should be owned centrally, what should remain with application teams, and which 5–10 golden paths to build first.

For a large organization, the best answer is usually not a single IDP product. The strongest enterprise platforms are typically an architecture made of several layers:

1. Developer portal / experience layer
2. Platform automation and orchestration layer
3. Service catalog and governance layer
4. Golden paths and paved-road workflows
5. Observability, security, and compliance integrations

A common enterprise pattern is:

Backstage + platform automation + service maturity tooling.

My recommendation for a large enterprise

1. Developer portal: Backstage

For organizations with hundreds or thousands of engineers, Backstage is often the strongest foundation because it is highly customizable and has a broad ecosystem. It provides:

• Software catalog
• Service ownership model
• Templates/scaffolding (“golden paths”)
• Documentation integration
• Plugin architecture
• Developer-facing portal experience

Backstage is especially appropriate when you have a real platform engineering team that can treat the IDP as a product. It is not a turnkey platform; you are building and operating your internal product around it.

Best fit:

• 1,000+ engineers
• Multiple business units
• Multiple clouds or Kubernetes clusters
• Strong internal engineering culture
• Willingness to invest in platform engineering

---

2. Provisioning/orchestration: choose based on your infrastructure model

The portal should not become a giant UI wrapper around Terraform scripts. The platform team should expose self-service capabilities.

Typical options:

• Kubernetes-native organizations:

  • GitOps workflows
  • Kubernetes operators
  • Crossplane-style abstractions
  • Platform APIs

• Enterprise environments with complex infrastructure:

  • Dedicated orchestration platforms
  • Internal APIs that abstract cloud complexity

Tools such as Humanitec-style orchestration approaches focus on separating developer intent (“I need a service with a database”) from infrastructure implementation (“AWS RDS + Kubernetes secret + monitoring configuration”).

---

3. Service ownership and maturity: add scorecards

Large enterprises usually need answers like:

• Who owns this service?
• Does it have an SLO?
• Is it patched?
• Does it have monitoring?
• Does it meet compliance requirements?

Tools in this category include:

• Cortex
• OpsLevel

These complement a portal rather than replace it.

---

A reference architecture I would build

                    Developers
                        |
                        v
              Internal Developer Portal
                    (Backstage)
                        |
        +---------------+---------------+
        |                               |
        v                               v
 Golden Paths                  Platform APIs
(service templates)             (self-service)
        |                               |
        v                               v
 CI/CD + Security             Cloud/Kubernetes
 + Observability              + Infrastructure
        |
        v
 Service Catalog + Scorecards

---

What I would avoid

❌ Building a custom portal from scratch

Many companies accidentally recreate Backstage:

• service catalog
• authentication
• plugins
• templates
• docs
• dashboards

That becomes a permanent software product to maintain.

❌ Giving developers raw Terraform modules

Terraform is excellent infrastructure tooling, but it is not a developer experience layer.

❌ Making the platform team an approval gate

A successful IDP reduces tickets. It should provide guardrails, not create a new queue.

---

Suggested rollout strategy

Phase 1: Establish the platform product (0–3 months)

Build:

• Service catalog
• Ownership model
• Standard templates
• CI/CD standards
• Basic golden paths

Phase 2: Self-service infrastructure (3–9 months)

Add:

• Environment creation
• Database provisioning
• Secrets management
• Observability setup
• Security scanning

Phase 3: Enterprise maturity (9–18 months)

Add:

• Compliance automation
• Cost visibility
• Reliability scorecards
• Developer productivity metrics
• AI-assisted platform workflows

---

Bottom line

For a large enterprise, I would start with:

Backstage as the developer portal + Kubernetes/GitOps-based platform automation + service scorecards.

If you have a very large engineering organization and the budget for a dedicated platform team, this gives you the most flexibility and avoids locking your engineering model into a vendor.

If your organization is smaller (for example, under a few hundred engineers) or you need value quickly, a managed IDP such as Port, Cortex, or similar offerings may reduce the amount of platform engineering needed.

A key question that changes the recommendation: How large is the engineering organization (number of developers), and are you primarily AWS, Azure, GCP, Kubernetes, or hybrid?

For a large organization, there is no single out-of-the-box turnkey framework that solves every requirement. Modern platform engineering recognizes that an IDP is not a single tool, but a combination of two distinct layers: the Portal layer (the "front door" for visibility and cataloging) and the Orchestration/Execution layer (the "engine" that provisions infrastructure and changes state).

The most successful large enterprises implement a composable architecture by pairing a leading developer portal with a robust platform orchestrator.

Phase 1: Choose Your Portal (The Interface & Catalog)

The portal provides your developers with a unified dashboard, service catalogs, software templates, and documentation.

• Backstage (Open Source, CNCF): The undisputed market leader and "front door" created by Spotify. Best for: Large orgs with dedicated JavaScript/TypeScript/React engineering capacity to build and maintain a custom portal and plugin ecosystem. Alternative: If you want Backstage without the heavy self-hosted maintenance overhead, consider commercial managed alternatives like Roadie.
• Port (Commercial, No-Code/Low-Code): A highly customizable data-model-driven portal. Best for: Teams that want rich visual developer scorecards, flexible data mapping (tracking AWS resources, PagerDuty, and microservices), and fast time-to-value without writing custom React plugins.
• Cortex or OpsLevel (Commercial): Portals hyper-focused on service ownership, technical maturity, and production-readiness scorecards. Best for: Organizations whose primary bottleneck is enforcing compliance, tracking microservice health, and driving engineering excellence across hundreds of teams.

Phase 2: Choose Your Orchestrator (The Execution Engine)

A portal is only as powerful as the automation triggered beneath it. You need an orchestrator to safely turn abstract developer requests into concrete infrastructure (Terraform, Argo CD, Kubernetes).

• Humanitec (Commercial Platform Orchestrator): Focuses on dynamic environment management and configuration graph orchestration. Best for: Enterprises wanting centralized standardization that cleanly separates app config from infrastructure code without rewriting existing CI/CD pipelines. Frequently paired with the open-source workload specification Score.
• Crossplane (CNCF Open Source): Turns Kubernetes into a universal control plane to manage external cloud infrastructure declaratively using Custom Resource Definitions (CRDs). Best for: Cloud-native, Kubernetes-heavy enterprises that want infrastructure provisioning treated as native, reconciled API calls.
• Kratix (CNCF/Syntasso Open Source): A framework for building composable platforms by packaging capabilities into versioned "Promises". Best for: Advanced platform teams that want a modular, highly tailored framework to vend customized resources safely.

Recommended Enterprise Blueprint

For a large organization, the proven reference architecture is:

1. Portal: Backstage (or Port) as the developer-facing UI.
2. Orchestration: Humanitec or Crossplane to handle backend state and infrastructure generation.
3. Delivery: Argo CD / GitHub Actions for GitOps execution.
4. Governance: OPA Gatekeeper or Kyverno for automated policy enforcement.

To help narrow down the ideal stack for your organization, could you share:

• What is your primary infrastructure footprint (Kubernetes-heavy, hybrid-cloud, or multi-cloud)?
• Do you have dedicated engineering headcount to maintain open-source frameworks like Backstage, or do you prefer a commercial/managed toolset?

If you're building an internal platform engineering team for a large organization, I would not choose a single "IDP framework" in isolation.

My recommendation is:

Use Backstage as the developer-facing portal, and build the platform underneath it around Kubernetes/GitOps/IaC and a dedicated orchestration layer. For a large enterprise, strongly consider Humanitec as that orchestration layer rather than building the orchestration yourself.

This gives you a much better separation of concerns than trying to make Backstage itself be the platform.

My recommended enterprise architecture

                    DEVELOPERS
                         │
                ┌────────▼────────┐
                │    Backstage    │
                │ Developer Portal │
                └────────┬────────┘
                         │
              Golden Paths / Self-Service
                         │
                ┌────────▼────────┐
                │   Orchestration │
                │ Humanitec / DIY │
                └────────┬────────┘
                         │
        ┌────────────────┼────────────────┐
        │                │                │
     Kubernetes       Terraform        Cloud APIs
        │                │                │
        └────────────────┼────────────────┘
                         │
                  AWS / Azure / GCP
                         │
              Observability / Security

Why Backstage?

Backstage is particularly strong for a large organization because it provides the developer experience layer:

• Software/service catalog
• Ownership and dependency information
• Golden-path templates
• Documentation via TechDocs
• Integrations through its plugin architecture
• A single developer-facing interface across many underlying systems

Backstage is explicitly designed as an extensible framework rather than a complete infrastructure automation platform.

The important distinction is that Backstage should be the front door, not the entire house.

Why add an orchestration layer?

This is where many enterprise platform initiatives go wrong.

You can assemble:

• Backstage
• Terraform
• Kubernetes
• Argo CD
• Crossplane
• GitHub/GitLab
• Vault
• cloud APIs
• observability
• policy engines

…and call the resulting collection an IDP.

But then your platform team becomes responsible for maintaining all the glue between them.

A platform orchestrator gives you a layer where platform engineers define things like:

"A production Java service gets an EKS namespace, IAM role, database, secrets, monitoring, deployment pipeline and appropriate policies."

The developer shouldn't have to understand how those 15 things are implemented.

Humanitec's architecture is explicitly built around this separation: developers specify workload requirements while platform engineers control the underlying infrastructure and standards.

Where Humanitec fits

Humanitec is therefore interesting for a large enterprise with a serious platform team.

Its Platform Orchestrator provides a centralized configuration/orchestration layer and integrates with CI/CD and infrastructure providers. Its Score workload specification lets developers describe what their workload needs without encoding all the environment-specific infrastructure details.

I would not, however, automatically buy Humanitec. If your platform team is highly experienced and you have strong requirements for portability/control, you can build this layer yourself.

---

The three choices I'd consider

The key is that Backstage and Humanitec aren't really competitors. A portal and an orchestration layer solve different problems; they can be complementary.

---

What I would build

For a large enterprise, I'd define the platform as six layers:

1. Developer experience

Backstage

Developers should be able to:

• Find services
• See ownership
• See dependencies
• Create a new service
• Create environments
• Deploy
• View operational information
• Find documentation
• Request infrastructure

The goal is one paved road, not "another tool developers have to learn."

2. Golden paths

This is arguably more important than the portal itself.

Examples:

Create REST API
    ↓
Choose Java / Go / Python
    ↓
Repository created
    ↓
CI configured
    ↓
Security scanning configured
    ↓
Container built
    ↓
Dev environment created
    ↓
Observability configured
    ↓
Production deployment available

The developer should not need to understand Kubernetes, Terraform, IAM, networking, or CI/CD internals.

3. Platform orchestration

This is the abstraction between developer intent and infrastructure.

For example:

service:
  type: web-service
  runtime: java
  tier: production

resources:
  database: postgres
  cache: redis

availability:
  tier: critical

The platform translates that into the appropriate:

Kubernetes
+ AWS
+ Terraform
+ IAM
+ networking
+ secrets
+ monitoring
+ CI/CD
+ policies

That's the real magic of an IDP.

4. Infrastructure

I'd generally standardize around:

• Kubernetes where it actually makes sense
• Terraform/OpenTofu for infrastructure
• GitOps for desired state
• Cloud-native services where Kubernetes isn't appropriate
• A consistent secrets/identity architecture

Don't force everything onto Kubernetes simply because you're building a platform.

5. Governance

This is especially important in a large company.

Your platform should enforce:

• Security baselines
• Identity and access
• Network policies
• Encryption
• Approved cloud regions
• Resource tagging
• Cost controls
• Vulnerability scanning
• Compliance requirements
• Production-change policies

The crucial principle is:

Governance should be implemented in the platform, not documented in a wiki.

A golden path that says "please remember to enable encryption" isn't governance.

6. Observability and feedback

Every service should automatically get:

• Logs
• Metrics
• Traces
• SLOs
• Deployment information
• Ownership
• Dependency information
• Security posture

And your platform team should measure whether the platform is actually helping.

---

The organizational part matters more than the technology

If your goal is to build an internal platform engineering team, I'd treat the platform as an internal product.

Your customers are developers.

So establish:

Platform Product Manager

→ owns developer problems and roadmap

Platform Engineering

→ builds the paved roads

Developer Experience

→ owns usability and workflows

SRE/Infrastructure

→ operates the underlying platform

Security

→ provides policy requirements and guardrails

And measure things such as:

• Time to first deployment
• Time to production
• Deployment frequency
• Change failure rate
• Developer onboarding time
• Platform adoption
• Self-service percentage
• Number of tickets eliminated
• Platform availability
• Developer satisfaction

Don't measure success by:

"We deployed Backstage."

Measure it by:

"A new engineering team can deploy a production-ready service in 30 minutes without opening an infrastructure ticket."

---

My strongest recommendation

If you're starting this from scratch, I would not start by implementing Backstage.

I'd start with one golden path.

For example:

"Create and deploy a production-ready REST service."

Make that path ridiculously good.

Then build the platform capabilities required to make it work:

Backstage → orchestration → CI/CD → infrastructure → Kubernetes/cloud → security → observability

Once that path works, add:

1. Databases
2. Async workers
3. Scheduled jobs
4. Data pipelines
5. ML workloads
6. Additional languages/runtimes
7. Specialized infrastructure

This prevents the classic enterprise-IDP failure mode: spending 12 months building a beautiful developer portal that nobody actually uses.

Bottom line

For a large organization, my default architecture would be:

Backstage + platform orchestration + Kubernetes/GitOps + Terraform/OpenTofu + cloud-native infrastructure + centralized identity/policy/observability.

If you want maximum control and have a very strong platform team, build the orchestration layer yourself.

If you want enterprise capability faster and are comfortable with a commercial dependency, I'd evaluate Backstage + Humanitec very seriously.

And I would keep Backstage and the orchestration layer conceptually separate. Backstage is your developer experience/catalog; orchestration is your platform control plane.

If you tell me roughly how many developers/teams you have, cloud(s) you're on (AWS/Azure/GCP/on-prem), Kubernetes vs. non-Kubernetes workloads, and whether you prefer buy vs. build, I can lay out a concrete enterprise IDP reference architecture and 6–12 month implementation roadmap.

In a large organization, there is no single "turnkey" product that acts as a complete Internal Developer Platform (IDP). Instead, enterprise architecture separates an IDP into two distinct layers:

• The Portal Layer (The Front Door): Where developers discover services, read documentation-as-code, browse APIs, and trigger self-service actions.
• The Orchestration / Execution Layer (The Engine Room): Where infrastructure is actually provisioned, configurations are managed, and deployments are executed securely across environments.

For a large-scale enterprise, the gold-standard framework relies on combining a robust Developer Portal with a powerful Platform Orchestrator or Cloud-Native Control Plane.

Phase 1: Choosing Your Portal (The Interface)

• Backstage (Open Source / CNCF)
  • Best For: Large engineering orgs (1,000+ engineers) that want total ownership, deep customization via TypeScript/React, and a massive ecosystem of open-source plugins.
  • Trade-offs: It is a framework , not an out-of-the-box product. You must dedicate a sub-team of engineers to maintain plugins, manage breaking updates, and build out the initial scaffolding.
  • Enterprise Alternative: If you want Backstage capabilities without self-hosting and maintaining the infrastructure burden, look at enterprise-managed distributions like Red Hat Developer Hub or commercial managed options like Roadie.
• Port (Commercial / No-Code Portal)
  • Best For: Large enterprises that want a production-ready, highly customizable catalog and action engine in weeks rather than spending 6 months coding a custom Backstage instance.
  • Trade-offs: It is a paid SaaS/commercial tool, meaning recurring vendor costs and reliance on their ecosystem data models.

Phase 2: Choosing Your Orchestrator (The Execution Layer)

A portal alone won't deploy code; you need an underlying execution engine.

• Humanitec (Platform Orchestrator)
  • Best For: Enterprises implementing Dynamic Configuration Management (DCM) using the open Score specification . It abstracts Terraform and Kubernetes manifests so developers deploy environment-agnostic configs that the orchestrator translates to your specific cloud infrastructure.
• Crossplane (CNCF Open Source Control Plane)
  • Best For: Cloud-native and Kubernetes-heavy enterprises that want to turn Kubernetes into a universal control plane using Custom Resource Definitions (CRDs) to provision infrastructure across AWS, GCP, or Azure.
• The "BACK Stack" Pattern: A heavily favored open-source enterprise architecture combining Backstage (Portal) + Argo CD (GitOps Delivery) + Crossplane (Infrastructure Provisioning) + Kyverno (Policy Enforcement).

Recommended Strategy for Large Organizations

1. Adopt a decoupled approach: Do not try to buy a single tool that does everything. Pair an interface portal (Backstage or Port ) with a robust backend orchestrator (Humanitec or Crossplane).
2. Treat the platform as a product: Survey your internal application engineering teams first to find their primary bottlenecks (e.g., slow environment creation, lack of service ownership, or painful CI/CD pipelines) rather than forcing top-down tooling they won't adopt.
3. Start small with one "Golden Path": Focus your initial framework on solving one painful workflow end-to-end—such as "scaffolding a microservice and deploying it to a staging environment in under 10 minutes"—before expanding the scope.

To help narrow down the exact framework blueprint for your company, let me know:

• What is the approximate size of your engineering organization?
• Is your infrastructure primarily Kubernetes/Cloud-Native , or a mix of legacy/VM/multi-cloud?
• Do you prefer an open-source-first approach with dedicated maintenance headcount, or a commercial/managed solution for faster time-to-value?