DOWN with Shift Left: Why You Should be Shifting DOWN into the Platform
summary
Argues that shift left simply shifts cognitive load onto developers and instead promotes shift down to the platform, where automation and policy enforce decisions. Demonstrates concrete tools and results: automatic Git scans with KubeScape and Harbor image-on-push scanning, auto PR fixes from Snyk/Dependabot, builds via Kpack/Buildpacks, service APIs via Crossplane and Backstage, auto-tuned resources with ScaleOps and observation via Pixie. Cites surprises: many Kotlin scan findings are irrelevant to runtime, and teams see 75% wasted usage in Kubernetes requests (up to 92%), so platform automation measurably reduces noise and developer overhead.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:04What is shift left
- 2:27Problems with shift left
- 5:15Kelsey Hightower critique
- 8:23Shift left as plumber metaphor
- 9:27Introducing shift down
- 10:30Shift left vs shift down scanning
- 11:54VEX documents role
- 12:59Developers shouldn’t write IaC
- 14:01Self-service portals
- 15:08Dockerfiles burden
- 15:49Kubernetes resource limits
- 17:16Software templates
- 18:58PR generation for fixes
- 19:40Kpack automated builds
- 20:22ScaleOps resource tuning
- 21:06Pixie observability
- 22:08Key takeaways
- 23:12Q&A
- 25:00Platform engineering challenges
- 26:47Tips for platform benefits
related talks
37mDon’t Sh*t-Left: How to Actually Shift-Left
16mShift Left, Not Off a Cliff: Why Your Testing Strategy Is Breaking Developers
52mShift Left or Squish Right - Testing in a Shifting World
13mShift left the proper way
31mPanel Discussion: Platform and Developer Productivity - Trends and Challenges
44mPlatform Engineering 101: Building Internal Developer Platforms
29mYour platform is not an island: building a platform for your ecosystem
46mForget Developer Platforms, Think Developer Productivity!