Presenters
Source
Divide and Collaborate: Scaling Backstage at ING 🚀
In the world of massive organizations, complexity is rarely a problem—it is a numbers game. At ING, a global systemic bank with 60,000 employees and 15,000 developers, the sheer volume of internal tools created a paradox: while the bank’s purpose is to help people stay a step ahead, its own developers were struggling to navigate a labyrinth of over 60 disparate portals just to get a single application to production.
To solve this, Krzysztof Janota (Product Manager) and Dusan Askovic (IT Area Lead) turned to Backstage.io. Here is how they transformed a fragmented ecosystem into a scalable, healthy developer platform.
☕ The Origin: From Kitchen Chats to Global Standard
Four years ago, the Backstage initiative at ING started as a casual conversation. The challenge was clear: developers were drowning in too many portals. The solution? Create a single entry point. However, the team knew that simply building one more portal wouldn’t work. They needed to convince 7,000+ engineers to migrate their services and contribute to a unified ecosystem.
🥕 The Carrot and the Stick: Driving Adoption
To ensure success, the team employed a two-pronged strategy:
- The Carrot: They focused on developer experience (DX). They provided effortless local setups, on-demand playground environments for testing, and robust support channels to guide engineers through writing plugins and templates.
- The Stick: They leveraged the Technology Standards Board (TSB). This body of senior architects dictated that Backstage is the standard front-end for ING’s tech platform. While they don’t mandate a full-scale migration of existing back-ends, they require all new initiatives to use Backstage, and existing portals to migrate during their natural lifecycle management phases.
🏗️ Scaling Without Chaos: The Split Architecture
Scaling to thousands of developers across multiple countries risks “absolute mayhem.” To prevent a single crashing plugin from taking down the entire developer portal, ING adopted a split architecture:
- Core Plugins: The software catalog, handling hundreds of thousands of entities, runs on its own instance with dedicated database tuning for high performance.
- Community Plugins: External contributions (like the Q&A plugin) run on separate instances.
- Internal Contributions: Teams can either build native Backstage plugins or use a backend proxy plugin to connect to existing legacy services, avoiding inefficient rewrites.
🛤️ The Golden Path Plugin
One of ING’s most innovative solutions is the Golden Path plugin. While the default Backstage Scaffolder is powerful, it often lacks clear ownership for complex, cross-domain journeys.
- The Concept: The Golden Path acts as a “meta-template.” It stitches together multiple templates owned by different teams into one seamless journey.
- The Benefit: A developer can start, stop, and resume a complex workflow. If a journey involves teams A and B, the plugin ensures responsibility remains distributed, allowing each team to maintain their specific part of the process.
🛡️ Governance and Quality Control
How do you ensure quality when anyone can contribute? Through a mandatory Contribution Plugin.
- Transparency: All ideas are pitched in a public repository so teams don’t duplicate work.
- Validation: Every contribution must pass a strict governance pipeline, including UX/UI validation to ensure consistency across the platform, followed by architecture review and final code review.
Note: ING is open-sourcing their Golden Path and Contribution plugins on their GitHub repository.
🎙️ Q&A: Insights from the Floor
Q: How do you handle versioning in the Golden Path plugin when multiple teams own different steps? A: Currently, we use a naming-based workaround. While not perfect, it works. We are looking to the community to help us push for native versioning within the Backstage Scaffolder itself.
Q: Do you enforce preconditions for onboarding a UI? A: Yes. The primary requirement is a UI/UX design verification to match the bank’s design system. We also provide documentation on required health probes and operational standards that teams must meet before they go live.
Q: What if a developer wants to use a language outside your supported standards, like Rust? A: If it’s for an external-facing application, the TSB standards apply—no exceptions. If it’s internal, you might get a pass, but you will be operating on an “off-road” journey. You won’t have the support, pipelines, or “Golden Path” tooling that the standard languages enjoy. You are essentially on your own. 🦾
This synthesis captures the essence of ING’s journey toward a unified developer experience. By balancing architectural discipline with developer-centric tools, they have turned “divide and collaborate” from a slogan into a working reality.