“With Kubernetes, you just ship your container and it runs”

From startups to enterprises, companies of all sizes use Kubernetes (K8s) to automate deployments, improve reliability, and build portable platforms across Clouds. But what does this mean in practice for companies and developers? We asked two Swiss Kubernetes experts: Aarno Aukia, co-founder of the DevOps company VSHN, and Armin Zaugg, Head of IT Operations at Xelon.

In this interview, Aarno and Armin explain how Kubernetes works, what makes the container orchestration technology so powerful, and which common Kubernetes misconceptions Swiss companies should watch out for.

Xelon: In your own words, what is Kubernetes? How would you explain its value to someone without a technical background?

Aarno Aukia: For non-technical people, I like to describe Kubernetes as an operating system for modern applications. Instead of managing individual servers manually, Kubernetes automatically runs and scales software across many machines. That helps companies deploy applications faster, keep them running reliably, and avoid being locked into a single vendor.

Armin Zaugg: One of the nicest analogies is the container ship. Think of applications as shipping containers and Kubernetes as the ship that delivers them to users. It’s simple but very powerful. You can also extend the analogy to different roles: who loads the containers, who steers the ship, and who coordinates everything. It’s a comprehensive model that’s been around for quite a while and still works very well.

How did you get started with Kubernetes, and what still excites you about it today?

Aarno: I got started in the summer of 2015. A friend told me about this new container orchestration technology that had just reached beta and suggested we explore it together. By early 2016, we launched APPUiO, the first production Kubernetes service in Switzerland.

What fascinated me then—and still does—is the automation. Before Kubernetes, containers were mostly a packaging tool. Kubernetes finally solved real operational problems by automatically distributing workloads and restarting them if something failed. It enables what we sometimes call “beach operations”: the systems run themselves, while humans are at a beach and only step in when needed.

Armin: I came to Kubernetes a bit later. I first learned about containerized workloads at university around 2016, but Kubernetes clicked for me only a few years afterward, when it was already well established.

What excites me most is the shift to a declarative, configuration-driven approach. You describe what you need through a simple API, and the complex logic happens behind the scenes. There’s an enormous ecosystem and community contributing to it, which makes the platform very robust and battle tested.

What has been a breakthrough Kubernetes project you’ve worked on?

Aarno: One example is helping a regulated Swiss organization modernize its legacy infrastructure; it was Health Info Net (hin.ch). If you email a Swiss doctor, chances are it goes through that system. We moved them from manual deployments to a standardized Kubernetes platform, including multi-Cloud and multi-vendor complexity. The results were significant: faster release cycles, fewer outages, and much better operational efficiency. Deployment times dropped from days to minutes. It’s a project I’m still very proud of.

Armin: Most of my projects were greenfield rather than brownfield transformations. Kubernetes was already established when we started. My focus was mainly on platform engineering and developer experience. In that space, Kubernetes provides far better tooling to support developers and make their work easier. When teams experience that improvement directly, the appreciation is immediate.

Which types of companies in Switzerland typically use Kubernetes today?

Aarno: Any company running more than a handful of software workloads tends to evaluate Kubernetes at some point. That includes SaaS providers, development agencies, and enterprises building internal platforms. We see strong adoption in fintech, healthcare, the public sector, and industrial manufacturing—basically anywhere reliability, compliance, and scalability matter. It’s especially relevant for APIs, data platforms, and AI workloads.

Armin: And if you’re very small, you can still benefit indirectly. There are higher-level services that abstract Kubernetes away, so you don’t manage the control plane yourself. You just ship your container, and it runs. That can be a very convenient entry point for smaller projects.

 

When does Kubernetes become a real game changer?

Aarno: Kubernetes becomes transformative once an organization runs more than a single application, maybe three or more instances across environments or customers. At that point, the platform benefits start to outweigh the effort. It becomes even more valuable when companies adopt a platform strategy and rely on one platform to run many applications. That’s where you really leverage the ecosystem, automation, and scalability.

Armin: Scalability is definitely number one. Kubernetes can scale massively. But extensibility is equally important. Through the operator pattern, you can extend Kubernetes to manage almost anything: databases, messaging systems, you name it.

Aarno: Exactly. You end up with one extensible platform that supports many use cases while keeping the same operational model.

When companies first adopt Kubernetes, what hurdles do they face?

Aarno: The biggest mistake is treating Kubernetes as just another tool instead of a platform transformation. Organizations often underestimate the cultural and operational shift required. If teams deploy Kubernetes without proper platform engineering practices, they create complexity without gaining the governance and automation benefits. That’s when things go wrong.

Armin: I see the same pattern. There’s a steep learning curve, especially culturally. Training and empowerment are crucial. Interestingly, I’ve seen teams go from very skeptical to becoming strong advocates once they understand the model.

What role does the IT infrastructure play when implementing Kubernetes?

Aarno: It’s fundamental. Kubernetes doesn’t provide the underlying servers; it only manages applications. It won’t magically make your environment secure or stable. You need solid infrastructure underneath and proper integration. Many organizations therefore choose managed Kubernetes services or external providers so they can focus on their actual business problems. This layered abstraction is key to scaling. Not every company needs to build every layer themselves.

Armin: And if the lower layers aren’t stable, troubleshooting becomes very difficult. For example, network issues beneath Kubernetes can be extremely hard to diagnose from the platform level. You have to trust the layers below you.

How do you expect Kubernetes to evolve in the coming years?

Aarno: I think Kubernetes itself will become less visible to developers. The industry is working hard to reduce complexity and improve usability. Developers shouldn’t need to understand every internal detail—just like car drivers don’t need to understand the thermodynamics of the engine. At the same time, new use cases, such as AI workloads, edge computing, serverless, will continue expanding Kubernetes’ role, mostly adding complexity behind the scenes.

Armin: If you look at the Cloud Native Computing Foundation ecosystem, evolution is driven largely by the needs of major contributors who use Kubernetes at scale. Special-interest groups regularly align on roadmaps. If a feature is needed and makes sense within Kubernetes, it will likely get built. The direction follows real-world demand.

Demand for open-source solutions keeps growing. Why is that?

Aarno: One major factor is digital sovereignty. Organizations want control over their data and tooling. Open standards reduce vendor lock-in and increase portability. Another factor is the business model. Open-source software is often free to try, which lowers the adoption barrier. Companies can later pay for support or services if needed. Finally, open source offers transparency and auditability, which is increasingly important for software supply chain security.

Armin: It’s also a self-reinforcing system. You can build a business on top of open source even without major funding. You contribute back, the ecosystem improves, and everyone benefits. That dynamic accelerates innovation.

Why should Swiss Kubernetes users be active in the community?

Aarno: If you rely on the technology, it’s smart to contribute. Your teams will discover bugs or new use cases. Fixing them upstream benefits everyone—including you. For companies like ours, it’s also a talent magnet. Engineers want to work on open source. It strengthens employer branding and aligns with our values of transparency and collaboration.

Armin: And sometimes you simply have to contribute. If you hit a very specific problem and no one else has solved it, you either build it yourself or wait indefinitely. Keeping fixes private often leads to maintenance headaches. Contributing upstream usually pays off in the long run.

If you could give one piece of advice to someone starting with Kubernetes today, what would it be?

Aarno: Focus less on memorizing commands and more on understanding cloud-native principles: automation, GitOps, observability, and security fundamentals. Understanding why platforms are designed the way they are is far more valuable than learning YAML syntax by heart.

Armin: If you’re serious, try to work at a company that already uses Kubernetes. Hands-on exposure is incredibly valuable. Otherwise, experiment on your own or attend community events. Even smaller conferences can be very helpful.

Are there common misconceptions beginners should watch out for?

Armin: Especially for management: Kubernetes will not solve all your problems. It’s just one part of a larger architecture and organizational setup.

Aarno: I’d add that Kubernetes does not automatically reduce complexity. It shifts complexity into automation and platform design. When implemented well, operations become simpler—but without clear architecture, it can become overwhelming. And importantly, Kubernetes is not a purpose in itself. It’s just a platform to run other software. Without a clear goal and workloads to support, running Kubernetes alone provides no value.