Building a Culture for a Kubernetes-Based Platform in a Bank

In a banking environment, open source can earn trust by running real workloads, as Marcy Paramonova and Stéphane Cusin explained in their talk Building Cloud Native Culture in a Bank at KubeCon & CloudNativeCon Europe. Deploying Kubernetes was the easy part; the hard part was culture: community of practice, shared knowledge, rituals, ownership. Teams try things, keep what works, and improve bottom-up.

Open source was not an obvious choice in their banking environment, Cusin mentioned. They received questions about support and accountability. Instead of trying to convince people with theory, they started running real workloads. Over time, trust was built by operating the platform day after day:

Open source stopped being seen as a risk. It became the foundation.

They treated their first version of Kubernetes like a project. "We delivered it, we got a good adoption", Cusin said. But the operation was incredibly hard. Not because the technology was broken, but because they hadn’t built the culture around it yet:

Nobody knew who to call, responsibilities were blurry, and teams were consuming the platform without really contributing to it. Every incident felt like a fire drill.

They realized deploying Kubernetes was the easy part. The hard part was building the culture with a community of practice around it. The shared knowledge, the rituals, the ownership model, Cusin explained:

Without that culture, no platform survives its own success.

They invite people to experiment, for instance by having a yearly competition where everybody can submit their ideas and the one that wins, actually gets implemented. Many of their improvements came from the bottom up, Paramonova argued.

They used open source as a compass, something that helped them orientate a subject, Cusin explained:

When Kubernetes appeared, we recognized it immediately. Strong Kubernetes, transparent governance, and real production users. The compass pointed; we followed. And now we are watching OpenStack the same way.

A compass doesn’t force you in one direction. It helps you recognize the right opportunity when it arrives, Cusin said.

They tried things, and some of them didn’t work. They kept the ones that did. The act of trying, of deliberately designing how teams interact, creates the culture we have today, Cusin said. Structure first, the culture follows.

Every organization is different; every regulated environment has its own constraints, Paramonova said. You need a compass during your journey. It’s something that will guide you when everything else is uncertain. For us, it was open source, she concluded.

InfoQ interviewed Marcy Paramonova and Stéphane Cusin after their talk.

InfoQ: How did you gain trust from your development teams?

Stéphane Cusin: Over time, trust emerged from a combination of transparency and reliability. When developers see that the platform consistently helps them deliver applications safely and efficiently, adoption follows naturally.

Marcy Paramonova: Trust was not something we could establish by presenting a roadmap or writing good documentation, though both matter. It came from running things. From being present when something broke. From being honest about what was not yet ready.

Cusin: Today, our culture is centered around ownership, automation, transparency, and continuous improvement. Teams are empowered to move quickly, but they do so within a framework of shared standards and platform capabilities. The result is not only greater efficiency, but also greater consistency, reliability, and visibility across the organization.

InfoQ: How did Kubernetes transform how your organization builds software?

Cusin: Kubernetes gave us a common platform and a common operating model. In the first version of our platform, we gave teams flexibility. We exposed many Kubernetes capabilities directly and allowed teams to customize their deployment model extensively. In practice, that often resulted in different patterns emerging across teams.

One of the lessons we learned as platform engineers is that developers do not come to a platform looking for more infrastructure choices. They come to a platform to deliver software.

In our current platform, Kubernetes is no longer the product. Kubernetes is the implementation detail. The product is a simple, secure, and standardized software delivery experience.

We provide opinionated deployment patterns, standardized Helm charts, and common platform capabilities. As a result, when an engineer moves from one team to another, the deployment experience is largely the same. They do not need to relearn how applications are packaged, deployed, monitored, or operated.

Paramonova: The transformation I experienced most directly was organizational. Kubernetes gave teams a common language. It created shared abstractions that made collaboration across different parts of engineering much more natural.

Before, a lot of knowledge was siloed by team or by technology stack. Kubernetes did not erase those silos overnight, but it gave everyone a shared foundation to build on. That changed conversations, and changed what was possible.