AI
The Real Lock-In: Infrastructure Outside the Cluster
Saxo Bank processes millions of trades every year on a global multi-asset trading platform. Kubernetes handled the workloads. It did not handle identity providers, databases, event streaming, or network controls. Those sat outside the cluster, owned by different teams, governed by different processes. Hard-coded endpoints, provider-specific credentials, and manually maintained network rules meant services could not move. The lock-in came from architecture, not contracts.
The Kafka ACL Problem: Five Steps to Change One Permission
Updating a single Kafka topic ACL required a developer to find a service account, open a separate portal, locate a managed identity ID and hope it was correct, switch to a repository owned by another team, edit the ACL file, open a PR, and wait for approval. Then repeat the entire sequence for test, staging, and production. Kristiansen called it massive cognitive load: slow and boring work that added no value.
Service Blueprints: One Declaration, Zero Broker Interaction
Saxo built a service blueprint system. A developer opens a service file and writes one line: this service consumes this Kafka topic. Enterprise architecture approves it. Blueprint operators then reconcile the ACL across all environments automatically. One PR, one approval, zero portal visits, zero identity ID copying, zero second PRs. The developer declares intent, not implementation. That abstraction lets Saxo swap messaging providers without rewriting any application code.
4.8x Amplification After One Year in Production
After a year in production, the numbers are concrete. 379 commits from 121 developers across 79 teams triggered 1,827 automated infrastructure operations. That 4.8x amplification factor came from application developers, not the central platform team. Manual intervention after the initial approval: zero. The same pattern covers tenant onboarding, workload identities, network policies, observability namespaces, and database access. One catalog entry and one approval drives all of it.
Extending the Model to On-Premises Workloads
The blueprint model does not stop at containerized workloads inside Kubernetes. Saxo is extending it to on-premises services, covering automated certificates, load balancing, and identity management. Traditional service accounts are being replaced with automated group managed service accounts. Services that will never run inside a cluster get the same declarative model and the same GitOps-driven reconciliation. The abstraction layer separates dependencies from implementation regardless of where the workload runs.
Notable Quotes
it’s a single PR one approval and there’s zero broker interaction the developer never touches a portal never copies any density ID never makes a second PR Oskar Kristiansen · ▶ 2:14
digital 70 is not where you run it’s the freedom to change where you run what you run on and how it’s connected without reriding a single application Oskar Kristiansen · ▶ 4:28
it’s 121 Developers Not A Central Platform Team That Is Driving The Infrastructure Changes Through Governance Of The Service Oskar Kristiansen · ▶ 3:23
Key Takeaways
- 379 developer commits produced 1,827 automated infrastructure operations, a 4.8x factor.
- Declaring intent rather than implementation details unlocks infrastructure portability without rewriting applications.
- The same blueprint and GitOps reconciliation model works for on-premises workloads, not just Kubernetes clusters.
About the Speaker(s)
Oskar Kristiansen is a Platform Engineer at Saxo Bank focused on cloud native open source technologies and their application in business. He holds the Kubestronaut certification.