KubeCon CloudNativeCon Europe 2023: A Galvanization
One of the keynotes at the KubeCon CloudNativeCon Europe 2023 started with the song Galvanize by The Chemical Brothers, which was not only appropriate with its energy and athmospherical suitability but also with its message: to galvanize the community, to shock or excite the community into taking action, or, to put in the terms used in this KubeCon CloudNativeCon edition: blooming the community. And that, indeed, was the overarching feeling I got from the conference. A blooming feeling. (See, I am not a snowflake, I am a flower.)
But this begs the question: what should the community be galvanized about?
We Cannot and Should not Avoid Talking About Sustainability
Sustainability, for one. Of course, when talking about sustainability there’s no way we can avoid the awkward question of justifying the in-person presence at a conference at a flying distance. The value the conference brings should justify the negative environmental impact of people having to travel to the venue. I feel like we are already in a better place when we are discussing these things openly and seeing the consequences of our actions. For example, our travel plan specified the exact CO2 impact that our travel produced. It is not to be denied.
So instead of just shrugging our shoulders about it (and emphasizing the words in the definition of ‘galvanize’): we should instead take action. This means actually doing something. Not just thinking about doing something. That something should have measurable outcomes on decreased environmental impact.
Galvanized by the Project Kepler
With this, I was excited to learn about the Project Kepler (Kubernetes), which monitors energy efficiency related metrics and exports them to Prometheus from which you can visualize them in eg. Grafana. With Kepler you can observe the energy consumption of your services, which brings a stronger sense of urgency to these matters. It is harder to deny the objective metrics that are produced than the vague feeling that we are harming the environment more than we should.
You could make the claim that the cost of your infrastructure is related to the consumption of energy and by cost-optimizing you would be also minimizing the negative environmental impact, but there are some complications about this line of logic. First, we are often not very good at cost-optimizing per se when we are dealing with capacity that we do not pay from our own pockets directly. Second, the relationship with the cost and the environmental impact is not completely direct. Some types of computation impact the environment more negatively than others. You will want to see the direct environmental impact. Use Kepler or something similar.
(Note also that you shouldn't cling too much into the idea that a datacenter claims to buy 100% carbon neutral energy. We, as the IT industry, are a part of the whole and cannot dismiss our responsibility as energy consumers. We should aim to consume less energy even if the datacenter provider actually buys carbon neutral energy.)
Openness makes communities bloom
For a first-time KubeCon CloudNativeCon attendee, it is really an overwhelming feeling to directly observe the blooming of the community. The amount of people, projects, APIs, tinkerings, experimentations, and commercial endeavours is just perplexing. We’ve all seen the Cloud Native Landscape picture, but looking at it doesn’t have the same impact compared to the feeling you have when attending something like the KubeCon CloudNativeCon. There, it is on your visual field in a more visceral way.
We should remind ourselves that this blooming doesn’t come without significant effort and careful planning. We should also remind ourselves of the success of the projects like Kubernetes and others under the Cloud Native Computing Foundation umbrella. They are not successful despite being open and community-involved but because of that. The philosophy, the design choices, and the API-driven nature of Kubernetes and related projects have enabled a blooming community. The community should savor that. Favor open projects, favor open standards. It is not even that difficult at all times.
Which brings me to one of the exciting talks I attended. Martin Villumsen and Michael Vittrup Larsen from Denmark’s TV 2 described how they utilized the new Gateway API in their talk Beyond Gateway API: Building a Cloud Agnostic Gateway Controller for Self-Service Network Configuration. Their goal is to drive the cluster management in their environment towards GitOps and more declarative approach by leveraging the Gateway API. They have built their own controller that produces a declarative configuration of a service through the use of templating and Kubernetes APIs. Check it out.
So what about security?
Security was very visible as a topic in this KubeCon CloudNativeCon. Not only were there a lot of presentations about security, but also the sales presentation floor was blooming with security products, and the project booths too. I welcome the attention to security. However, there’s a real risk when adopting a more-tools-is-better attitude towards security. Tools have their uses and appropriate contexts, but there’s much untapped potential in embracing simplicity and fundamental principles too.
In this vein of thinking, I was stoked to attend the Zero Privilege Architectures talk by Thijs Ebbers & Diana Jordan. Their argument, and approach, was not to bolt more security tools but to design systems securely, which often means removing stuff, not adding more. One of the main building blocks of their architecture was extending the idea of immutable infrastructure to its logical and practical conclusion. I recommend checking their presentation when it becomes available.
I would only add to their ideas that when you do have the system designed securely and it is as simple as reasonably possible, then you can add eg. detection tools, because you then know that any detected activity will be extremely suspicious, because your systems are very strict in what is allowed and possible. Signal-to-noise ratio of security tools improves significantly when your system is simple and restricted.
Reflections on Understanding Stuff Better
One theme with Thijs’ and Diana’s talk was also the urge to build from and understand first principles. This desire to understand our tools better was also evident in the delightful and insightful Malicious Compliance: Reflections on Trusting Container Scanners talk by Ian Coldwater, Duffie Cooley, Brad Geesaman and Rory McCune. They have dug deeper into how container scanners work and have found that they are quite easily fooled into thinking that the container image is free from vulnerable components (when the opposite is true).
Here, of course, we need to keep our heads cool and realize, like the authors emphasized, that the lesson from talks like theirs is to understand what the role of a specific tool is in your context. Also, the more you understand how the tools you use actually work, the more you are able to use the contextual information for your own advantage.
The Community Blooms Only by its Members
Finally, I and others from our team felt the urge and duty to contribute back to the Kubernetes and Cloud Native community. We enjoy the benefits of the openness of this community by running these products and services by ourselves and by services that have been built on the open standards and APIs by the same community. The community is huge, but it doesn’t mean the vast majority could bury their head in the sand and just reap the benefits. The community needs the contributions. It can be code, it can be testing, it can be advocacy, it can be documentation. Whatever suits best to your strengths.
Just do it.