1 Introduction

This article is the second part of a series on multi-cloud strategies. In the first part, we explored the reasons why organizations are adopting multi-cloud approaches and the benefits they can reap from it. Now, in this second part, we will dive into the practical aspects of implementing a multi-cloud strategy. We will discuss the key considerations, challenges, and best practices for successfully managing multiple cloud environments. I will also share some real-world examples and insights from my experience.

For a couple of years, I have been regularly working on designing and implementing cloud-native landing zones on multiple cloud providers at once. When I started designing such platforms, I was somewhat wary. The theory was slightly attractive: I could cherry-pick the best services from each cloud provider to build the ultimate architecture. Nevertheless, I held some reservations about operational concerns: complexity, costs, observability, alerting, and the like.

After reading the insightful Nicolas Martignole articles series (in French) on how Claude Code could streamline and accelerate coding through a terminal, I had the idea to test it by my own on specific (boring) use cases.

In nutshell, he used it to create a MVP in roughly 20H and explains how he handled it.

I had the opportunity to test Google Code Assist. I then decided to boost my terminal with Gemini Cli instead of Claude Code.

1 Introduction

Last week, I had the opportunity to lead a workshop on Software Architecture at Riviera Dev.

With the help of my colleague Yassine Benabbas, more than sixty participants learned and improved their design and architecture skills through a three-hour Architecture Kata based on a (not so) real-life use case.

If you are not familiar with Architecture Katas, I suggest you take a look at the following links:

• A video captured during a conference and the slides where I introduce the concept.
• An article from the Worldline Tech Blog.

In this article, as a follow-up, I will present some of the solutions proposed by the participants and then share my own proposition.

1 Introduction

Recently, I had the opportunity to participate in JChateau and Devoxx France. At these two events, I organized and facilitated roundtables on how to onboard, mentor, and manage young developers to help them grow and improve over time.

For many years, I have been managing young developers, including trainees and developers with less than one year of experience. Additionally, I have been involved in various mentoring programs. For example, I have helped young students prepare for their first interviews and guided them to succeed.

Most workloads we deploy on Kubernetes are deployments. They dynamically manage Pods & Replicasets.

However, it may be useful to manually handle the identity of the Pods and their scalability. For instance, if we want to install a distributed database such as MongoDB on top of Kubernetes, it would be mandatory to manually set the names to set up the cluster and its discovery.

For that purpose, we may use StatefulSets.

After nearly a decade of coding with Spring Boot, I decided to switch to Quarkus (and was quite late to the party) for a workshop about how to embrace the API-First approach in Java.

A few years ago, I had already given it a spin. I was not entirely convinced of the value of switching. By the way, I presented in 2022 a talk about that topic with a former colleague of mine Jean-François James. We compared both of the two solutions and concluded the functionalities provided by Spring Boot & Quarkus were sightly similar.