Stage 7 · Master
Advanced Topics & Future of Platform Engineering
Platform Engineering at Scale
1000+ developers, 10000+ services. Platform team structure: platform PM, UX, reliability, security, data. Inner source model.
Scale Challenges
| Challenge | 100 Devs | 1000 Devs | 10000 Devs |
|---|---|---|---|
| Platform Team Size | 3-5 | 15-30 | 50-100+ |
| Services | 50-100 | 1000-3000 | 10000+ |
| Clusters | 1-3 | 10-50 | 100+ |
| Cloud Providers | 1 | 1-2 | 3+ |
| Golden Paths | 1-2 | 5-10 | 20+ |
| Policy Rules | 10-20 | 100-200 | 500+ |
| On-Call Rotation | 1 team | 3-5 teams | Dedicated SRE + platform |
| Governance | Informal | Structured | Automated + committee |
| Inner Source | Ad-hoc | Structured program | Platform as product |
At scale, platform team cannot build every feature request. Must enable inner source: teams contribute to platform, platform team reviews/merges. Platform team becomes product managers of the platform product.
Platform Team Structure
| Sub-Team | Focus | Size (1000 devs) | Size (1000 devs) | Key Roles |
|---|---|---|---|---|
| Core Platform | API, CLI, Portal, Scaffolder | 6-8 | Backend, Frontend, UX, PM | |
| Compute | K8s, CAPI, Cluster lifecycle, Autoscaling | 4-6 | K8s experts, CAPI maintainers | |
| Data Platform | Databases, Streaming, ML features, Warehousing | 4-6 | DBAs, Data engineers, ML platform | |
| Security | Policy, Secrets, Supply chain, Compliance | 3-4 | Security engineers, Policy authors | |
| Observability | Metrics, Logs, Traces, Profiling, Alerting | 3-4 | Observability engineers, SRE | |
| Developer Experience | CLI, Portal, Local dev, Feedback loops | 3-4 | Frontend, UX, Technical writers | |
| Reliability | Platform SLIs, Incident response, Game days | 2-3 | SRE, Incident commanders | |
| FinOps | Cost allocation, Optimization, Budgets | 2-3 | FinOps analysts, Cloud economists |
Each sub-team owns a platform capability end-to-end: API, implementation, documentation, runbooks, SLIs. They collaborate via RFC process, shared design docs, quarterly planning.
Inner Source Model
Inner source = open source practices inside the company. Stream-aligned teams contribute to platform: bug fixes, new capabilities, golden path improvements. Platform team reviews, merges, maintains.
| Aspect | Traditional | Inner Source |
|---|---|---|
| Contribution | Ticket to platform team | PR to platform repo |
| Prioritization | Platform team decides | Community + platform PM |
| Review | Platform team only | Platform team + community |
| Ownership | Platform team owns all | Contributor owns feature |
| Documentation | Platform team writes | Contributor writes, platform reviews |
| Testing | Platform team tests | Contributor tests, platform gates |
| Release | Platform team releases | Automated via platform CI/CD |
| Support | Platform team supports | Contributor + platform on-call |
# Contributing to the Platform
## Ways to Contribute
1. **Bug Fix**: Fix a bug in platform API, CLI, portal, controller
2. **Feature**: Add new capability to golden path, new template, new policy
3. **Documentation**: Improve docs, add runbook, add example
4. **Policy**: Add new policy rule, fix false positive, improve message
5. **Testing**: Add unit/integration tests, improve coverage
## Process
1. **Check Existing**: Search issues/PRs for duplicates
2. **Open Issue**: Describe problem, proposed solution, impact
3. **Design Doc** (for features): Write RFC, get feedback
5. **Implement**: Fork, branch, code, test, document
6. **PR**: Link issue, add tests, update docs, request review
7. **Review**: Platform team + 1 community reviewer
8. **Merge**: Auto-merge after approvals + CI pass
## Contribution Areas
| Area | Repo | Maintainers | Good First Issues |
|------|------|-------------|-------------------|
| Platform API | platform/api | @platform-core | #123, #456 |
| CLI | platform/cli | @platform-cli | #789 |
| Portal | platform/portal | @platform-ux | #101 |
| Golden Paths | platform/templates | @platform-templates | #202 |
| Policies | platform/policies | @platform-security | #303 |
| Controllers | platform/controllers | @platform-compute | #404 |
## Recognition
- Contributor badge in portal profile
- Monthly "Top Contributor" announcement
- Annual platform contributor summit
- Swag for 5+ merged PRs
Inner source guide: how to contribute, process, areas, recognition. Lowers barrier, increases platform velocity.
Platform Federation
At very large scale (5000+ devs), single platform team becomes bottleneck. Federate: core platform team + domain platform teams (payments platform, identity platform, ML platform). Core provides shared infrastructure; domains provide domain-specific capabilities.
| Model | Core Platform | Domain Platforms | Best For |
|---|---|---|---|
| Centralized | All capabilities | None | <500 devs, simple domain |
| Federated | Shared: API, Portal, Auth, Policy, Observability, CI/CD | Domain-specific: ML platform, Data platform, Payments platform | 500-5000 devs, distinct domains |
| Decentralized | Minimal: Auth, Policy, Catalog | Full platform per domain | >5000 devs, highly autonomous |
Governance at Scale
- Platform Council: Monthly meeting of sub-team leads + PM + architect. Decides: architecture, standards, priorities
- RFC Process: All significant changes (new capability, breaking change, new policy) go through RFC. 2-week comment period
- Architecture Review Board: Quarterly review of platform architecture, tech debt, strategic direction
- Policy Council: Security, compliance, data leads review new policies. Approve/reject with rationale
- Exception Process: Formal exception requests with expiration, owner, migration plan. Tracked in portal
- Deprecation Policy: 18-month support, 6-month notice, migration tooling, communication plan
- Vendor Review: Quarterly review of cloud/vendor contracts, pricing, alternatives
Metrics at Scale
| Metric Category | Metrics | Frequency | Audience |
|---|---|---|---|
| Platform Health | API latency, error rate, availability, scaffold success | Real-time | Platform team, on-call |
| Developer Productivity | Lead time, deploy freq, change failure, MTTR, scaffold-to-deploy | Daily/Weekly | Platform PM, engineering leads |
| Adoption | Golden path %, template usage, API calls, portal DAU | Weekly | Platform PM, exec |
| DX | NPS, in-app feedback sentiment, friction log score | Quarterly | Platform PM, exec |
| Cost | Per-team/service cost, budget burn, optimization savings | Daily/Monthly | FinOps, team leads, exec |
| Reliability | Platform SLIs, error budget burn, MTTR, incident count | Real-time | Platform team, SRE |
| Inner Source | PRs from community, time-to-merge, contributor count | Monthly | Platform PM, community |
At scale, platform is a portfolio of products (API, CLI, Portal, Templates, Policies, Controllers). Each has: PM, UX, eng, SLIs, roadmap, budget. Platform PM becomes portfolio manager.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.