Keynote: Digital Sovereignty by Design: Turning Developer Intent into Portab... O. Kristiansen (ASL)

In this talk, Ask Christianson from Sexo Bank presents the challenges of managing workloads within a multi-asset trading platform. He discusses the complexities that arise when services are tightly coupled with specific infrastructure components, such as hard-coded endpoints and identity management. To alleviate these issues, the speaker introduces the Sexo Service Blueprint, which allows developers to declare services in a simplified manner. This innovation enables automated updates to access control lists across various environments, significantly reducing cognitive load and manual intervention for developers. As a result, the platform achieves an impressive amplification factor of 4.8x in infrastructure operations, driven by numerous developers across diverse teams. Christianson emphasizes the importance of abstraction in creating flexible architectures that allow for changes in infrastructure without the need to rewrite applications.

Ah thank you and good morning everyone. I'm Ask Christianson from Sexo Bank. Sexo Rans A Global Multi-Acid Trading Platform. We process millions of trades every year and there are many of you in this room. Wee Bed and Cubanators. We head the clusters, we head the Git Up setup, we head the CICD pipelines. But we head a wall. Manage workloads It doesn't manage the world around them Everything

from identity providers Databases Event streaming Network controls All outside the cluster Owned by different teams and governed by different processes We have estimated the workload, but we haven't estimated the boundaries And here's what we realize When your services are directly coupled to a specific infrastructure Hard coded endpoints Provide specific credentials CAI dependent network rules You can move You are locked in not by contract but by architecture

The bane was never It was everything around it Let me make a concrete To update a kafka topic ACL A developer had to find a service account Navigate to the portal to find a Manage ID Minus Identity Computer Write ID and hope they get the right one Then go to a completely separate repository Owned by another team Update the ACL file Create a PR Wait for approval

And when they're done they had to do it All over again for test sim and life this is a massive cognitive load for developers and it's slow and it's erroneous so we build sexo service blueprint a developer open the service declares my service consumes this kafka topic that's it enterprise architecture approves and from that moment blueprint operators reconcile the acl across all environments automatically it's a single

pr when approved and there's zero broker interaction the developer never uses a portal never copies and density id never makes a second pr and he is the servant angle the developer the class i consume this topic not i speak to this specific broker with this specific identity and that abstraction is what lets you swap kafka for other messaging providers without rewriting a single application the same pattern

works for tend on boarding workload identities network policies observability namespace and and access database access one Catalog entry one approval and everything is reconciled so what does this look like after a year in production 4.8 x that's the amplification factor 379 commits from 1121 developers across 79 teams trigger 1800 and 27 automated infrastructure operations so think about that it's 121 developers not a central platform team that

is driving the infrastructure changes through the gov service a manual intervention after that initial approval zero this is what service looks like in practice you can change your mind about infrastructure without rewriting your applications and we're not stopping at containerized applications running inside the cloud native ecosystem blueprint is now extending to unpremised workloads automated certificates load balancing even with identity management replacing traditional service accounts for automated

written groups managed service accounts and this is for services that will Never run in a cluster Same declarative model Same song driven reconciliation Because serviceability is not a Kubz feature It's what you get when you abstract dependencies from implementations and that's an organizational capability I'd like to take a moment to emphasize that 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 We build that and started with the service catalog coordinates operators and cloudnative ecosystem that this community created If you like to learn more I will do a deeper introduction to Diz and implementation in my session later today. Thank you very much and enjoy the rest of the conference.