On parle souvent des comparaisons entre SQL et NoSQL mais cet article va plus loin en comparant les usages des 5 grandes familles de "Data Store"

• Base de données relationnelles (e.g. PostgreSQL)
• Base de données non-relationnelles (e.g. MongoDB)
• Base de données clé/valeur (e.g. Redis)
• Moteur de recherche (e.g. Elasticsearch)
• File de messages (e.g. Kafka)

Raft est un algorithme de consensus distribué très populaire qui permet de garantir la consistence d'un état au sein d'un cluster.

Il est utilisé dans des bases de données (CockroachDB, Mongodb) et dans d'autres produits comme Etcd.

Il couvre l'élection d'un master et la réplication de l'état sur chaque noeud.

Une explication très accessible du fonctionnement de Wine, le programme Linux qui permet de lancer des applications Windows.

Pour rappel, Wine n'est pas un emulateur mais "simplement" une traduction des appels systèmes Windows en appels système Linux.

Un article très complet sur l'API Gateway utilisé par Uber.

Ils ont développé leur propre API Gateway qui est en frontal de leurs micro-services écrits dans différents langages.
user access, etc

Les API Gateway peuvent être de simples routeurs mais peuvent aussi aller plus loin en incorporant de la logique métier, comme celle de Uber justement ("low level" vs "feature rich")

Dans le cycle de vie d'une requête, ils ont extraits 4 familles de composants:

• Protocol Manager: responsable de décoder et d'encoder (JSON, Thrift, Protobuf)
• Middleware: briques métier réutilisables (authentification, rate limiting, etc)
• Endpoint Handler: convertit la requête entrante dans le format attendu par le service backend
• Client: envoi la requête au service backend (validation, timeout, retries, etc)

Un retour d'expérience sur l'utilisation de Timescale DB pour ingérer et traiter de grosses séries temporelles.

TimescaleDB est une extension de PostgreSQL donc on retrouve facilement ses repères.

Une de leur feature extra est la compression optimisée des séries temporelles pour gagner jusqu'à 90% d'espace (!)

L'histoire d'une migration de AWS sur des serveurs custom.

Encore une fois, ce sont les transferts de données qui coutaient le plus cher à l'entreprise.

C'est très souvent un coût "caché" car très compliqué à évaluer.

Leur solution finale se base sur:

• serveurs bare metal pour le computing
• MinIO pour le stockage S3-like
• Cassandra pour la base de données

Les cloud comme AWS ont une tarification du traffic réseau et surtout du traffic réseau externe pour vous garder un maximum au sein de leurs écosystèmes.

Il vaut mieux se tourner vers des hebergeurs comme OVH ou Scaleway qui eux ne facturent pas le traffic https://links.aschen.tech/shaare/Q0rZJw

Meetup du CTO de BAM sur leur méthode pour réduire l'incertitude dans les cycle de développement.

En gros on est sur du développement centré autour des Epic (features) et non plus des Users Stories.

Mais surtout leur méthode implique de la modélisation de la logique applicative avec un subset de BPMN (ça ressemble à des diagrammes).

Ce langage commun utilisé par tous permet d'identifier les edge-case, de faire valider les features par le client, de discuter autour d'une feature, etc

Dans notre métier on a souvent envie de tout recommencer à 0, de faire un "gros refactor", de changer de stack technique.

Seulement si c'est fait pour les mauvaises raisons il y a de grandes chances que ça échoue et/ou coule le business.

Tant qu'il n'y a pas de contraintes techniques fortes il vaut mieux faire évoluer son legacy.

Un article explicatif sur le versionning d'API chez LinkedIn.

Conceptuellement, ils vont dupliquer les ressources en interne en incluant la version de l'API Foo => FooResource_v20220201

Ils ont ensuite un service de conversion qui va convertir les ressources dans le dernier format possible pour éviter d'avoir à dupliquer le code.

Un excellent document qui parle de tests unitaires et tests fonctionnels.

En règle général, il vaut mieux se concentrer sur les tests fonctionnels plutôt que les tests unitaires car ces derniers sont très couteux à maintenir, notamment leur de remaniement de l'architecture du code.

Quelques extraits:

Few developers admit that they do only random or partial testing and many will tell you that they do
complete testing for some assumed vision of complete. Such visions include notions such as: “Every line of code has been reached,” which, from the perspective of theory of computation, is pure nonsense in terms of knowing whether the code does what it should.

Tests should be designed with great care. Business
people, rather than programmers, should design most functional tests. Unit tests should be limited to those that can be held up against some “third-party” success criteria

The purpose of testing is to create information about your program. (Testing does not increase
quality; programming and design do. Testing just provides the insights that the team lacked to do a correct design and implementation.)

Don’t underestimate the intelligence of your people, but don’t underestimate the collective stupidity of many people working together in a complex domain.

Un super retour d'expérience sur l'utilisation de Flutter Web pour créer une PWA !

Les équipes ont décidé de faire une PWA pour éviter le problème de gestion d'anciennes versions d'une app mobile dans leur parc.

A part quelques difficultés autour de l'utilisation de l'appareil photo, ils n'ont pas rencontré de problème.

C'est vraiment encourageant pour Flutter Web car la techno est en production depuis seulement 1 an et semble déjà à la hauteur des promesses.

Ce genre de choix permet de tester rapidement un concept avec une PWA et de publier plus tard des applications natives sur les stores.

Excellente explication du fonctionnement des GPUs et particulièrement des 4 niveaux de mémoire de travail disponibles.

Une analogie est faite entre un GPU et une entreprise de bureau avec des équipes de personnes qui doivent s'échanger de l'information.

Un exemple de code CUDA, le framework pour bosser sur les GPU Nvidia, est expliqué pas à pas

Un article intéressant de Spotify qui avait besoin d'une manière de visualiser correctement les interactions entre leurs centaines de services.

Ils n'ont pas utilisé UML (thanks god!) mais plutôt le C4 Model qui est un diagramme à 4 niveaux:

• Contexte: comment s'intègre notre système avec d'autres systèmes (service mail externe, autre système métier, etc)
• Containers: quels sont les principaux composants de notre système (app mobile, base de données, frontend admin, etc)
• Components: principales briques métiers de chaque container (CartController, EmailService, etc)
• Code: classes composants les briques métiers

Je connaissais pas mais ça à l'air d'être un outil approprié pour définir visuellement des systèmes très complexes tout en offrant la possibilité de "zoomer" dans des niveaux plus détaillés

Un article présentant un framework pour micro-frontend avec tout le tooling pour se simplifier la vie.

Attention car même avec Piral, gérer un ensemble de micro-frontend est beaucoup plus compliqué.

Une telle décision d'architecture doit se reposer uniquement sur un besoin d'organisation d'une grande équipe en plus petites équipes focalisée sur un domaine de l'application.

Plus d'info sur les micro-frontend https://links.aschen.tech/shaare/AuKMeA

Une bonne introduction aux micro-frontends.

Finalement ça répond au même besoin que les micro-services, pouvoir scale son produit en plusieurs équipes qui peuvent travailler de manière indépendante sur des parties du produit.

Les micro-frontends sont au frontend ce que les micro-services sont au backend.

A utiliser avec parcimonie donc

Très bon article sur les Design System et leurs limites:

• trop de couplage entre composants et logique métier spécifique (data fetching, state, etc)
• manque de documentation à jour (le plus vieux problème des développeurs)

J'aime aussi la distinction qu'ils font entre front-frontend qui s'occupe principalement de l'UI via le design system justement et le back-frontend qui est plus dans la récupération des données et la gestion du state.

Évolution du tracking distribué chez Netflix depuis 2017.

A l'époque l'écosystème de l'observabilité n'était pas aussi mature et des solutions comme OpenTelemetry n'existaient pas encore

8 fausses idées reçues lorsque l'on développe des systèmes distribués

Les microservices apportent avec eux une complexité beaucoup plus grande notamment dans la traçabilité des erreurs et le debug dans un écosystème distribué sur le réseau.

Leur utilisation ne doit être envisagé que lorsqu'il y a de gros besoins de scalabilité

Les Architecture decision record (ADR) servent d'historique des décisions d'architecture technique d'un produit en fournissant des éléments de contexte en plus de la décision et de ses implications.

Le template markdown est mon préféré https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-madr/index.md