Enterprise Platform Engineering: Consolidate Orchestration Not Testing Stacks

A pattern I keep seeing in enterprise platform eng conversations: A lot of large enterprises have acquired 3–5 companies in the last decade. Each one brought its own testing stack. > Jenkins here. GitHub Actions there. A team still running Cypress locally because nobody wired up their CI. The platform team inherits the mess. Maybe 30% of engineers are on Kubernetes. The rest are on VMs and legacy apps. "Consolidate the testing stack" sounds rational in the boardroom. In practice, it's the riskiest migration a platform team could run, because the blast radius of breaking a test framework is production bugs. What I tell the Directors of Platform Eng I talk to: Don't consolidate the frameworks. Consolidate the orchestration layer underneath. Let every team keep the tool that fits their stack: Playwright, K6, Postman, JUnit, whatever. Put one control plane on top that tracks execution, flakiness, RBAC, and audit across all of them. That's the path acquisition-heavy orgs actually ship. What's worked for platform leaders dealing with this? #PlatformEngineering #Kubernetes #DevOps #CICD

  • graphical user interface

To view or add a comment, sign in

Explore content categories