Last year, at the end of winter, we wrote our impressions of the trends and evolution of infrastructure and configuration management after attending FOSDEM and CfgMgmtCamp. We’re at it again, but with Kubecon this year, the biggest cloud native computing conference.

If you’ve never heard of cloud native computing before, it has a number of definitions online, but the simplest one is that it’s mostly about Kubernetes.

Kubecon is a huge event with thousands of attendees. The conference spanned several levels of the main convention center in Paris, with a myriad of conference rooms and a whole floor for sponsor booths. FOSDEM already felt huge compared to academic conferences, but Kubecon is even bigger.

Although the program was filled with appealing talks, we ended up spending most of our time chatting with people and visiting booths, something you can’t do as easily online.

Nix for the win

The very first morning, as we were walking around and waiting for the caffeine to kick in, we immediately spotted a Nix logo on someone’s sweatshirt. No better way to start the day than to meet with fellow Nix users!

And Nix was in general a great entry point for conversations at this year’s Kubecon. We expected it to still be an outsider at an event about container-driven technology, but the problems that “containers as a default packaging unit” can’t solve were so present that Nix’s value proposition is attuned to what everyone had on their minds anyway. In other words, Nix is now known enough as to serve as a conversation starter: the company might not use it, but many people have heard about it and were very interested to hear insights from big contributors like Tweag, the Modus Create OSPO.

Cybersecurity

Many security products were represented. Securing cloud-native applications is indeed a difficult matter, as their many layers and components expose a large attack surface.

For one, the schedule included a security track, with a fair share of talks being about SBOMs tying back into the problem of containers that ship an opaque content without inventory. Nix, as a solution to this problem, was a great conversation starter here as well, especially for fellow Nixer Matthias, who can talk for hours about how Nix is the best (and maybe only) technology for automatically deriving complete SBOMs of a piece of software, in a trustworthy manner. Our own NLNet-funded project genealogos, which does exactly that, is recently getting a lot of interest.

Besides the application code and what goes in it, another focus was avoiding misconfiguration of the cloud infrastructure layer, of the Kubernetes cluster, and anything else going into container images. Many companies propose SaaS combinations of static linters scanning the configuration files directly with various policy rules, heuristics and dynamic monitoring of secure cloud native applications. Our configuration language Nickel was very relevant here: one of its raisons d’être is to provide efficient tools (types, contracts and a powerful LSP) to detect and fix misconfigurations as early as possible. We had cool conversations around writing custom security policies as Nickel contracts with the new LSP background contract checking (introduced in 1.5) reporting non-compliance live in the editor — in that light, contracts are basically a lightweight way to program an LSP.

Internal Developer Platforms (IDPs)

IDPs were a hot topic at Kubecon. Tweag’s mission, as the OSPO of a leading software development consultancy, is to improve developer experience across the software lifecycle, which makes IDPs a natural topic for us.

An IDP is a platform - usually a web interface in practice - which glues several developer tools and services together and acts as the central entry point for most developer workflows. It’s centered around the idea of self-service, not unlike the console of cloud providers, but configurable for your exact use case and open to integrate tools across ecosystem boundaries. We already emphasized this emerging new abstraction in last year’s post. Example use cases are routinely deploying new infrastructure with just a few clicks, rather than requiring to sync and to send messages back-and-forth to the DevOps team. IDPs don’t replace other tools but offer a unified interface, usually with customized presets, to interact with repositories, internal data and infrastructure.

Backstage, an open-source IDP developed by Spotify, had its own sub-conference at Kubecon. Several products are built on top of it as well: it’s not really a ready-to-use solution but rather the engine to build a custom IDP for your company, which leaves room for turnkey offers. We feel that such integrated, centralized and simple-to-use services may become a standard in the future: think of how much GitHub (or an equivalent) is a central part of our modern workflow, but also of how many things it frustratingly can’t do (in particular infrastructure).

Cloud & AI

Many Kubernetes-based MLOps companies propose services to make it easy to deploy and manage scalable AI models in the cloud.

In the other direction, with the advent of generative AI, there was no doubt that we would see AI-based products to ease the automation of infrastructure-related tasks. We attended a demo of a multi-agent system which integrates with e.g. Slack, where you can ask a bot to perform end-to-end tasks (which includes interacting with several systems, like deploying something to the cloud, editing a Jira ticket and pushing something to a GitHub repo) or ask high-level questions, such as “which AWS users don’t have MFA enabled”.

It’s hard to tell from a demo how solid this would be in a real production system. I also don’t know if I would trust an AI agent to perform tasks without proper validation from a human (though there is a mode where confirmation is required before applying changes). There are also security concerns around having those agents run somewhere with write access to your infrastructure.

Putting those important questions aside, the demo was still quite impressive. It makes sense to automate those small boring tasks which usually require you to manually interact with several different platforms and are often quite mechanical indeed.

OSPO

We attended a Birds-of-a-Feather session on Open Source Program Offices (OSPO). While the small number of participants was a bit disappointing (between 10 and 15, compared to the size of the conference), the small group discussions were still engrossing, and we were pleased to meet people from other OSPOs as well as engineers wanting to push for an OSPO in their own company.

The generally small size OSPOs (including from very large and influential tech companies) and their low maturity from a strategic point of view was surprising to us. Many OSPOs seem to be stuck in tactical concerns, managing license and IP issues that can occur when developers open up company-owned repos. In such a situation, all OSPO members are fully occupied by the large number of requests they get. But the most interesting questions: how to share benefits and costs by working efficiently with open source communities, how to provide strategic guidance and support, and how to gain visibility in communities of interest were only addressed by few. A general concern seemed to be generally a lack of understanding by upper management about the real strategic power that an OSPO can provide. From that perspective, Tweag, although a pink unicorn as a consulting OSPO, is quite far on the maturity curve with concrete strategical and technical firepower through technical groups, and our open-source portfolio (plus the projects that we contribute to but aren’t ours).

Concluding words

Kubecon was a great experience, and we’re looking forward to the next one. We are excited about the advent of Internal Developer Platforms and the concept of self-serving infrastructure, which are important aspects of developer experience.

On the technological side, the cloud-native world seems to be dominated by Kubernetes with Helm charts and YAML, and Docker, while the technologies we believe in and are actively developing are still outsiders in the space (of course they aren’t a full replacement for what currently exists, but they could fill many gaps). I’m thinking in particular about Nix (and more generally about declarative, hermetic and reproducible builds and deployments) and Nickel (better configuration languages and management tools). But, conversation after conversation, conference after conference, we’re seeing more and more interests in new paradigms, sometimes because those technologies are best equipped - by far - to solve problems that are on everyone’s radar (e.g. software traceability through SBOMs with Nix) thanks to their different approach.