[Reference Architecture] Internal Developer Platform for Cloud-Native Applications at The New York Times

### Name

Internal Developer Platform for Cloud-Native Applications at The New York Times

### Organization

The New York Times Company

### Team(s)

Developer Platforms

### Overview and Goals

This reference architecture describes The New York Times' internal developer platform that provides a standardized, multi-tenant Kubernetes-based environment for building, deploying, and operating cloud-native applications.

**The platform's goals are to:**

- **Reduce infrastructure and security complexity** for product teams by offering a managed runtime and paved paths.
- **Centralize cross-cutting concerns** such as networking, traffic management, and web application firewall, while preserving team autonomy.
- **Provide opinionated CI/CD and GitOps workflows** so teams can safely deploy frequently.
- **Integrate observability and progressive delivery** so teams gain clear application and deployment health signals and can confidently remediate issues.

This architecture is relevant to the wider community as an example of how a large media organization builds an internal developer platform on Kubernetes and CNCF projects to serve diverse product teams, while balancing central standards with flexibility.

### Projects

Deployment, Continuous Delivery & Rollout

Project | Role
-- | --
Argo CD | Primary GitOps-based continuous delivery engine; manages application deployments and cluster add-ons via Applications and ApplicationSets
Argo Rollouts | Progressive delivery for canary, blue/green, and traffic-shaped rollouts with service mesh integration and metrics-driven analysis
Helm | Core deployment abstraction; all platform workloads deploy via standardized Helm charts synced through Argo CD
KEDA | Event-driven and cron-based autoscaling on top of HPA for traffic spikes and breaking-news scenarios

Runtime Platform, Networking & Cluster Infrastructure

Project | Role
-- | --
Kubernetes | Core orchestration layer; shared multi-tenant clusters serving as the platform runtime
Istio / Envoy | Service mesh providing mTLS, L4/L7 traffic policy, and telemetry; evolving toward Istio Ambient mode
Cilium | eBPF-based CNI providing pod networking and network policy enforcement for tenant isolation
CoreDNS | Cluster DNS service, actively maintained and instrumented with dedicated monitoring
Karpenter | Cluster autoscaling for tenant node pools, including ARM-based compute pools, tuned via GitOps

Observability & Telemetry

Project | Role
-- | --
OpenTelemetry | Strategic observability standard; platform-provided wrapper libraries for Go, Java, Python, and TypeScript expose OTel APIs as the golden path for tracing, metrics, and logs
OpenTelemetry Collector | Managed collector service running on platform clusters, providing a centralized telemetry pipeline between workloads and observability backends
Prometheus | Metrics collection and autoscaling signals, including shared workspaces for event-driven scaling scenarios

Security, Policy & Identity

Project | Role
-- | --
OPA Gatekeeper | Kubernetes policy enforcement across tenant namespaces; enforces controls such as resource limits and security baselines
Kubernetes Network Policies (via Cilium) | Namespace-scoped isolation for tenants with default-deny posture and tenant-specific allow-lists
cert-manager | Cluster PKI and ACME certificate lifecycle management for ingress, webhooks, and internal services

### Planned Evolution

Planned evolution of this architecture focuses on several areas:

1. **Broader Workload Support** — Expanding beyond containerized web services to include tighter integration patterns for serverless workloads within the same governance, observability, and deployment experience.

2. **AI/ML and API Gateway Patterns** — Standardizing how teams expose and operate AI-related and other latency-sensitive APIs on the platform, including reference implementations for AI gateways deployed on the shared clusters.

3. **Observability-Driven Operations** — Deepening integration between deployment workflows and observability systems to enable safer progressive delivery, automated rollback triggers, and clearer platform-wide status visibility for tenants.

4. **Unified Authentication and Multi-Tenant Governance** — Continuing to strengthen unified authentication and authorization across platform components and tenant services, while refining network policy and service identity models.

5. **Adoption and Migration Pathways** — Codifying migration patterns, templates, and engagement models that help additional business domains move to the platform more predictably and at scale.