Cloud Native Pioneer: “Sovereignty Is a Spectrum”

Cloud Native is about more than technology. It also changes how teams work together, develop software, and take responsibility for running it. But what does that look like in practice? What challenges do Swiss companies face on their journey to Cloud Native? And what role does data sovereignty play in a Cloud Native strategy? We spoke with Lena Fuhrimann, co-founder of the Cloud consulting firm bespinian and a pioneer of Switzerland’s Cloud Native movement.

How would you explain Cloud Native to someone without a technical background?

Lena Fuhrimann: Many companies run their software on their own servers. That hardware often isn’t used to its full capacity, but it still needs maintenance and support. That’s why it can make sense to run applications in the Cloud and use resources as needed. Cloud Native means designing software from the start to make the most of what the cloud offers.

A key part of this is being able to understand how an application is doing at any time: Is it running reliably? Where are the bottlenecks? Are errors occurring? This visibility helps teams spot problems early and respond more quickly. The goal is to run software efficiently and reliably in the Cloud while continuously improving it.

When does Cloud Native become truly transformative for a company? Is there a tipping point?

Cloud Native becomes transformative when it becomes part of the company culture. The technical side is relatively straightforward to describe: I can adapt an application to use the Cloud’s capabilities efficiently. But the real shift only happens when teams make this way of working their own. You see it, for example, when they start developing new applications according to Cloud Native principles on their own initiative. They do this because they recognize the benefits and have the knowledge and experience to develop and run their applications accordingly.

As with many changes, culture is the deciding factor. It’s tempting to focus on the technology: You introduce a few tools and check an item off the list. The human and cultural side is less tangible. But it’s essential to making the change last.

You co-founded bespinian in 2019 and have since delivered more than 100 Cloud Native projects with your team. What mistakes or misconceptions do you encounter most often in Swiss companies, both culturally and technically?

We see both. But in my view, the biggest challenge is the human side. Changing how people think and work together generally takes much more time and support than making technical changes. When people first encounter Cloud Native, it can create uncertainty or a fear of change. Understandably, many initially try to apply their experience and ways of working from traditional IT directly to this new environment.

I think it’s important to show team members at the companies we work with what this change can mean for them in practical terms: How will their role evolve? Which tasks can they automate? And what will that free up time for? Spending less time manually handling routine tasks, which most people don’t particularly enjoy, gives them room to take on other work and develop new skills. That can open up new career opportunities, too. The key is to make these benefits visible. When team members see the value and support the change, that creates the foundation for the technical implementation. You still need experience and the right tools. But I would always start with people and culture.

The community plays an important role here, too. How did you get involved in the Cloud Native community, and what motivates you to help shape it?

I’ve found the Cloud Native community, and the wider IT community, incredibly warm and welcoming, both in Switzerland and elsewhere. You show up and immediately find yourself in an interesting conversation. People are passionate about what they do, and some are pretty nerdy, which I really appreciate. You feel included from the start. That made a real impression on me and made it easy to get involved. People aren’t just interested in what you do for work. They’re interested in you as a person, too. I particularly value that warmth.

That’s why I enjoy being active in the community, organizing events, and giving talks. I won’t pretend that this doesn’t also have a marketing benefit for us. It’s an important way to raise awareness of our company and products. But it’s work I really enjoy, and it comes naturally because the community is so open and welcoming.

How has the Cloud Native community has evolved over the past few years?

In the technical sense, a lot of the focus has shifted toward AI. Cloud Native remains important, but AI now plays a major role in that space, too. For example, people are exploring how to rework software more efficiently or use AI to better understand the health and behavior of applications.

On the one hand, these new topics bring the community even closer together. They give us things to discuss, encourage us to exchange ideas, and help us get to know each other better. On the other hand, I see a challenge across the IT industry: New technologies and topics are emerging at an ever-faster pace. People working in IT generally enjoy learning new things and know that change is part of the job. But AI has accelerated that pace considerably.

For some, that creates a sense of helplessness: They want to engage with these developments but simply don’t have the capacity to keep up with everything. I hear this in conversations at events, too. Alongside the excitement about new possibilities, people are increasingly asking how they can manage the pace of change.

What challenges should the community tackle together over the next two years? How can members support each other?

Keeping up with the pace of technological change will certainly be one of them. Nobody can explore every new technology every day, let alone in depth. This is one of the community’s greatest strengths: We can pool our knowledge. Individual members take a close look at developments in their areas of expertise and share what they’ve learned at events. For example, I can present the technologies I consider particularly relevant in my field and share my perspective on them. Others contribute their own views and experience. This creates a kind of shared filter, so we don’t all have to follow everything to stay informed about the developments that matter.

Supporting each other on a personal level is just as important. It helps to talk to people who are in the same boat. They understand why something is on your mind or frustrating you, and they can share your excitement about something, too. Personally, I get a lot out of that connection with the community.

You’ve spoken at both GovTech events and traditional developer conferences. What differences do you see between the public and private sectors when it comes to adopting new technologies?

My impression is that the fundamental challenges are very similar, especially when it comes to adopting AI. Public institutions face governance questions just as private companies do. How complex those questions become also depends heavily on the size of the organization. Smaller companies can often be more agile and respond to change more quickly. Larger organizations generally need more coordination: First, they need a strategy, then they have to define and implement policies. Only then do they select the right tools. That can make it harder to try new approaches without a lengthy process. Public institutions also face their own specific challenges. In my view, the differences are therefore less about the fundamental questions and more about the conditions organizations operate under and how they respond to them.

Incidentally, I often meet the same people at those events. That’s another defining feature of Switzerland’s IT and Cloud Native community: People know each other, exchange experiences, and understand the challenges others are dealing with.

A midsize Swiss company wants to move toward Cloud Native and asks for your support. What would you recommend for the first three months?

I would always start by asking what problems the company wants to solve with Cloud Native. Why does it want to take this path? Cloud Native is also a buzzword. Pursuing it simply because everyone is talking about it won’t get you very far. So first, we need to understand the starting point, both the teams themselves and me as an external consultant. What are the specific challenges? What needs to improve? From there, we can define a clear goal and a strategy with concrete steps. Only then should we consider which target platform and technologies are suitable.

I have to remind myself of this, too: When you’re enthusiastic about technology, you want to jump straight into building a solution and choosing the right tech stack. But the most important step comes before that: understanding why you want to move toward Cloud Native and what problems you actually want to solve.

What role does data sovereignty play when planning a Cloud Native strategy?

Sovereignty is often oversimplified: Are we sovereign or not? But for most companies, there’s no single answer to that question. First, they need to assess their situation: What data do we have? What requirements apply to it? Where can it be processed? And how quickly do we need to be able to switch Cloud providers if necessary? Companies should identify the aspects that matter to them, whether because of their own goals or specific regulations, and examine those in detail. Simply aiming to be “fully sovereign” can make it easy to lose focus.

In my view, complete independence is almost impossible to achieve. Even if you run your own Cloud or an on-premises Kubernetes cluster, you still depend on hardware suppliers, for example, who may be based abroad. Sovereignty is a spectrum. What matters is making deliberate decisions about which data can go where, which dependencies you can accept, and where you need more control. That also means considering how much time and money your company can and wants to invest.

Many companies feel they have to choose between Big Tech’s AI capabilities and control over their data. Are those goals really at odds?

I don’t see it as an either-or choice. This ties back to sovereignty. Companies have different use cases, and different models are suited to them. Not every task needs one of the most powerful models from the major AI providers. Equally, a locally hosted language model isn’t the best choice for every task. That’s why it makes sense to have a platform that provides central access to different AI providers and models and lets you manage them in one place. Usage policies and costs should be managed there, too. This allows a company to decide for each use case: Do we use a model from an international provider, a Swiss provider, or a model we run ourselves?

This makes it possible to weigh performance, control over data, and costs for each task. You use a powerful model where it adds value and choose a more affordable or locally hosted solution for other tasks. In the long run, I think that makes more sense than committing entirely to a single AI provider or running everything yourself. There are plenty of options in between that let you combine the benefits of both approaches and get the best of both worlds.

How realistic is it to run AI workloads in Switzerland while maintaining sovereignty, and where are the limits?

The limits often come down to cost and the availability of suitable hardware. If you want to run AI yourself, you need to ask: Can we get the hardware we need, and can we afford it? Fluctuating prices make planning even harder. Then there’s the knowledge and experience needed to run it. That makes it all the more important to keep as many technical options open as possible. A central point of access to different AI providers and models, built on open standards and interfaces, can help reduce dependencies and make future migrations easier.

A company might, for example, start by using a Swiss provider that hosts AI models and makes them available for queries. If it later turns out that a particular use case requires more control, or that investing in its own hardware makes financial sense, the company can assess whether running the models itself is the right move. Open standards don’t automatically make that transition easy, but they provide an important foundation. You don’t have to commit to a single operating model from the start. Instead, you can begin with a suitable solution and develop it as your requirements, internal capabilities, or financial circumstances change.