By Romain Boulanger.
Just like last year, I had the opportunity to be a speaker at Voxxed Days Luxembourg on a GitOps topic entitled “Argo et Flux sont dans un Kargo, lequel tombe à l’eau ?”.
I’m very excited to share the first day of this conference. The conference took place over two days, on 20 and 21 June 2024 respectively.
As a reminder, this event brings together a multitude of enthusiasts on a number of themes: software development, Agile methods, Cloud, Big Data, security, DevOps, automation, etc. Whether you’re a beginner or a senior, there’s always plenty topics to discover!
There are several formats on the menu: Keynote at the beginning and end of the day, University (2 hours), Conferences (50 minutes), Tools in Action (25 minutes) and Launch Talk (15 minutes).
In the rest of this article, we will go through the different keynotes and conferences I attended.
By Pierre Henriquet
We began with a totally fascinating opening keynote on computer achievements in the discovery of space.
The aim was also to talk about the bugs that have caused some damage in the loss of communications with robots sent into space.
This frantic race to discover space began in 1957 with the Sputnik satellite, which was the first machine to break through the atmosphere.
Later, Viking 1 was sent to discover the surface of Mars, including the presence of Mount Olympus and the largest canyon, Valles Marineris, in 1979.
Unfortunately, the programme came to an end in 1982 following an update designed to reduce battery use. During the update, the data used to point the antenna towards the Earth’s surface was permanently overwritten, rendering the system completely inoperable.
Another computer error occurred with the Mars Climate Orbiter programme between 1998 and 1999, the aim of which was to study the planet Mars. The only problem was that the probe was supposed to reduce its distance from orbit by passing through the Martian atmosphere, so as to gradually slow down and save fuel.
The mistake that was made was in subcontracting a NASA component to Lockheed Martin, which worked in pound-force, whereas NASA works with the international system, i.e. in Newton.
Pierre went on to talk about a number of discoveries, including the moon Titan, a satellite of Saturn, which bears a striking resemblance to the Earth. The aim is to go there in a few years’ time with robots capable of studying how the moon works.
Speaking of robots, there are several types, such as the Canadarm 2 from 2001 on the International Space Station, or the Robonaut 2 from 2011, which helps astronauts with tasks that require them to carry heavy equipments.
Finally, Pierre concludes with the Voyager probes, a programme launched in 1977 to explore the solar system. Two probes are involved in this programme, both equipped with microcontroller chips, 70KB of memory and computer code written in FORTRAN 5!
It has to be said that these two probes are still in operation despite some recent setbacks linked to several data corruptions. For example, they had to be patched 24 billion km away with a data rate of 20 bytes per second and a ping of 45 hours! Totally incredible when you think about it…
By Henri Gomez
Henri Gomez presented a vision of Site Reliability Engineering (SRE) that goes beyond conventional wisdom.
For Google, SRE is a software engineer who creates value through systematic automation. Henri stressed the importance of the 4 golden signals: error, traffic, saturation and latency, the last of which is essential for validating quality of service.
The SRE’s missions include tooling, observability (with an emphasis on good logging), and architecture. However, new missions are emerging, such as performance management, capacity planning and FinOps.
Henri then addressed several myths surrounding the SRE:
The myth that the Google-style SRE is applicable everywhere, pointing out that Google is still a tech company that makes tech products for tech people. So there are things that need to be adapted to suit different contexts;
The myth of the “superhero” who knows everything, whereas SREs have expertise in a complex technical stack but cannot master all languages, frameworks and tools;
The myth of the “bug detector”, emphasising the importance of SLIs (Service Level Indicators) and collaboration with development teams;
The myth of the “ultimate shield”, pointing out that security is everyone’s business, even if certain areas such as pentesting remain specialised;
The myth of “the ops guy who does the dev”, pointing out that SREs are not experts in every field, but can help developers find problems right down to the code.
Henri also clarified the common confusion between SRE and DevOps, the latter being more focused on infrastructure creation and automation.
To succeed as an SRE, you need a repeatable and predictable environment, a good understanding of SLAs, SLIs and SLOs, and you need to listen to build resilience.
The organisation needs to balance junior and senior staff, with a well-defined scope. In addition, soft skills are crucial: listening, communicating, the ability to convince and to learn.
Finally, Henri recommends gradually adding tools in line with the issues encountered, rather than implementing everything at once.
This presentation offers a balanced and realistic vision of the role of the SRE, demystifying some stereotypes ideas while underlining the importance of this function in modern organisations.
By Dotan Horovits
The presentation uses Jenkins as an example to illustrate the importance of observability in CI/CD pipelines. Dotan highlights several crucial questions to ask about pipeline failures, such as:
The focus is on DORA metrics for DevOps, including frequency of deployment to production and Lead Time for Change.
The lack of observability makes it difficult to assess these metrics. Dotan proposes a four-step approach to improving observability:
He made it clear that CI/CD is not limited to the tool used and recommends using tracing to measure agent performance.
To do this, it is possible to use OpenTelemetry, by configuring the associated Jenkins plugin, to store the data in the Jaeger backend.
To take this a step further, Dotan suggests tracing tools such as Maven for recovery and dependency management so as to study any faults that might occur during this phase on the performance of CI/CD agents.
He also recommends monitoring the CI/CD environment, i.e. the infrastructure, by collecting metrics with Telegraf and the Prometheus plugin, then visualising them with Grafana.
Finally, Dotan explains that it is fundamental to treat CI/CD as an integral part of production, applying the same observability practices to it.
By Mehdi Boissat-Bron
The presentation begins with a reminder of Agile, mentioning the history with the release of the Agile Development Manifesto in 2001.
Mehdi then goes on to review the major sessions specific to the SCRUM methodology, such as the Sprint Planning Meeting, Daily Standup Meeting, Backlog Refinement, and so on.
An important point raised in the estimation of team members’ tasks is not to use time as a measure, but rather points of complexity to avoid putting unnecessary pressure on oneself in relation to a notion of time.
Furthermore, in SCRUM, the role of the Scrum Master is compared to that of an air traffic controller, underlining its importance in coordinating and facilitating the process of delivering new functionalities.
A good practice recommended by Mehdi is to have a technical refinement backlog session with the SCRUM team to be much more efficient during the actual refinement backlog. This session aims to:
The presentation concludes with the importance of knowing how to adapt to the context, recalling one of the fundamental principles of agility.
By Valentin Dumas
This presentation focuses on the use of AI for test generation, with an initial emphasis on unit tests. Valentin discusses the issues of code quality and regression, highlighting the importance of these aspects in the development process.
AI can be particularly effective in generating unit tests based on code that has already been written, thanks in particular to the Codiumate tool, which retrieves the context of the project by transmitting requests to ChatGPT 3.5 or 4.
However, there are a few limitations with integration tests: AI is less effective for this type of requirement, requiring more human intervention to enrich the tests generated. This is certainly due to the different interactions between components.
This approach aims to improve code quality and reduce the risk of regression, while optimising developer time in the testing process without neglecting human interaction to define code coverage.
By Denis Germain
The presentation begins with a reminder of what Kubernetes is, so that we have a clear definition of the tool.
Denis will then create his own Kubernetes cluster from scratch to explore all the components in detail. To add a little layer of complexity, he’s using alpha and release candidate components.
A few pieces of infrastructure are already deployed upstream, such as the virtual machines, certificates and binaries needed to install the cluster.
Each component is installed following these steps:
This presentation provides an in-depth understanding of the Kubernetes architecture, highlighting the role and importance of each component in the operation of a cluster.
By me 🙂
Here’s a summary of the topic I had the opportunity to present this year. It deals with GitOps and more specifically GitOps within Kubernetes.
Thanks to the Pull approach, it’s possible to take advantage of the Kubernetes reconcialisation loop, which allows us to synchronise the content of the cluster with the source of truth associated with Git that contains our objects to be deployed, using an operator such as Argo CD.
There are two tools on the market that are currently very popular with this approach: Argo CD and Flux CD. Each has its own strengths:
Argo CD has a GUI delivered by default where you can view what has been deployed in the cluster. It is possible to use custom resources (CRD) to simplify the deployment of our resources, such as AppProject, Application or ApplicationSet.
Flux CD has controllers for managing the lifecycle of applications deployed with Helm, Kustomize or Terraform, for example. It is also possible to add more controllers to extend the operator. Finally, Flux’s approach is quite native to Kubernetes concepts, especially in terms of permissions management.
In addition to this information, which allows you to choose between these two tools, how do you use both? That’s where I introduced you to Flamingo, an open-source tool that combines Argo CD and Flux CD, with the option of choosing one or other of the reconciliation loops to suit your needs.
The second part of this presentation focuses on managing environments using the GitOps approach, using files or folders to represent environments within a specific branch.
However, the GitOps world lacks tools to provide a centralised view orchestrating changes between environments. That’s why Kargo, an open-source tool still under development, has great potential for solving this problem, especially with its unified view and the promotion of changes between environments.
When we talk about tech, it’s important to choose the right tool for your needs, without wanting to use everything at the risk of going down the wrong path. Finally, it’s always important to keep an eye out for new tools that can provide solutions to existing problems.
By Grace Jansen
To begin with, Grace Jansen makes an analogy between medical diagnosis and the analysis of cloud-native applications to detect problems. She emphasises the importance of observability, comparing it to the medical examination of a patient.
This observability is based on three main pillars:
It relies on three key stages to be used effectively:
To meet this need for observability, Grace highlights the use of MicroProfile for Java, which offers ready-to-use cloud-native APIs.
A large part of the presentation is devoted to OpenTelemetry, which is described as :
Finally, Grace points out that OpenTelemetry is not an observability backend per se, but rather a tool for collecting and standardising data. She also mentions Openliberty.io, which is an IBM open-source project that quickly creates cloud-native applications in Java.
By Johannes Dienst
The conference highlights the crucial importance of documentation to the success of a product.
Johannes insists that documentation is the most essential resource for developers.
When creating documentation, he lists a number of mistakes to avoid, such as the absence of a search bar, examples of API methods, a getting started guide and explanations of how to configure the environment to use a tool or product.
It recommends using intuitive rather than aesthetic documentation and limiting the number of sub-elements to 5 per category to encourage reading.
Segmenting documentation according to the audience and the specific needs of end users is also crucial.
In the rest of his presentation, Johannes encourages the Docs as Code approach, using tools such as Markdown combined with Git to take advantage of revisions and versioning.
Finally, he also recommends tools such as Docusaurus to create documentation sites, or Vale to check for spelling and grammar.
By Pierre Henriquet
We finish with the closing keynote, which deals with a topic which drifts from computing but keeps our scientific minds awake. The goal is to pinpoint the differences between fusion and fission to produce energy with the various scientific advances in this field.
A closing keynote just as exciting as the first!
The fact that I’ve been chosen again for this 2024 edition made me discover a very diverse range of topics, from Agile to test generation using artificial intelligence.
I was really pleased to be able to present my talk on the state of the art of GitOps in Kubernetes, and to introduce you Flamingo and Kargo!
Thanks again to the organisers for this great event!