Fosdem is the biggest open source conference in Europe. Fosdem is free in both senses of the word (free as in free speech and free as in free beer), there is no fee to pay in order to attend. Devs, Ops and DevOps people come here to see what’s new, to collaborate, share ideas and have fun.
Taking off
The mountain silver peaks around my hometown slowly faded into the sunset as I flew off on Friday evening with the goal to attend Fosdem which is taking place in Brussels for a few years now. The flight was generally OK although I got a little worried when my flight from Munich got delayed. Fortunately, the pilots made up for the delay during the flight resulting in my timely arrival. I arrived in “Place de l’Agora” at 23:30 on Friday and immediately got in touch with the night life of Brussels which is not without effervescence. Aa I arrived too late to attend the beer event that had been hosted by the Fosdem staff I decided to stay in my hotel room where I ate a sandwich and drank a couple of beers that lured me gently into a deep sleep. The following day Fosdem was about to start.
At Fosdem, the open source bazaar
On Saturday morning we jumped on the bus that took us to ULB (Université Libre de Bruxelles) where Fosdem 2019 was going to unfold. The fact that a huge number of people were attending was letting itself felt already because as more and more people got on the bus, we were getting packed tighter than a can of sardines. On arrival at ULB the bus almost emptied and we headed over to the reception area. Here we already came in contact with many open source software organizations representatives which were happy to have conversations with you about their projects and also handed out stickers, shirts, cups and other stuff with their brands on them, some for small donations (most of these OS organisations run on donations), others for free. Some of the ones that were present this year were: Apache, Debian, Centos, Python, Percona, Grafana to name just a few. At Fosdem is where you really feel like there is this bazaar of open source but on so many layers. There is the physical, real layer in which there actually is this bazaar of open source organizations that tend to software projects. These software projects themselves are built in the bazaar style which made open source so successful as a software development paradigm. There is also this flat bazaar of talks that you can attend at your own choosing (if the rooms are not full already ) about a bazaar of technologies ranging from Baremetal to Kubernetes, C to Python that convey a bazaar of information from which you can take what you want just like in a real bazaar. So, if you were to write a class that would describe a bazaar of open source technology, organizations and knowledge, then Fosdem would be an instance of that class.
Fosdem through my lenses
As a system engineer, I mostly attended the “Infra management” and “Containers” devrooms. What I can say is that it is obvious, only from the sheer number of talks about it, that Kubernetes has become the primary container orchestration and management platform. It is already added as a service by most cloud providers: AWS, Azure, Google Cloud, IBM Cloud etc. but if you would still like to install and manage your own cluster over multiple cloud providers there is an easier way to do it now with Kubespray. Kubespray creates complete k8 clusters according to your specs and all you have to provide to it are the VMs you want to install on. Kubespray uses Ansible to do the actual installation via Ansible playbooks. This a very powerful solution which can lead you to achieve complete cloud layer abstraction, that is you can have k8 clusters on multiple cloud providers and many AZs and just balance the load between them. A demo has been presented on how Kubespray was used to deploy k8 clusters in many locations in the world, much more than any one cloud provider can offer, using the Openstack public cloud marketplace. Another great use case for Kubespray is creating k8 clusters for testing and POCs.
Except for the use case above, k8 or other cloud services can be spawned on most public clouds and the thing that keeps everything together and abstracts cloud providers is Terraform. Terraform is getting more and more traction precisely because the need has shifted from VMs to containers and so via terraform you can order managed container services from most big cloud players. Although terraform does not allow for config management natively this feature is not needed anymore if you use a managed k8 service as a runtime for your app and have a deployment pipeline set up so that it will build the app from a container image in a registry. So, in my opinion, we will see an accelerated shift from tools like Chef, Puppet, Salt, Ansible to Terraform as the need for cloud containers services grows and the need for virtual machines services shrinks.
And if the containers are the present, then containers with a kernel are the future. Practically kernel containers are very lightweight VMs. So light that they boot up in 125 ms! Firecracker is the new virtualization technology that supports these microVMs that boot up containers just as fast but have the security of VMs because they are not sharing a kernel with other containers. It uses KVM as underlying hypervisor. Firecracker now seems pretty new and not very well integrated but, in the future, the devs are working to integrate it with Kubernetes. When that will be done, I think that we will again see a shift from namespace containerization, like we have today, to kernel containerization or microVMs. Nevertheless, Kata containers (project managed by Openstack foundation) seem to be closer to an integration with k8.
Something really interesting is a kernel functionality that we could use to get low level statistics in Linux and therefore from containers, as containers share the Linux host kernel. This is called eBPF. eBPF has been in the kernel for some time now but it is recently that more functionality has been added to it and some userspace tools have been developed like BPFtrace CLI utility. It is not yet included in Linux distros by default and it depends on a kernel > 4.9. But the real-world applications of this are very useful and not to mention cool. The eBPF takes a filter and can aggregate stats for that filter in the kernel before printing the result. This means that you could get a histogram with write size of all the writes to a disk (or to a file) in a specified timeframe and there would be a negligible performance cost for that machine. You could also do some low-level security policies with eBPF. This is because seccomp, that is used to create the separation at a container level in docker for example, also uses eBPF to restrict access to various syscalls for a process. You could also create a keylogger or have low level access to kernel networking data like netfilter or conntrack. One very useful application for this is that you could filter network packets before they would be processed by netfilter which could increase the performance of that box a lot, or maybe even create a rule that blocks a flood without any performance impact.
By way of conclusion
These are only some of the technologies that were talked about at Fosdem but as you can imagine I cannot present all in a blogpost. It’s like you went to the Fosdem bazaar but had had only enough money for the ones above :).