Talks

Avez-vous déjà entendu “ça doit fonctionner 24/7”, “Je veux 100% de dispo”, pour finir avec “en réalité, une VM ça sera largement suffisant” ? Ou au contraire “Pas de SLA, ma plateforme n’est pas critique, il faut juste qu’elle tourne impérativement le premier du mois à 6h54 précises” ?

Si ces situations sont votre quotidien, ne perdez pas espoir ! Que ces critères techniques (Non Functional Requirements) soient explicites ou non, ils sont la clé qui vous permettra de concevoir une architecture en adéquation avec le besoin client.

En se basant sur deux exemples fictifs (toute ressemblance avec la réalité serait bien évidemment fortuite, ou pas), nous verrons comment déjouer les pièges de la surqualité, et comment mettre en place une démarche pragmatique d’identification de la bonne architecture pour le bon besoin métier.

À l’issue de cette présentation, nous saurons comment identifier ces fameuses NFRs qui nous aiderons à concevoir de meilleures architectures en évitant la sur-complexité !

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.

Quand on souhaite publier des APIs avec par exemple, une solution d’API Management, on évoque régulièrement le versioning. Cette pratique répond à des contraintes projet mais apporte malheureusement son lot de complexité.

Imaginez, vous travaillez sur un produit qui expose des APIs à plusieurs clients. Vous devez leur proposer des évolutions et nouvelles fonctionnalités tout en maîtrisant l’existant. Quelle stratégie adopter ? Quelles solutions techniques peut-on mettre en place simplement ?

Dans cette présentation, vous (re)découvrirez des conseils que j’ai pu mettre en pratique et qui m’ont aidé lors de mes derniers projets.

Nous aborderons, au travers d’un cas concret la stratégie à mettre en œuvre, les différentes possibilités d’implémentation ainsi que leurs contraintes.

À l’issue de cette présentation, nous aurons une vue complète et objective des manières d’appréhender le versioning d’APIs.

Quand on souhaite publier des APIs avec par exemple, une solution d’ API Management, on évoque régulièrement le versioning. Cette pratique répond à des contraintes projet mais apporte malheureusement son lot de complexité.

Imaginez, vous travaillez sur un produit qui expose des APIs à plusieurs clients. Vous devez leur proposer des évolutions et nouvelles fonctionnalités tout en maîtrisant l’existant. Comment faire évoluer et proposer vos APIs à certains clients sans pénaliser les autres? Quelle stratégie adopter? Quelles solutions techniques peut-on mettre en place simplement?

Lors de cet atelier, vous (re)découvrirez et mettrez en pratique des conseils que j’ai pu mettre en oeuvre et qui m’ont aidé lors de mes derniers projets.

Au travers d’un cas concret basé sur une architecture microservices, nous définirons la stratégie à mettre en œuvre, les différentes possibilités d’implémentation ainsi que leurs contraintes. Nous les challengerons ensuite en apportant différentes évolutions (ajout d’un nouveau client ou de nouvelles fonctionnalités).

A l’issue de cet atelier, nous aurons une vue complète et mis en pratique différentes manières d’appréhender le versioning d’APIs.

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!