Talks

Today, most of our applications are hosted in the cloud. But what if we leveraged multiple providers for a single application or platform?

The theory is attractive: cherry-picking the best services from each provider to build the ultimate architecture. The reality? Cloud providers that are “more equal than others” and a labyrinth of technical complexities—where network latency, fragmented data, and incompatible APIs threaten both your SLAs and your peace of mind.

In this session, we will tackle the challenge of designing a multi-cloud platform based on a real-world use case.

From defining bounded contexts to addressing production hurdles, security, and API design, we will navigate the pitfalls inherent to this architecture while highlighting essential best practices.

Finally, we will explore how a thorough understanding of customer needs and a pragmatic risk analysis can guide design choices to deliver a coherent, end-to-end vision.

Shipping code is good. Shipping a new feature without breaking the rest of the system is even better!

Every release today brings the risk of regressions or bad interactions between existing and new functionality. And what about deploying to only a subset of users? That’s even trickier.

Feature flagging decouples code deployment from feature activation, allowing you to turn blocks on or off at runtime without redeploying.

Fortunately, this practice has been growing with open‑source tools and solid engineering habits. However, beyond simple if‑then‑else, most available solutions are proprietary, heavy or costly to set up.

OpenFeature, a CNCF project, offers an open specification for unified feature flagging, usable both server‑ and client‑side regardless of the backing store.

In this workshop we’ll add a new feature to an existing Java/Angular application and drive its activation through feature flags. Along the way we’ll cover key topics: error handling, A/B testing, progressive rollouts, targeting and observability.

By the end, you’ll know how to deliver faster, safer and with confidence.

We often oppose Code-first to API-first approaches. Most of the coders prefer the first one because it is more code centric, and the documentation is automatically generated. In fact, the latter is often perceived by them as a “boring-documentation-first” development.

However, the API-first design and implementation offer many benefits: streamlining your APIs, tackling the complexity and most of all, boosting the developer experience of your customers.

Through practical feedback we will cover how to implement API-first Approaches with the associated practices and tooling. We will then pinpoint the main difficulties to struggle with.

We will therefore see how to tackle this huge challenge: improve the quality of your API, increasing the adoption of your APIs by your customers, and most importantly, make your developers love the Documentation Code First approach!

Êtes-vous confronté au défi d’encadrer et de développer les compétences des jeunes développeurs ? En tant que lead développeur ou développeur expérimenté, vous êtes souvent amené à guider techniquement de nouveaux talents. Mais quelle approche adopter pour assurer leur progression de manière optimale ?

Je participe depuis plusieurs années à différentes initiatives de mentorat et d’accompagnement de jeunes développeurs. Je vous propose donc de partager les bonnes pratiques que j’ai pu mettre en œuvre ainsi que les écueils que j’ai rencontré.

Nous saurons donc à la fin de cette présentation comment intégrer et rendre autonomes les nouveaux arrivant.es le plus efficacement possible.

Imagine it’s Friday afternoon. You’re looking forward to enjoying your weekend when an Ops engineer forwards you a blocking issue with an HTTP 500 error.

He couldn’t pinpoint the root cause due to a lack of contextual information. After a few hours, you finally manage to identify it by reproducing and debugging it on your computer.

If you often encounter such issues, it likely means that you may have overlooked developing one of the most important features of your application: Observability!

In this workshop, we will implement logging best practices and cover the entire observability stack from libraries to storage backend and visualization tools based on OpenTelemetry and the Grafana Suite (Tempo, Prometheus, Loki, Grafana). We will gain an understanding of how Java Developers can make Ops their best friends by making our Java application more reliable and production-ready!

• Slides
• Workshop

Have you ever heard phrases like “it must work 24/7,” “I want 100% availability,” only to end up with “in reality, a VM will be more than sufficient”? Or conversely, “No SLA, my platform is not critical, it just needs to run precisely at 6:54 AM on the first day of the month”? If these situations sound familiar, don’t miss out! Whether these Non-Functional Requirements are explicit or not, they are the keystone of any architecture aligned with client needs.

Drawing on two fictional examples (any resemblance to reality is purely coincidental, or maybe not), we will explore how to navigate the pitfalls of overengineering and establish a pragmatic approach to identifying the right architecture for the right business need.

By the end of this presentation, we’ll know how to identify those elusive NFRs that will help us design better architectures while avoiding unnecessary complexity!

Designing a new platform is always tricky to set up.

How to start? What is the best strategy to adopt while designing a platform? What kind of architecture should we deploy: event streaming, orchestration, or choreography?

For a brand-new platform: “Donuts @ Home”, we will proceed a live architecture study.

After analysing the customer needs, brainstorming, and exchanging our ideas, we will choose among all the potential solutions the least worst option.

You will be asked to validate our design and the different implementation examples.

At the end of this talk, you will have tips and tricks for thinking about it and starting working on architecture studies in complete peace of mind.

When we want to publish APIs, for instance using an API Management solution, we regularly think about versioning.

This practice meets project management needs but brings a lot of complexity. Imagine, you work on a platform which exposes APIs to many customers.

You must bring new features while controlling the existing ones.

Which strategy to adopt? What are the potential technical tools and practices we could implement easily?

During this presentation, you will unlock the secrets of API versioning I have put in place and helped me during my last projects.

Through a real-life use case based on a microservices architecture, we will define the best strategy to put in place, the other potential ones and their constraints.

At the end of this presentation, we will have the big picture on the diverse ways of APIs versioning.

When we want to publish APIs, for instance using an API (Application Programmable Interface) Management solution, we regularly think about versioning.

This practice meets project management needs but brings a lot of complexity. Imagine, you work on a platform which exposes APIs to many customers.

You must bring new features while controlling the existing ones.

How to deliver new functionalities to specific customers without affecting the others?

Throughout this workshop you will (re)discover and apply advice I have put in place and helped me during my last projects.

Through a real-life use case based on a microservices architecture, we will define the best strategy to put in place, the other potential ones and their constraints.

We will challenge them implementing new features for a new customer in this application.

At the end of this workshop, we will have the big picture and put into practice diverse ways of APIs versioning.

Né au début des années 2000, le framework Spring a mis en avant la facilité de développement. Plus récemment, il a su s’adapter aux contraintes techniques liées aux applications cloud-natives.

De son coté, Quarkus est plus récent, il est né en 2019 sur la base de MicroProfile avec un objectif clair : tirer le meilleur parti des plateformes Kubernetes en se concentrant sur un démarrage rapide et une faible empreinte mémoire.

Nous avons donc un champion et un outsider ! Maintenant lequel choisir en fonction de vos besoins et votre contexte ? Spring ou Quarkus ?

Au travers d’une démonstration “live” nous présenterons un cas contret basé sur notre expérience. Ce dernier sera implémenté avec chacune des deux stacks.

Enfin, nous vous mettrons à contribution au travers de sondages pour dynamiser ensemble notre réflexion.

Kubernetes and cloud technologies are nowadays the new standard to deploy different cloud native applications: API, BATCHES, microservices and … monoliths! These technologies help to solve many issues but with some complexity. It could be difficult for developers and designers to identify the constraints of such architectures.

In this presentation, you will (re)discover ten tips and pieces of advice I applied and found useful in my last JAVA projects (Spring, JEE).

I will talk about:

Application ecosystem Choice of technical solutions Development K8S design constraints And more!