Repository navigation
Expand file tree
/
Copy pathroadmapData.js
More file actions
838 lines (838 loc) · 72.6 KB
/
Copy pathroadmapData.js
File metadata and controls
838 lines (838 loc) · 72.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
export const roadmapData = {
title: "Platform Engineering Roadmap",
description: "An opinionated roadmap to become a Platform Engineer",
image: "platform-engineering-inferno.jpg",
sections: [
{
id: "individual",
title: "Individual Skills",
description: "Core technical skills every Platform Engineer should master",
topics: [
{
id: "yaml",
title: "YAML",
description: "YAML fundamentals - it's everywhere in platform engineering",
content: "YAML (not even kidding you have to learn YAML. It's everywhere and it is the first thing to learn). From Kubernetes manifests to CI/CD pipelines, YAML is the de facto configuration language in cloud-native environments.",
links: [
{ title: "YAML Official Spec", url: "https://yaml.org/spec/" },
{ title: "YAML Tutorial", url: "https://www.tutorialspoint.com/yaml/index.htm" },
{ title: "Learn YAML in Y minutes", url: "https://learnxinyminutes.com/docs/yaml/" },
{ title: "YAML Lint - Online Validator", url: "https://www.yamllint.com/" }
],
subtopics: [
{ name: "YAML Syntax & Structure", description: "Understanding indentation, lists, maps, and anchors" },
{ name: "Multi-document YAML", description: "Working with multiple documents in a single file" },
{ name: "YAML vs JSON vs TOML", description: "Comparing configuration formats" }
]
},
{
id: "programming",
title: "Programming",
description: "Programming languages and development skills",
content: "Programming languages (Python, Golang, Typescript) - you don't necessarily need to be a master at these but it helps a ton. These languages are commonly used for automation, tooling, and building platform services.",
links: [
{ title: "Python.org", url: "https://python.org" },
{ title: "Go Documentation", url: "https://golang.org/doc/" },
{ title: "TypeScript Handbook", url: "https://www.typescriptlang.org/docs/" },
{ title: "Exercism - Practice Coding", url: "https://exercism.org/" },
{ title: "Pro Git Book", url: "https://git-scm.com/book/en/v2" },
{ title: "Git Branching Tutorial", url: "https://learngitbranching.js.org/" },
{ title: "Rust for Platform Engineering", url: "https://www.rust-lang.org/learn" }
],
subtopics: [
{ name: "Python", description: "Automation, scripting, and tooling - most common for DevOps/Platform" },
{ name: "Golang", description: "Building CLIs, operators, and high-performance tools (Kubernetes ecosystem)" },
{ name: "TypeScript/JavaScript", description: "Frontend for developer portals and internal tooling" },
{ name: "Rust", description: "Systems programming and high-performance infrastructure tools" },
{ name: "Version control (Git)", description: "Essential for code management and collaboration" },
{ name: "SDKs and APIs", description: "Software Development Kits for cloud providers and platforms" },
{ name: "Code review practices", description: "Reviewing code effectively and providing constructive feedback" }
]
},
{
id: "linux",
title: "Linux",
description: "Linux system administration and scripting",
content: "Essential Linux skills for managing infrastructure and automation. Understanding the operating system that powers most cloud infrastructure is fundamental.",
links: [
{ title: "Linux Documentation", url: "https://www.kernel.org/doc/html/latest/" },
{ title: "Bash Guide", url: "https://mywiki.wooledge.org/BashGuide" },
{ title: "Linux Journey", url: "https://linuxjourney.com/" },
{ title: "The Linux Command Line Book", url: "https://linuxcommand.org/tlcl.php" },
{ title: "OverTheWire Bandit - Linux Practice", url: "https://overthewire.org/wargames/bandit/" },
{ title: "Systemd Documentation", url: "https://systemd.io/" },
{ title: "Linux Foundation Training", url: "https://training.linuxfoundation.org/" }
],
subtopics: [
{ name: "Bash scripting", description: "Automation and task scripting" },
{ name: "Navigating the filesystem", description: "File system operations and navigation" },
{ name: "Memory & disk management", description: "Understanding and manipulating RAM and storage" },
{ name: "Process management", description: "ps, top, htop, kill, and process lifecycle" },
{ name: "cgroups and namespaces", description: "Foundation of containerization and resource isolation" },
{ name: "systemd", description: "Service management and init system" },
{ name: "Security (SELinux/AppArmor)", description: "Mandatory Access Control systems" },
{ name: "Package management", description: "apt, yum, dnf, rpm - managing software packages" },
{ name: "Networking tools", description: "netstat, ss, tcpdump, iptables, nftables" }
]
},
{
id: "network",
title: "Network",
description: "Networking protocols and infrastructure",
content: "Network fundamentals, protocols, and troubleshooting for distributed systems. Networking knowledge is crucial for designing and debugging cloud-native applications.",
links: [
{ title: "HTTP/2 Specification", url: "https://tools.ietf.org/html/rfc7540" },
{ title: "HTTP/3 Explained", url: "https://http3-explained.haxx.se/" },
{ title: "Computer Networking Course (Free)", url: "https://www.youtube.com/playlist?list=PLEbnTDJUr_IegfoqO4iPnPYQui46QqT0j" },
{ title: "DNS for Developers", url: "https://www.nslookup.io/learning/" },
{ title: "Cloudflare Learning Center", url: "https://www.cloudflare.com/learning/" },
{ title: "High Performance Browser Networking", url: "https://hpbn.co/" }
],
subtopics: [
{ name: "TCP/IP vs UDP", description: "Transport layer protocols and use cases" },
{ name: "HTTP/1.1 vs HTTP/2 vs HTTP/3", description: "Web protocols evolution and performance" },
{ name: "TLS/SSL & mTLS", description: "Transport Layer Security and mutual TLS" },
{ name: "DNS", description: "Domain Name System - resolution, records, and troubleshooting" },
{ name: "SSH", description: "Secure Shell protocol and key management" },
{ name: "DHCP & IPAM", description: "IP address management" },
{ name: "Firewalls (iptables, nftables)", description: "Network security and filtering" },
{ name: "OSI & TCP/IP models", description: "Network layer models" },
{ name: "Network topologies", description: "Network design patterns" },
{ name: "Load Balancing (L4 vs L7)", description: "Traffic distribution strategies" },
{ name: "Proxy and reverse-proxy", description: "Traffic intermediaries and use cases" },
{ name: "VPN & Network tunneling", description: "Secure network connectivity" },
{ name: "Service discovery", description: "Finding services in distributed systems" }
]
},
{
id: "distributed-systems",
title: "Distributed Systems",
description: "Distributed systems architecture and data stores",
content: "Understanding distributed systems, queues, APIs, caching, and databases. These concepts are fundamental for building scalable and reliable platforms.",
links: [
{ title: "Apache Kafka", url: "https://kafka.apache.org/" },
{ title: "Valkey (Redis fork)", url: "https://valkey.io/" },
{ title: "Designing Data-Intensive Applications", url: "https://dataintensive.net/" },
{ title: "CAP Theorem Explained", url: "https://www.ibm.com/topics/cap-theorem" },
{ title: "Martin Kleppmann's Blog", url: "https://martin.kleppmann.com/" },
{ title: "Distributed Systems Course (MIT)", url: "https://pdos.csail.mit.edu/6.824/" },
{ title: "System Design Primer", url: "https://github.com/donnemartin/system-design-primer" },
{ title: "gRPC Documentation", url: "https://grpc.io/docs/" }
],
subtopics: [
{ name: "Message Queues & Event Streaming", description: "Kafka, RabbitMQ, NATS, Pulsar" },
{ name: "Event Log vs Message Queue", description: "Understanding the architectural differences" },
{ name: "Load Balancers (Layer 4 vs Layer 7)", description: "Traffic distribution strategies" },
{ name: "REST APIs", description: "RESTful service architecture and best practices" },
{ name: "Microservices architecture", description: "Distributed service design patterns, pros and cons" },
{ name: "GraphQL", description: "Query language for APIs" },
{ name: "gRPC & Protocol Buffers", description: "High-performance RPC framework" },
{ name: "Caching strategies", description: "Redis, Memcached, Valkey, and caching patterns" },
{ name: "CDN concepts", description: "Content delivery networks and edge computing" },
{ name: "Database types", description: "NoSQL, Relational, Graph, Vector, Column-oriented" },
{ name: "ACID principles", description: "Atomicity, Consistency, Isolation, Durability" },
{ name: "CAP Theorem", description: "Consistency, Availability, Partition tolerance trade-offs" },
{ name: "Consensus algorithms", description: "Raft, Paxos - distributed agreement" },
{ name: "Eventual consistency", description: "Understanding distributed data patterns" }
]
},
{
id: "data-recovery",
title: "Data Services & Recovery",
description: "Database operations, backups, and tested disaster recovery",
content: "A platform's data services need more than a persistent volume and a healthy replica. Choose managed services or database operators according to recovery objectives, consistency needs, and the team's ability to operate them. Replication can copy accidental deletion and corruption; it is not a substitute for independent backups. Prove recovery by restoring data, verifying application behavior, and measuring the time and data loss against agreed objectives.",
links: [
{ title: "Google SRE: Data Integrity", url: "https://sre.google/sre-book/data-integrity/" },
{ title: "PostgreSQL Continuous Archiving & PITR", url: "https://www.postgresql.org/docs/current/continuous-archiving.html" },
{ title: "CloudNativePG Backup Concepts", url: "https://cloudnative-pg.io/docs/current/backup/" },
{ title: "Velero Backup & Restore", url: "https://velero.io/docs/" }
],
subtopics: [
{ name: "Managed vs Self-managed Data Services", description: "Compare patching, failover, backup, support, cost, and operational ownership before choosing a service or operator" },
{ name: "Storage & Data Semantics", description: "Distinguish block, file, and object storage from database transactions, durability, and application consistency" },
{ name: "Replication & Writer Fencing", description: "Understand replication lag, synchronous trade-offs, read routing, and preventing an old primary from writing after failover" },
{ name: "Consistent Backups", description: "Use engine-supported backups; volume snapshots and Kubernetes object backups alone do not guarantee application-consistent recovery" },
{ name: "Point-in-Time Recovery (PITR)", description: "Combine recoverable base backups with continuous WAL or binlog archives and verify the required recovery window" },
{ name: "Recovery Objectives", description: "Agree on recovery point objective (RPO) for acceptable data loss and recovery time objective (RTO) for service restoration" },
{ name: "Restore Drills", description: "Restore into an isolated environment and verify integrity, permissions, application queries, and measured recovery time" },
{ name: "Regional Recovery & Failback", description: "Plan destination capacity, credentials, encryption keys, traffic cutover, writer fencing, and a tested return to normal operation" },
{ name: "Safe Database Changes", description: "Test engine upgrades and expand-contract schema migrations; bound backfill load, lock time, and connection growth" },
{ name: "Backup Protection & Retention", description: "Separate backup access from production administration, protect copies from deletion, and retain the keys and metadata needed to restore" }
]
},
{
id: "devops",
title: "DevOps",
description: "DevOps practices, cloud platforms, and automation",
content: "DevOps culture, cloud services, CI/CD, and Infrastructure as Code. Platform Engineering evolved from DevOps, understanding these foundations is essential.",
links: [
{ title: "DevOps Handbook", url: "https://itrevolution.com/product/the-devops-handbook-second-edition/" },
{ title: "OpenTofu Documentation", url: "https://opentofu.org/docs/" },
{ title: "Terraform Documentation", url: "https://www.terraform.io/docs/" },
{ title: "Ansible Documentation", url: "https://docs.ansible.com/" },
{ title: "GitOps Principles", url: "https://opengitops.dev/" },
{ title: "ArgoCD Documentation", url: "https://argo-cd.readthedocs.io/" },
{ title: "FluxCD Documentation", url: "https://fluxcd.io/docs/" },
{ title: "Continuous Delivery Book", url: "https://continuousdelivery.com/" },
{ title: "Pulumi Documentation", url: "https://www.pulumi.com/docs/" }
],
subtopics: [
{ name: "DevOps Culture", description: "Culture over tools, feedback loops, continuous improvement" },
{ name: "Cloud Service Models", description: "SaaS, PaaS, IaaS, FaaS - understanding the stack" },
{ name: "Serverless", description: "Knative, OpenFaaS, and serverless patterns" },
{ name: "CI/CD Pipelines", description: "Continuous integration and deployment principles" },
{ name: "GitOps", description: "Git-based operations with ArgoCD, FluxCD" },
{ name: "Infrastructure as Code", description: "OpenTofu, Terraform, Pulumi, Crossplane" },
{ name: "Configuration Management", description: "Ansible, Puppet, Chef - system automation" },
{ name: "Cloud Providers", description: "AWS, GCP, Azure, and multi-cloud strategies" },
{ name: "Version Control Platforms", description: "GitHub, GitLab, Bitbucket" },
{ name: "Secrets Management", description: "HashiCorp Vault, SOPS, Sealed Secrets" },
{ name: "Environment Management", description: "Dev, staging, production - isolation and promotion" },
{ name: "Multitenancy", description: "Single vs multi-tenant architectures" }
]
},
{
id: "rollout",
title: "Rollout Strategies",
description: "Deployment patterns and release management",
content: "Various deployment strategies for safe and reliable software releases. Understanding these patterns is crucial for reducing deployment risk and enabling continuous delivery.",
links: [
{ title: "Blue-Green Deployment", url: "https://martinfowler.com/bliki/BlueGreenDeployment.html" },
{ title: "Canary Releases", url: "https://martinfowler.com/bliki/CanaryRelease.html" },
{ title: "Feature Flags Best Practices", url: "https://launchdarkly.com/blog/feature-flag-best-practices/" },
{ title: "Progressive Delivery", url: "https://www.split.io/glossary/progressive-delivery/" },
{ title: "Argo Rollouts", url: "https://argoproj.github.io/rollouts/" },
{ title: "Flagger", url: "https://flagger.app/" }
],
subtopics: [
{ name: "Blue-Green Deployment", description: "Two identical production environments" },
{ name: "Canary Releases", description: "Gradual rollout to subset of users" },
{ name: "Progressive Delivery", description: "Incremental feature rollout with automated analysis" },
{ name: "Shadow/Dark Launches", description: "Testing with production traffic without user impact" },
{ name: "Feature Flags", description: "Runtime feature toggling and experimentation" },
{ name: "A/B Testing", description: "Comparing different versions with user segments" },
{ name: "Bake Time", description: "Monitoring period after deployment" },
{ name: "Rollback strategies", description: "Fast and safe rollback mechanisms" },
{ name: "Traffic shifting", description: "Weighted routing between versions" }
]
},
{
id: "observability",
title: "Observability",
description: "Monitoring, logging, and observability practices",
content: "Comprehensive observability including metrics, logs, traces, and alerting. Platform engineers must ensure platforms are observable and issues are quickly diagnosed.",
links: [
{ title: "OpenTelemetry", url: "https://opentelemetry.io/" },
{ title: "Prometheus", url: "https://prometheus.io/" },
{ title: "Grafana", url: "https://grafana.com/docs/" },
{ title: "Observability Engineering Book", url: "https://www.oreilly.com/library/view/observability-engineering/9781492076438/" },
{ title: "SLO Guide", url: "https://sre.google/workbook/implementing-slos/" },
{ title: "Jaeger Tracing", url: "https://www.jaegertracing.io/" },
{ title: "Loki Log Aggregation", url: "https://grafana.com/oss/loki/" },
{ title: "DORA Metrics", url: "https://dora.dev/guides/dora-metrics-four-keys/" }
],
subtopics: [
{ name: "Telemetry vs Monitoring vs Observability", description: "Understanding the differences and evolution" },
{ name: "Three Pillars: Metrics, Logs, Traces", description: "Foundation of observability" },
{ name: "OpenTelemetry (OTEL)", description: "Vendor-neutral observability framework" },
{ name: "Prometheus & PromQL", description: "Metrics collection and querying" },
{ name: "Grafana", description: "Visualization and dashboarding" },
{ name: "Distributed Tracing", description: "Jaeger, Zipkin, Tempo" },
{ name: "Log Management", description: "Aggregation, retention, analysis" },
{ name: "APM concepts", description: "Application Performance Monitoring" },
{ name: "SLIs, SLOs, SLAs", description: "Service level indicators, objectives, agreements" },
{ name: "Alerting strategies", description: "ChatOps, on-call, slow vs fast burn alerts" },
{ name: "DORA Metrics", description: "Deployment frequency, lead time, MTTR, change failure rate" },
{ name: "Error budgets", description: "Balancing reliability and velocity" }
]
},
{
id: "security",
title: "Security",
description: "Security practices and tools for platform engineering",
content: "Security fundamentals including encryption, authentication, and DevSecOps. Security must be embedded into platform design from the start.",
links: [
{ title: "OWASP", url: "https://owasp.org/" },
{ title: "CIS Benchmarks", url: "https://www.cisecurity.org/cis-benchmarks" },
{ title: "NIST Cybersecurity Framework", url: "https://www.nist.gov/cyberframework" },
{ title: "Open Policy Agent", url: "https://www.openpolicyagent.org/" },
{ title: "Kyverno", url: "https://kyverno.io/" },
{ title: "Falco", url: "https://falco.org/" },
{ title: "Trivy Container Scanner", url: "https://trivy.dev/" },
{ title: "Supply Chain Security (SLSA)", url: "https://slsa.dev/" },
{ title: "Sigstore", url: "https://www.sigstore.dev/" }
],
subtopics: [
{ name: "Encryption", description: "Algorithms, certificates, TLS, PKI" },
{ name: "Authentication & Authorization", description: "AuthN vs AuthZ, OAuth, OIDC, SAML" },
{ name: "Zero Trust Architecture", description: "Never trust, always verify" },
{ name: "IAM", description: "Identity and Access Management principles" },
{ name: "RBAC & ABAC", description: "Role and Attribute-based access control" },
{ name: "DevSecOps", description: "Security in development lifecycle (Shift Left)" },
{ name: "SAST & DAST", description: "Static and Dynamic Application Security Testing" },
{ name: "Container & Image Scanning", description: "Trivy, Grype, vulnerability detection" },
{ name: "Policy as Code", description: "OPA, Kyverno, Gatekeeper" },
{ name: "Runtime Security", description: "Falco, threat detection" },
{ name: "Supply Chain Security", description: "SBOM, SLSA, Sigstore, image signing" },
{ name: "Secrets Management", description: "Vault, External Secrets, Sealed Secrets" },
{ name: "Network Security", description: "Network policies, mTLS, service mesh security" },
{ name: "CNAPP", description: "Cloud Native Application Protection Platform" }
]
},
{
id: "site-reliability",
title: "Site Reliability",
description: "Site reliability engineering practices",
content: "SRE practices including scalability, rate limiting, and chaos engineering. Platform engineers often work closely with SRE teams or adopt SRE principles.",
links: [
{ title: "SRE Book (Google)", url: "https://sre.google/books/" },
{ title: "SRE Workbook", url: "https://sre.google/workbook/table-of-contents/" },
{ title: "SLIs, SLOs & SLAs Explained", url: "https://sre.google/sre-book/service-level-objectives/" },
{ title: "Implementing SLOs & Error Budgets", url: "https://sre.google/workbook/implementing-slos/" },
{ title: "Incident Command & Coordination", url: "https://sre.google/sre-book/managing-incidents/" },
{ title: "OpenTelemetry Logs", url: "https://opentelemetry.io/docs/concepts/signals/logs/" },
{ title: "OpenTelemetry Metrics", url: "https://opentelemetry.io/docs/concepts/signals/metrics/" },
{ title: "OpenTelemetry Traces", url: "https://opentelemetry.io/docs/concepts/signals/traces/" },
{ title: "Chaos Engineering Principles", url: "https://principlesofchaos.org/" },
{ title: "Chaos Monkey (Netflix)", url: "https://netflix.github.io/chaosmonkey/" },
{ title: "LitmusChaos", url: "https://litmuschaos.io/" },
{ title: "Gremlin", url: "https://www.gremlin.com/community/tutorials/" },
{ title: "Availability Calculator", url: "https://availability.sre.xyz/" }
],
subtopics: [
{ name: "SRE vs DevOps", description: "Understanding the relationship and differences" },
{ name: "Service Level Indicators (SLIs)", description: "Measure user-visible outcomes such as successful-request rate, latency, and freshness, with explicit measurement scope and telemetry coverage" },
{ name: "Service Level Objectives (SLOs)", description: "Set a target for an SLI over a defined measurement window; use the corresponding error budget to guide reliability and release decisions" },
{ name: "Service Level Agreements (SLAs)", description: "Define agreed service commitments, measurement rules, and consequences for breaches, such as service credits; distinguish these from internal SLOs" },
{ name: "Logs", description: "Use timestamped, structured logs with severity and service context; correlate trace and span IDs, define retention, and redact sensitive data" },
{ name: "Metrics", description: "Measure service behavior with counters, gauges, and histograms; track traffic, errors, latency, and saturation while bounding label cardinality for SLIs and alerting" },
{ name: "Traces", description: "Follow distributed requests through related spans, propagate context across service and async boundaries, and account for sampling when diagnosing latency and failures" },
{ name: "Hard vs Soft Dependencies", description: "System dependency classification" },
{ name: "Scalability patterns", description: "Horizontal vs vertical scaling" },
{ name: "Rate Limiting", description: "Traffic flow control and protection" },
{ name: "Circuit Breakers", description: "Preventing cascade failures" },
{ name: "Bulkhead pattern", description: "Isolating failures" },
{ name: "Throughput & Latency", description: "System performance metrics" },
{ name: "Chaos Engineering", description: "Resilience testing practices" },
{ name: "Game Days", description: "Structured chaos experiments" },
{ name: "Incident Command", description: "Assign one incident commander to coordinate mitigation, delegate operations, communications and timeline roles, manage escalation, and hand over command explicitly" },
{ name: "Incident Management", description: "Response, communication, post-mortems" },
{ name: "On-call practices", description: "Effective on-call rotations and runbooks" },
{ name: "Toil reduction", description: "Automating repetitive operational work" }
]
},
{
id: "platform-testing",
title: "Platform Testing",
description: "Testing infrastructure, platform APIs, policies, and golden paths",
content: "Platform changes deserve the same testing discipline as application changes. Validate small units and contracts quickly, then exercise the real provisioning, deployment, and recovery paths in isolated environments. A valid manifest or successful plan does not prove that a developer can use the platform. Test failures and denied operations as well as the happy path, use synthetic data, and verify that temporary resources are removed.",
links: [
{ title: "OpenTofu Test Command", url: "https://opentofu.org/docs/cli/commands/test/" },
{ title: "OPA Policy Testing", url: "https://www.openpolicyagent.org/docs/policy-testing" },
{ title: "Kyverno Chainsaw", url: "https://kyverno.github.io/chainsaw/latest/" },
{ title: "Pact Contract Testing", url: "https://docs.pact.io/" }
],
subtopics: [
{ name: "Test Layers", description: "Combine fast unit and schema checks with integration, contract, and end-to-end tests rather than relying on one expensive suite" },
{ name: "Infrastructure as Code Testing", description: "Check plans and module assertions, then verify real resources in disposable accounts or clusters with bounded cost and cleanup" },
{ name: "Policy & Admission Tests", description: "Exercise allowed, denied, malformed, and exception cases for OPA, Kyverno, and other guardrails" },
{ name: "API Contract Testing", description: "Verify request, response, error, and event compatibility between platform APIs and their consumers" },
{ name: "Golden-path End-to-end Tests", description: "Exercise scaffolding, provisioning, deployment, observability, and teardown from a developer's point of view" },
{ name: "Upgrade & Migration Tests", description: "Test supported version combinations, existing workloads, data migrations, and documented rollback limits" },
{ name: "Load & Failure Testing", description: "Measure latency, saturation, rate limits, dependency failures, and recovery under bounded synthetic workloads" },
{ name: "Ephemeral Test Environments", description: "Use synthetic fixtures, scoped credentials, resource budgets, expiry, and verified cleanup even when tests fail" },
{ name: "Post-deployment Verification", description: "Use safe synthetic checks and service objectives to detect regressions after promotion without exposing customer data" }
]
},
{
id: "ai-ml-fundamentals",
title: "AI & ML Fundamentals",
description: "AI and machine learning basics for platform and SRE work",
content: "AI and ML are becoming part of operational tooling, incident response, capacity planning, developer experience, and platform automation. Platform engineers do not need to become research scientists, but they should understand enough to evaluate models, data, risks, and failure modes.",
links: [
{ title: "Google Machine Learning Crash Course", url: "https://developers.google.com/machine-learning/crash-course" },
{ title: "Hugging Face Learn", url: "https://huggingface.co/learn" },
{ title: "Full Stack Deep Learning", url: "https://fullstackdeeplearning.com/" },
{ title: "Made With ML", url: "https://madewithml.com/" },
{ title: "NIST AI Risk Management Framework", url: "https://www.nist.gov/itl/ai-risk-management-framework" }
],
subtopics: [
{ name: "ML fundamentals", description: "Supervised learning, unsupervised learning, model training, inference, and evaluation" },
{ name: "LLM fundamentals", description: "Tokens, context windows, embeddings, temperature, latency, and cost trade-offs" },
{ name: "Data quality", description: "Freshness, labeling, bias, drift, and noisy operational data" },
{ name: "Feature engineering", description: "Turning telemetry, incidents, deploys, and topology into model-ready signals" },
{ name: "Model evaluation", description: "Precision, recall, hallucination checks, regression tests, and human review" },
{ name: "MLOps basics", description: "Model lifecycle, versioning, deployment, monitoring, rollback, and governance" },
{ name: "Responsible AI", description: "Privacy, security, explainability, fairness, and safe failure modes" }
]
},
{
id: "ai-for-sre",
title: "AI for SRE",
description: "Using AI and ML to improve reliability work",
content: "AI for SRE is about augmenting humans, not hiding system behavior behind magic. The useful path is better signal extraction, faster context gathering, safer remediation suggestions, and continuous learning from incidents, deploys, telemetry, and runbooks.",
links: [
{ title: "Google SRE Books", url: "https://sre.google/books/" },
{ title: "OpenTelemetry Documentation", url: "https://opentelemetry.io/docs/" },
{ title: "Prometheus Alerting Best Practices", url: "https://prometheus.io/docs/practices/alerting/" },
{ title: "Grafana Machine Learning", url: "https://grafana.com/docs/grafana-cloud/alerting-and-irm/machine-learning/" },
{ title: "AIOps Foundation", url: "https://www.cncf.io/blog/2023/11/06/aiops-cloud-native-ai-machine-learning-operations/" }
],
subtopics: [
{ name: "Anomaly detection", description: "Detecting unusual metric, log, trace, and event patterns without paging on noise" },
{ name: "Alert correlation", description: "Grouping related symptoms by service, dependency, deploy, topology, and time window" },
{ name: "Incident summarization", description: "Creating timelines, impact summaries, suspected causes, and handoff notes" },
{ name: "Root cause assistance", description: "Suggesting likely causes while preserving evidence and operator judgment" },
{ name: "Capacity forecasting", description: "Predicting saturation, traffic growth, resource needs, and seasonal behavior" },
{ name: "Change risk scoring", description: "Using deploy metadata, ownership, blast radius, and past incidents to guide rollout safety" },
{ name: "Runbook recommendation", description: "Finding relevant runbooks, dashboards, traces, commits, and ownership context" },
{ name: "Post-incident learning", description: "Extracting follow-ups, recurring patterns, and reliability investments from reviews" }
]
},
{
id: "ai-agents-platform-work",
title: "AI Agents for Platform Work",
description: "Agentic workflows for safe platform automation",
content: "AI agents can help platform teams by planning, querying tools, changing configuration, opening pull requests, and coordinating workflows. Treat them like powerful automation: give them narrow permissions, observable actions, clear approval gates, and tests before production impact.",
links: [
{ title: "Model Context Protocol", url: "https://modelcontextprotocol.io/" },
{ title: "OpenAI Agents SDK", url: "https://github.com/openai/openai-agents-python" },
{ title: "LangGraph", url: "https://langchain-ai.github.io/langgraph/" },
{ title: "OWASP Top 10 for LLM Applications", url: "https://owasp.org/www-project-top-10-for-large-language-model-applications/" },
{ title: "Backstage", url: "https://backstage.io/" }
],
subtopics: [
{ name: "Tool-calling agents", description: "Connecting agents to tickets, repos, observability, cloud APIs, CI/CD, and runbooks" },
{ name: "Retrieval-augmented generation", description: "Grounding answers in service catalogs, docs, incidents, diagrams, and ownership data" },
{ name: "Agent workflows", description: "Plan, act, observe, review, and escalate loops for operational tasks" },
{ name: "Human-in-the-loop controls", description: "Approval gates for production changes, access requests, rollbacks, and remediation" },
{ name: "Agent observability", description: "Tracing prompts, tool calls, decisions, outputs, latency, cost, and failure modes" },
{ name: "Evaluation and testing", description: "Golden tasks, simulation, red-team prompts, replayed incidents, and regression suites" },
{ name: "Least privilege access", description: "Scoped credentials, temporary tokens, sandboxed execution, and policy enforcement" },
{ name: "Platform copilots", description: "Self-service assistants for golden paths, templates, onboarding, and troubleshooting" },
{ name: "Autonomous remediation", description: "Starting with low-risk actions before guarded production changes" }
]
},
{
id: "cloud-native",
title: "Cloud Native",
description: "Containers, Kubernetes, and cloud-native technologies",
content: "Comprehensive cloud-native ecosystem including containers, orchestration, and service mesh. This is the technology foundation for modern platforms.",
links: [
{ title: "Kubernetes Documentation", url: "https://kubernetes.io/docs/" },
{ title: "CNCF Landscape", url: "https://landscape.cncf.io/" },
{ title: "CNCF Projects", url: "https://www.cncf.io/projects/" },
{ title: "OCI Specifications", url: "https://opencontainers.org/" },
{ title: "Containerd", url: "https://containerd.io/" },
{ title: "Helm Documentation", url: "https://helm.sh/docs/" },
{ title: "Kustomize", url: "https://kustomize.io/" },
{ title: "Cilium", url: "https://cilium.io/" },
{ title: "Istio", url: "https://istio.io/" },
{ title: "Linkerd", url: "https://linkerd.io/" },
{ title: "Crossplane", url: "https://www.crossplane.io/" }
],
subtopics: [
{ name: "Containers & OCI", description: "Container images, registries, OCI spec" },
{ name: "Container Runtimes", description: "containerd, CRI-O, gVisor" },
{ name: "Kubernetes Architecture", description: "Control plane, nodes, etcd" },
{ name: "Core Resources", description: "Pods, Services, Deployments, StatefulSets" },
{ name: "Configuration", description: "ConfigMaps, Secrets, environment management" },
{ name: "Package Management", description: "Helm, Kustomize, Carvel" },
{ name: "Storage", description: "PV, PVC, Storage Classes, CSI drivers" },
{ name: "Networking", description: "CNI, ingress controllers, Gateway API" },
{ name: "Service Mesh", description: "Istio, Linkerd, Cilium Service Mesh" },
{ name: "Security", description: "RBAC, Network Policies, Pod Security Standards" },
{ name: "Autoscaling", description: "HPA, VPA, Karpenter, Cluster Autoscaler" },
{ name: "Operators & CRDs", description: "Extending Kubernetes with custom resources" },
{ name: "Multi-cluster", description: "Federation, multi-cluster management" },
{ name: "eBPF", description: "Kernel-level observability and networking" }
]
},
{
id: "multi-tenancy",
title: "Multi-tenancy & Isolation",
description: "Tenant boundaries, fair resource sharing, and noisy-neighbor control",
content: "Multi-tenancy is a trust and resource-sharing design, not just a namespace convention. Decide who the tenants are, which components they share, and what happens if a tenant is compromised or exhausts resources. Namespaces and separate control planes do not, by themselves, isolate a shared host kernel. Combine appropriate runtime or cluster boundaries with authorization, network and data controls, quotas, and tested tenant onboarding and offboarding.",
links: [
{ title: "Kubernetes Multi-tenancy", url: "https://kubernetes.io/docs/concepts/security/multi-tenancy/" },
{ title: "Kubernetes Resource Quotas", url: "https://kubernetes.io/docs/concepts/policy/resource-quotas/" },
{ title: "Capsule Shared-cluster Tenancy", url: "https://projectcapsule.dev/docs/" },
{ title: "SPIFFE Workload Identity", url: "https://spiffe.io/docs/latest/spiffe-about/overview/" },
{ title: "Kubernetes RuntimeClass", url: "https://kubernetes.io/docs/concepts/containers/runtime-class/" },
{ title: "Kata Containers Architecture", url: "https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/README.md" },
{ title: "gVisor Application Kernel", url: "https://gvisor.dev/docs/" },
{ title: "Firecracker MicroVMs", url: "https://firecracker-microvm.github.io/" },
{ title: "Hyperlight Function Sandboxes", url: "https://github.com/hyperlight-dev/hyperlight" },
{ title: "Wasmtime Security Model", url: "https://docs.wasmtime.dev/security.html" }
],
subtopics: [
{ name: "Tenant Trust Models", description: "Distinguish cooperating internal teams, external customers, and untrusted workloads before choosing isolation boundaries" },
{ name: "Namespaces, Control Planes & Clusters", description: "Compare namespace-based tenancy, tenant control planes, dedicated clusters, and isolated runtimes without confusing API separation with host isolation" },
{ name: "Sandboxing & Runtime Isolation", description: "Choose a boundary for untrusted workloads, restrict host capabilities and egress, and verify the actual runtime, resource limits, and overhead; the host remains trusted" },
{ name: "Kata Containers", description: "Run pod sandboxes in lightweight VMs with a guest kernel through OCI/CRI integration; select a compatible RuntimeClass and remember containers in one pod share the VM" },
{ name: "gVisor", description: "Use runsc's userspace application kernel to mediate Linux system calls; validate syscall compatibility, storage and network behavior, and overhead rather than assuming full VM semantics" },
{ name: "Firecracker MicroVMs", description: "Use a KVM-based virtual machine monitor with a minimal device model for microVMs; provide guest images, lifecycle orchestration, networking, and host hardening separately" },
{ name: "Hyperlight", description: "Embed core Hyperlight for purpose-built functions in hypervisor-isolated sandboxes without a guest OS; constrain hostcalls, execution time, and memory; not a drop-in container runtime" },
{ name: "WebAssembly Sandboxes", description: "Run WebAssembly modules with runtimes such as Wasmtime, isolated linear memory, and explicit host imports or WASI capabilities; verify limits and do not treat this as a guest-kernel boundary" },
{ name: "Workload Identity & Authorization", description: "Scope service accounts, short-lived credentials, RBAC, secrets, and administrative access to the intended tenant" },
{ name: "Network & Egress Isolation", description: "Enforce and test default-deny policies, permitted DNS and service paths, and outbound access using a compatible network implementation" },
{ name: "Quotas & Noisy Neighbors", description: "Combine resource requests, limits, quotas, API fairness, and capacity planning; quota alone does not reserve capacity or eliminate contention" },
{ name: "Cluster-scoped Dependencies", description: "Account for shared CRDs, admission webhooks, operators, and cluster administrators that can affect every tenant" },
{ name: "Data & Telemetry Isolation", description: "Enforce tenant access in storage, backups, caches, logs, metrics, and traces rather than relying only on network separation" },
{ name: "Tenant Lifecycle", description: "Automate onboarding, policy inheritance, access reviews, and offboarding with explicit data-retention and resource-cleanup rules" },
{ name: "Isolation Verification", description: "Test cross-tenant denials and noisy-neighbor scenarios with synthetic workloads, and document the remaining shared failure boundaries" }
]
},
{
id: "ai-workload-infrastructure",
title: "AI Workload Infrastructure",
description: "GPU scheduling, model serving, and reliable training infrastructure",
content: "Running AI workloads is a different platform responsibility from using AI to help operators. Training, batch inference, and online serving have different scheduling, storage, recovery, and latency requirements. Design accelerator allocation, model delivery, tenant boundaries, and service objectives together. Measure useful throughput and cost, not GPU utilization alone, and prove that jobs can restart and serving workloads can meet their objectives.",
links: [
{ title: "Kubernetes Dynamic Resource Allocation", url: "https://kubernetes.io/docs/concepts/resource-management/dynamic-resource-allocation/" },
{ title: "Kueue Batch Admission & Quotas", url: "https://kueue.sigs.k8s.io/docs/overview/" },
{ title: "Kubeflow Trainer", url: "https://www.kubeflow.org/docs/components/trainer/overview/" },
{ title: "KServe Model Serving", url: "https://kserve.github.io/website/" },
{ title: "GPU Time-slicing & MIG Trade-offs", url: "https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html" }
],
subtopics: [
{ name: "Training, Batch & Online Inference", description: "Separate queue-wait and completion targets from interactive latency, availability, and output-correctness objectives" },
{ name: "GPU Scheduling & Allocation", description: "Match hardware, drivers, and runtimes; use supported device plugins or DRA ResourceClaims without allocating the same device through competing mechanisms" },
{ name: "Batch Admission & Fair Sharing", description: "Use queues, quotas, priorities, and coordinated admission; Kueue admission complements rather than replaces pod placement or node autoscaling" },
{ name: "Accelerator Sharing & Isolation", description: "Compare whole devices, MIG partitions, and time-slicing; time-slicing does not provide dedicated memory or fault isolation" },
{ name: "Distributed Training Topology", description: "Align GPU memory, CPU and NUMA placement, interconnect, and storage bandwidth across workers" },
{ name: "Model & Dataset Delivery", description: "Plan object storage, local caches, immutable artifact versions, tenant permissions, and download fan-out during cold starts" },
{ name: "Durable Checkpoints", description: "Store checkpoints outside disposable workers and test restart compatibility before relying on preemption or interruptible capacity" },
{ name: "Model Serving & Autoscaling", description: "Account for model-loading time, batching, concurrency, time to first token, and tail latency when scaling inference" },
{ name: "Artifact Lineage & Access", description: "Track model, dataset, and image identity; treat executable model formats as code and protect training data and serving credentials" },
{ name: "AI Reliability & Economics", description: "Measure queue age, useful throughput, failed work, cost per inference or token, and service objectives without logging sensitive prompts" }
]
},
{
id: "platform-engineering",
title: "Platform Engineering",
description: "Platform engineering concepts and internal developer platforms",
content: "Platform engineering practices, Internal Developer Platforms, and developer experience. This is the culmination of all skills, applying product thinking to infrastructure.",
links: [
{ title: "CNCF Platform White Paper", url: "https://tag-app-delivery.cncf.io/whitepapers/platforms/" },
{ title: "Platform Engineering Maturity Model", url: "https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/" },
{ title: "Backstage", url: "https://backstage.io/" },
{ title: "Team Topologies", url: "https://teamtopologies.com/" },
{ title: "Internal Developer Portal Guide", url: "https://internaldeveloperplatform.org/" },
{ title: "DevEx Paper (DX)", url: "https://queue.acm.org/detail.cfm?id=3595878" }
],
subtopics: [
{ name: "Internal Developer Platform (IDP)", description: "Self-service developer platforms" },
{ name: "Platform Capabilities", description: "Feature offerings and service catalog" },
{ name: "Golden Paths", description: "Recommended, paved roads for development" },
{ name: "Platform as a Product", description: "Product thinking applied to platforms" },
{ name: "Developer Experience (DevEx)", description: "User experience for developers" },
{ name: "Cognitive Load", description: "Reducing complexity for development teams" },
{ name: "Platform APIs", description: "API-first platform design" },
{ name: "Self-service", description: "Enabling autonomy with guardrails" },
{ name: "Platform ROI & Metrics", description: "Measuring platform success" },
{ name: "Developer Portals", description: "Backstage, Port, and internal tools" },
{ name: "Service Catalog", description: "Discoverable services and APIs" },
{ name: "Platform Team Structure", description: "Organizing platform teams effectively" }
]
},
{
id: "soft-skills",
title: "Soft Skills",
description: "Essential interpersonal and communication skills",
content: "Critical soft skills for effective platform engineering and team collaboration. Technical skills alone are not enough - communication and collaboration are essential.",
links: [
{ title: "Effective Communication", url: "https://www.skillsyouneed.com/ips/communication-skills.html" },
{ title: "Blameless Postmortems", url: "https://sre.google/sre-book/postmortem-culture/" },
{ title: "Technical Writing Guide", url: "https://developers.google.com/tech-writing" },
{ title: "The Manager's Path (for aspiring engineering managers / platform leads)", url: "https://www.oreilly.com/library/view/the-managers-path/9781491973882/" },
{ title: "So Good They Can't Ignore You (Cal Newport)", url: "https://www.amazon.com/Good-They-Cant-Ignore-You/dp/1455509124" }
],
subtopics: [
{ name: "Being a nice person to work with", description: "Interpersonal relationships matter" },
{ name: "Technical Writing", description: "Clear documentation and RFCs" },
{ name: "Oral Communication", description: "Speaking, listening, and presenting" },
{ name: "Stakeholder Management", description: "Working with different teams and leadership" },
{ name: "Collaboration", description: "Working effectively across teams" },
{ name: "Problem Solving", description: "Analytical and creative thinking" },
{ name: "Curiosity", description: "Continuous learning mindset" },
{ name: "Navigating Ambiguity", description: "Working with unclear requirements" },
{ name: "Blameless Retrospectives", description: "Learning-focused incident reviews" },
{ name: "Mentoring", description: "Helping others grow technically" },
{ name: "Influencing without Authority", description: "Leading through expertise and relationships" }
]
}
]
},
{
id: "certifications",
title: "Certifications",
description: "Industry certifications to validate and advance your platform engineering skills",
topics: [
{
id: "cnpa",
title: "CNPA - Cloud Native Platform Engineering Associate",
description: "CNCF's certification for platform engineering professionals",
content: "The Certified Cloud Native Platform Engineering Associate (CNPA) is CNCF's newest certification, specifically designed for platform engineers. It validates foundational skills in designing, building, and operating modern developer platforms in cloud-native environments. This vendor-neutral certification covers automation, security, observability, continuous delivery, platform APIs, and developer experience.",
links: [
{ title: "CNCF CNPA Official Page", url: "https://www.cncf.io/training/certification/cnpa/" },
{ title: "CNPA Curriculum", url: "https://github.com/cncf/curriculum/tree/master/cnpa" },
{ title: "Linux Foundation CNPA", url: "https://training.linuxfoundation.org/certification/certified-cloud-native-platform-engineering-associate-cnpa/" },
{ title: "Platform Engineering Resources (CNCF)", url: "https://tag-app-delivery.cncf.io/whitepapers/platforms/" }
],
subtopics: [
{ name: "Platform Engineering Core Fundamentals", description: "Core concepts, platform thinking, and architecture" },
{ name: "Observability, Security & Conformance", description: "Monitoring, security practices, and compliance" },
{ name: "Continuous Delivery & Platform Engineering", description: "CI/CD, GitOps, and deployment strategies" },
{ name: "Platform APIs & Infrastructure Provisioning", description: "API design and IaC practices" },
{ name: "IDPs & Developer Experience", description: "Internal Developer Platforms and DevEx" },
{ name: "Measuring Your Platform", description: "DORA metrics and platform success metrics" }
]
},
{
id: "kubernetes-certs",
title: "Kubernetes Certifications",
description: "CNCF Kubernetes certifications for cloud-native expertise",
content: "The CNCF offers several Kubernetes certifications that are highly valuable for platform engineers. These certifications validate hands-on skills with Kubernetes and are widely recognized in the industry.",
links: [
{ title: "CKA - Kubernetes Administrator", url: "https://www.cncf.io/training/certification/cka/" },
{ title: "CKAD - Kubernetes Application Developer", url: "https://www.cncf.io/training/certification/ckad/" },
{ title: "CKS - Kubernetes Security Specialist", url: "https://www.cncf.io/training/certification/cks/" },
{ title: "KCNA - Kubernetes and Cloud Native Associate", url: "https://www.cncf.io/training/certification/kcna/" },
{ title: "KCSA - Kubernetes and Cloud Native Security Associate", url: "https://www.cncf.io/training/certification/kcsa/" },
{ title: "Kubernetes Tutorials", url: "https://kubernetes.io/docs/tutorials/" },
{ title: "Killer.sh Practice", url: "https://killer.sh/" }
],
subtopics: [
{ name: "KCNA", description: "Entry-level cloud native knowledge certification" },
{ name: "CKA", description: "Certified Kubernetes Administrator - cluster management" },
{ name: "CKAD", description: "Certified Kubernetes Application Developer - app deployment" },
{ name: "CKS", description: "Certified Kubernetes Security Specialist - security hardening" },
{ name: "KCSA", description: "Kubernetes and Cloud Native Security Associate" }
]
},
{
id: "other-certs",
title: "Other Relevant Certifications",
description: "Additional certifications valuable for platform engineers",
content: "Beyond CNCF certifications, several other industry certifications can strengthen your platform engineering credentials. These cover cloud providers, GitOps, and related technologies.",
links: [
{ title: "HashiCorp Certifications", url: "https://www.hashicorp.com/certifications" },
{ title: "AWS Certifications", url: "https://aws.amazon.com/certification/" },
{ title: "Google Cloud Certifications", url: "https://cloud.google.com/learn/certification" },
{ title: "Azure Certifications", url: "https://learn.microsoft.com/en-us/certifications/" },
{ title: "GitOps Certification (Codefresh)", url: "https://codefresh.io/gitops-certification/" },
{ title: "Linux Foundation Certifications", url: "https://training.linuxfoundation.org/certification-catalog/" }
],
subtopics: [
{ name: "HashiCorp Terraform Associate", description: "Infrastructure as Code with Terraform" },
{ name: "HashiCorp Vault Associate", description: "Secrets management certification" },
{ name: "AWS Solutions Architect", description: "AWS architecture and services" },
{ name: "Google Professional Cloud Architect", description: "GCP architecture certification" },
{ name: "Azure Solutions Architect", description: "Azure architecture certification" },
{ name: "GitOps Fundamentals", description: "GitOps practices certification" },
{ name: "Linux System Administrator", description: "LFCS/LFCE Linux certifications" },
{ name: "Prometheus Certified Associate", description: "PCA - Prometheus monitoring certification" }
]
}
]
},
{
id: "company",
title: "Company Level",
description: "Organizational practices for successful platform engineering",
topics: [
{
id: "engineering-culture",
title: "Engineering Culture",
description: "Building a strong platform engineering culture",
content: "For a company to be successful in the long run, it needs to have a strong engineering culture. This includes fostering collaboration, continuous learning, and a product mindset for platform development.",
links: [
{ title: "Team Topologies", url: "https://teamtopologies.com/" },
{ title: "Accelerate Book", url: "https://itrevolution.com/product/accelerate/" },
{ title: "Engineering Culture at Spotify", url: "https://engineering.atspotify.com/" },
{ title: "Google Engineering Practices", url: "https://google.github.io/eng-practices/" }
],
subtopics: [
{ name: "Engineering Culture", description: "Building strong engineering practices" },
{ name: "Platform Strategy", description: "Organizational platform approach" },
{ name: "Team Topologies", description: "Stream-aligned, platform, enabling, and complicated subsystem teams" },
{ name: "Conway's Law", description: "Understanding how organization shapes architecture" },
{ name: "Psychological Safety", description: "Creating an environment for innovation" },
{ name: "Continuous Improvement", description: "Kaizen and retrospective culture" }
]
},
{
id: "platform-adoption",
title: "Platform Adoption",
description: "Strategies for successful platform adoption",
content: "Building a great platform is only half the battle - getting developers to adopt and love it requires product thinking, marketing, and continuous feedback.",
links: [
{ title: "Platform as a Product (CNCF)", url: "https://tag-app-delivery.cncf.io/whitepapers/platforms/#platform-as-a-product" },
{ title: "Platform Engineering's Inferno (DevEx Talk)", url: "https://www.youtube.com/watch?v=y0VLubJKT5U" }
],
subtopics: [
{ name: "Platform Marketing", description: "Internal communication and evangelism" },
{ name: "User Research", description: "Understanding developer needs" },
{ name: "Feedback Loops", description: "Gathering and acting on feedback" },
{ name: "Documentation", description: "Self-serve docs and guides" },
{ name: "Onboarding", description: "Smooth developer onboarding" },
{ name: "Champion Programs", description: "Building platform advocates" }
]
},
{
id: "platform-lifecycle",
title: "Platform Lifecycle",
description: "Versioning, upgrades, migrations, deprecation, and retirement",
content: "A platform capability needs an owner and an evolution plan long after its first release. Treat APIs, templates, operators, and shared services as supported products with explicit compatibility and maintenance policies. Give consumers practical migration paths and evidence that upgrades work before removing old behavior. Retirement is part of the lifecycle too: reclaim resources and access without losing data that must be retained.",
links: [
{ title: "CNCF Platform Engineering Maturity Model", url: "https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/" },
{ title: "Semantic Versioning", url: "https://semver.org/" },
{ title: "Kubernetes Deprecation Policy", url: "https://kubernetes.io/docs/reference/deprecation-policy/" },
{ title: "Kubernetes Upgrade Guide", url: "https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/" }
],
subtopics: [
{ name: "Capability Ownership & Support", description: "Track accountable teams, consumers, supported versions, maintenance windows, and end-of-life commitments" },
{ name: "API Versioning & Compatibility", description: "Define breaking changes, version contracts, test older clients, and communicate behavior changes beyond schema compatibility" },
{ name: "Golden-path & Template Evolution", description: "Version templates and dependencies; updating a scaffold does not automatically migrate applications created from older versions" },
{ name: "Platform Upgrades", description: "Test component compatibility and supported version skew, stage fleet rollouts, and bound the blast radius of upgrades" },
{ name: "Migration Paths", description: "Provide tooling, documentation, and coexistence windows for API and data migrations, with explicit rollback or roll-forward limits" },
{ name: "Deprecation Policy", description: "Publish notices and timelines, identify remaining consumers, offer supported alternatives, and handle time-bounded exceptions" },
{ name: "Safe Decommissioning", description: "Verify consumers have moved, preserve required data, revoke identities, and remove obsolete resources, integrations, and costs" },
{ name: "Sustainable Maintenance", description: "Budget for patching and migration work, track adoption and support burden, and retire capabilities that no longer justify their cost" }
]
},
{
id: "measuring-success",
title: "Measuring Platform Success",
description: "Metrics and KPIs for platform engineering",
content: "Measuring the success of platform initiatives is crucial for justifying investment and driving continuous improvement. DORA metrics, developer productivity, and platform adoption rates are key indicators.",
links: [
{ title: "DORA Metrics", url: "https://dora.dev/" },
{ title: "SPACE Framework", url: "https://queue.acm.org/detail.cfm?id=3454124" },
{ title: "Developer Productivity", url: "https://martinfowler.com/bliki/CannotMeasureProductivity.html" },
{ title: "CNCF Platform Maturity Model", url: "https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/" }
],
subtopics: [
{ name: "DORA Metrics", description: "Deployment frequency, lead time, MTTR, change failure rate" },
{ name: "SPACE Framework", description: "Satisfaction, Performance, Activity, Communication, Efficiency" },
{ name: "Platform Adoption Rate", description: "Tracking platform usage growth" },
{ name: "Developer Satisfaction", description: "NPS and developer surveys" },
{ name: "Time to First Deploy", description: "Onboarding efficiency metric" },
{ name: "Self-Service Ratio", description: "Automation vs manual requests" }
]
},
{
id: "finops",
title: "FinOps & Platform Economics",
description: "Cost allocation, showback, and the economics of platform capabilities",
content: "FinOps connects engineering decisions to the value and cost of running technology. Platform teams can make costs understandable at the point of use, build efficient defaults, and help finance and product teams agree on trade-offs. Optimize cost per useful outcome while protecting reliability and developer experience, rather than treating a smaller infrastructure bill as success on its own.",
links: [
{ title: "FinOps Framework", url: "https://www.finops.org/framework/" },
{ title: "FinOps Cost Allocation", url: "https://www.finops.org/framework/capabilities/allocation/" },
{ title: "FinOps Unit Economics", url: "https://www.finops.org/framework/capabilities/unit-economics/" },
{ title: "OpenCost Kubernetes Cost Allocation", url: "https://opencost.io/docs/" }
],
subtopics: [
{ name: "Cost Allocation", description: "Map accounts, tags, labels, and service ownership to teams and products, including a clear policy for shared and idle costs" },
{ name: "Showback & Chargeback", description: "Distinguish showing teams their attributed costs from actually charging budgets, and make allocation rules transparent" },
{ name: "Unit Economics", description: "Track cost per request, tenant, build, or other useful outcome alongside quality, reliability, and business value" },
{ name: "Budgets & Forecasting", description: "Forecast demand, investigate anomalies, and assign budget owners; spending alerts are not automatic hard limits" },
{ name: "Resource Efficiency", description: "Right-size requests, scale idle capacity, and tune storage and telemetry retention while measuring the effect on service objectives" },
{ name: "Pricing & Capacity Commitments", description: "Compare on-demand and committed spend, utilization risk, interruption tolerance, and data-transfer charges" },
{ name: "Cost-aware Self-service", description: "Expose estimates and ownership in golden paths, apply quotas, and expire temporary environments with safe cleanup" },
{ name: "Cost Data Quality", description: "Reconcile allocation estimates with billing data and document discounts, currency, timing, and shared-cost assumptions" },
{ name: "Cross-functional Decisions", description: "Bring engineering, finance, and product owners together to fund capabilities and evaluate cost, value, and risk over time" }
]
},
{
id: "ai-adoption-strategy",
title: "AI Adoption Strategy",
description: "Company strategy for adopting AI in platform and SRE teams",
content: "AI adoption should be treated like a product and operating model change, not just a tooling rollout. Companies need clear use cases, responsible experimentation, enablement, and metrics that prove AI improves reliability, developer experience, and platform outcomes.",
links: [
{ title: "People + AI Guidebook", url: "https://pair.withgoogle.com/guidebook/" },
{ title: "NIST AI Risk Management Framework", url: "https://www.nist.gov/itl/ai-risk-management-framework" },
{ title: "OECD AI Principles", url: "https://oecd.ai/en/ai-principles" },
{ title: "DORA Metrics", url: "https://dora.dev/" },
{ title: "Platform Engineering Maturity Model", url: "https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/" }
],
subtopics: [
{ name: "Use-case portfolio", description: "Prioritizing incident response, support, onboarding, docs, capacity, and toil reduction opportunities" },
{ name: "Build vs buy decisions", description: "Choosing between vendor copilots, internal agents, open source models, and custom workflows" },
{ name: "Pilot programs", description: "Running small experiments with clear success criteria and production-safe boundaries" },
{ name: "AI literacy", description: "Teaching teams prompt patterns, model limits, data handling, and review expectations" },
{ name: "Change management", description: "Rolling out AI workflows with champions, feedback loops, and transparent communication" },
{ name: "Outcome metrics", description: "Measuring reliability impact, adoption, time saved, quality, satisfaction, and risk reduction" }
]
},
{
id: "ai-governance-risk",
title: "AI Governance & Risk",
description: "Responsible AI controls for operational and platform workflows",
content: "AI governance gives teams confidence to use AI without creating hidden security, privacy, compliance, or reliability risks. For platform and SRE work, governance must cover data access, model behavior, approvals, auditability, and safe failure modes.",
links: [
{ title: "NIST AI Risk Management Framework", url: "https://www.nist.gov/itl/ai-risk-management-framework" },
{ title: "OWASP Top 10 for LLM Applications", url: "https://owasp.org/www-project-top-10-for-large-language-model-applications/" },
{ title: "ISO/IEC 42001 AI Management System", url: "https://www.iso.org/standard/81230.html" },
{ title: "Responsible AI Standard", url: "https://www.microsoft.com/ai/responsible-ai" },
{ title: "SLSA Supply Chain Security", url: "https://slsa.dev/" }
],
subtopics: [
{ name: "Data classification", description: "Defining which telemetry, code, incidents, tickets, and customer data can be used by AI systems" },
{ name: "Access boundaries", description: "Applying least privilege, scoped tools, temporary credentials, and tenant isolation" },
{ name: "Human approvals", description: "Requiring review for production changes, destructive actions, secrets, and customer-impacting workflows" },
{ name: "Audit trails", description: "Recording prompts, retrieved context, tool calls, approvals, actions, and outputs" },
{ name: "Vendor and model risk", description: "Evaluating retention policies, data residency, model updates, SLAs, and exit plans" },
{ name: "Policy as code", description: "Encoding AI usage policies into gateways, CI checks, admission controls, and platform APIs" },
{ name: "Incident response for AI", description: "Handling prompt injection, data leakage, unsafe actions, hallucinations, and model outages" }
]
},
{
id: "operational-knowledge-data",
title: "Operational Knowledge & Data",
description: "Making company knowledge usable by AI and humans",
content: "AI quality depends on the quality of the company's operational knowledge. Service ownership, runbooks, architecture, incidents, telemetry, and deployment data need to be accurate, searchable, governed, and connected before AI can reliably help platform and SRE teams.",
links: [
{ title: "Backstage Software Catalog", url: "https://backstage.io/docs/features/software-catalog/" },
{ title: "OpenTelemetry", url: "https://opentelemetry.io/" },
{ title: "Google SRE Workbook", url: "https://sre.google/workbook/table-of-contents/" },
{ title: "Diataxis Documentation Framework", url: "https://diataxis.fr/" },
{ title: "OpenAPI Specification", url: "https://www.openapis.org/" }
],
subtopics: [
{ name: "Service catalog quality", description: "Maintaining ownership, dependencies, lifecycle, SLOs, repos, dashboards, and runbooks" },
{ name: "Runbook hygiene", description: "Keeping procedures current, tested, searchable, and linked to alerts and services" },
{ name: "Telemetry standards", description: "Standardizing labels, resource attributes, trace context, log fields, and event schemas" },
{ name: "Incident knowledge base", description: "Structuring postmortems, timelines, follow-ups, impact, and recurring failure modes" },
{ name: "Architecture knowledge", description: "Capturing diagrams, ADRs, ownership boundaries, dependencies, and data flows" },
{ name: "Retrieval readiness", description: "Preparing docs and metadata for indexing, chunking, permissions, freshness, and citations" },
{ name: "Data ownership", description: "Assigning stewards for operational datasets, retention, quality, and access policies" }
]
},
{
id: "agentic-operating-model",
title: "Agentic Operating Model",
description: "How companies safely operate AI agents at scale",
content: "AI agents need an operating model before they become part of critical platform workflows. Companies should define where agents are allowed to act, how they are evaluated, who owns them, how failures are handled, and when humans stay in control.",
links: [
{ title: "Model Context Protocol", url: "https://modelcontextprotocol.io/" },
{ title: "OWASP Agentic AI Threats and Mitigations", url: "https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/" },
{ title: "Team Topologies", url: "https://teamtopologies.com/" },
{ title: "Open Policy Agent", url: "https://www.openpolicyagent.org/" },
{ title: "OpenTelemetry", url: "https://opentelemetry.io/" }
],
subtopics: [
{ name: "Agent ownership", description: "Defining accountable teams, escalation paths, lifecycle, documentation, and support model" },
{ name: "Permission tiers", description: "Separating read-only agents, PR-generating agents, approval-required agents, and break-glass automation" },
{ name: "Workflow boundaries", description: "Choosing which tasks are assistive, semi-autonomous, or never autonomous" },
{ name: "Evaluation program", description: "Testing agents with golden tasks, replayed incidents, simulations, and adversarial scenarios" },
{ name: "Operational controls", description: "Rate limits, budgets, kill switches, rollback plans, and dependency health checks" },
{ name: "Agent observability", description: "Monitoring tool calls, latency, cost, drift, errors, policy denials, and user feedback" },
{ name: "Continuous improvement", description: "Reviewing agent outcomes, missed cases, escalations, and user trust over time" }
]
}
]
}
]
};