Plaidoyer pour une architecture simple (2022)

• Wave est une entreprise valorisée à 1,7 Md$ (2,3 billions de wons) avec 70 ingénieurs (elle fournit des services bancaires mobiles pour l’Afrique)
• Son architecture est celle d’une application CRUD standard : un monolithe Python basé sur Postgres
• En partant d’une architecture simple et en résolvant les problèmes tout en minimisant la complexité, les ingénieurs ont pu se concentrer sur la création de valeur pour les utilisateurs
• Stack Overflow a lui aussi connu une forte croissance avec succès en faisant évoluer un monolithe, jusqu’à être acquis pour 1,8 milliard de dollars

Malgré l’efficacité d’une architecture simple, la plupart des médias préfèrent les architectures complexes

• Dans les conférences techniques, on voit beaucoup de présentations sur des architectures complexes basées sur des microservices, mais aucune sur de simples monolithes
• De nombreuses entreprises imitent des technologies complexes alors même que leurs applications sont de petite taille, et en tirent de la popularité dans les conférences et sur HN
• L’architecture que nous utilisons est tellement simple qu’il n’est même pas nécessaire d’en faire un diagramme

Comment conserver la simplicité

• Wave utilise Python synchrone, ce qui signifie que les processus serveur sont bloqués lorsqu’ils attendent des E/S
• Ils ont essayé des frameworks asynchrones comme Eventlet, mais il y avait trop de bugs, et ils ont jugé que cela ne valait pas le coût en souffrance opérationnelle
• Au lieu d’augmenter la complexité, les tâches à long temps d’exécution sont isolées dans des files d’attente
• Pour respecter les règles de résidence des données, il faut exploiter des datacenters on-premise dans certains pays
  • Le Sénégal et la Côte d’Ivoire étaient sur le cloud, mais l’Ouganda et d’autres pays exigeaient de l’on-premise à cause de la réglementation
  • Dans ce cas, une architecture simple est bien plus facile à gérer qu’une architecture complexe

Construire plutôt qu’acheter

• Avec une petite équipe, l’entreprise préférait au départ acheter des logiciels, mais lorsqu’il était impossible de corriger des bugs critiques, elle développait ses propres outils
• Construire des outils maison ajoute une complexité qu’ils préféreraient éviter, mais dans certaines catégories de produits, même après des recherches approfondies, ils n’ont trouvé aucun fournisseur capable de proposer une solution adaptée
• Même en dehors des compétences cœur de métier, il est parfois nécessaire de développer ses propres outils et de maintenir une expertise en interne

Choix remis en question

• Ils reconsidèrent certains choix techniques comme RabbitMQ, Celery, SQLAlchemy et Python, car ils accroissent la complexité ou la charge de maintenance
• S’ils devaient repartir sur une nouvelle base de code, ils examineraient ces choix avec prudence

Choix dont ils sont satisfaits

• Ils sont satisfaits de choix comme GraphQL, un protocole de transport personnalisé et Kubernetes
• GraphQL apporte des avantages comme l’auto-documentation, la génération de code et l’explorateur interactif GraphiQL
• Ils estiment qu’avec GraphQL, les avantages l’emportent sur les inconvénients
  • Avantages
    • Auto-documentation sur les types de retour exacts
    • Des clients plus sûrs grâce à la génération de code à partir des types de retour exacts
    • Gain de productivité avec l’explorateur interactif GraphiQL
    • Diverses applications (application utilisateur, application de support, application des agents Wave, etc.) peuvent en grande partie partager une seule API, ce qui réduit la complexité
    • Avec un langage de requête composable, les clients peuvent récupérer exactement les données nécessaires en un seul aller-retour de paquets, sans avoir à construire de nombreux endpoints spécialisés
    • Suppression des débats inutiles sur ce qui doit être considéré comme une API RESTful
  • Inconvénients
    • Les bibliothèques GraphQL n’étaient pas excellentes au moment de l’adoption de GraphQL
    • L’encodage GQL par défaut est redondant, et comme beaucoup de clients utilisent une faible bande passante, une grande attention est portée aux limites de taille
• Kubernetes est utilisé pour répondre aux exigences d’exploitation de datacenters par pays

Conclusion

• En gardant l’architecture applicative aussi simple que possible, il est possible de consacrer le budget de complexité (et de personnel) aux domaines où cette complexité aide réellement l’entreprise
• En privilégiant l’idée de faire les choses aussi simplement que possible tant qu’il n’existe pas de raison forte d’ajouter de la complexité, ils ont pu bâtir une activité d’une taille significative avec peu d’ingénieurs, alors même qu’ils opèrent dans la finance en Afrique, souvent considérée comme un secteur difficile

[secret3056]

« Buy before build » devrait plutôt être « build before buy ».

Un autre domaine concerne les logiciels que nous avons dû développer (au lieu de les acheter).

[xguru]

Ah, j’essayais de mettre l’accent, mais le titre est devenu bizarre. Je l’ai corrigé. Merci.

[savvykang]

Est-ce que les modes changent selon le cycle économique ? Indépendamment des tendances, commencer par un monolithe est plus avantageux pour réduire les coûts fixes et pour la maintenance.

[aer0700]

Une architecture facile à comprendre est aussi plus facile à maintenir.

[mhj5730]

À mon avis, pour n’importe quel service, il vaut mieux commencer par un monolithe. Partir sur une MSA dès le début, c’est gaspiller de l’argent.

[dhlee0305]

« Quand la complexité augmente, les coûts (argent, ressources humaines, temps...) augmentent aussi. »
« N’essaie pas de résoudre avec une architecture complexe un problème qui peut l’être avec une architecture simple. »

[xguru]

Avis sur Hacker News

• Conseils d’ingénierie sur les microservices

  • Les microservices ne sont pas une stratégie d’amélioration des performances, mais une stratégie potentielle de réduction des coûts et de coordination de l’ingénierie.
  • Il n’y a pas de grande différence entre une application monolithique extensible horizontalement et des microservices, sauf lorsque l’on veut réduire l’échelle d’une fonctionnalité spécifique.
  • Dans une application monolithique, il est impossible de réduire l’échelle d’une seule partie de l’application.
  • Les économies de coûts commencent à grande échelle et nécessitent au moins 3 répliques.
  • Pour la plupart des entreprises, le véritable avantage réside dans la coordination de l’ingénierie.
  • Avec un monolithe doté d’un dépôt unique, une équipe peut en être propriétaire et le gérer, mais dans un monolithe partagé, personne n’en est réellement responsable, ce qui le rend difficile à gérer.

• Conférences sur les microservices

  • Lors de conférences techniques généralistes, plusieurs présentations ont porté sur la complexité et les effets secondaires des architectures microservices, mais aucune sur la construction d’un monolithe simple.
  • Une conférence de David Schmitz sur les façons d’échouer avec les microservices était particulièrement marquante, et son style de présentation humoristique est très apprécié.

• Biais cognitifs et simplicité

  • Les gens se concentrent souvent sur l’ajout de quelque chose et négligent les solutions simples.
  • Des recherches montrent qu’il vaut mieux résoudre un problème en retirant des briques d’une structure Lego plutôt qu’en en ajoutant.

• Sur-ingénierie et manque d’expérience

  • Une architecture doit être « suffisamment simple tout en étant aussi complexe que nécessaire », mais atteindre cet équilibre demande de l’expérience.
  • L’industrie IT tend à manquer d’expérience, et l’expérience prend du temps à s’acquérir.
  • Les ingénieurs et managers peu expérimentés utilisent souvent des technologies ou des métriques inutiles.

• Des entreprises qui valorisent l’équilibre entre vie professionnelle et vie privée

  • Recherche d’une entreprise où l’on peut se concentrer sur l’amélioration du produit et consacrer le reste du temps à sa vie personnelle.

• Expérience personnelle avec Dan Luu

  • Dan Luu est généreux dans ses échanges avec les lecteurs de son blog et possède une expertise sur la frontière entre logiciel et matériel.
  • Il partage volontiers ses analyses et son expertise, et apprendre à ses côtés est une expérience très enrichissante.

• L’importance d’une architecture simple

  • Dans la plupart des cas, l’architecture nécessaire se compose d’éléments de base comme un load balancer avec prise en charge SSL, plusieurs serveurs d’application, une base de données shardée et une file de messages.

• Architecture et structure sociale des équipes d’ingénierie

  • L’architecture devrait refléter la structure sociale des équipes d’ingénierie, faute de quoi cela peut entraîner confusion et inefficacité.
  • Un grand dépôt monolithique et une architecture simple peuvent être difficiles à gérer, et des entreprises comme Google et Meta développent elles aussi de nombreux outils en interne.
  • L’architecture peut faciliter ou entraver la collaboration entre équipes, et le leadership technique doit en tenir compte.

• Préférence pour une architecture simple

  • Une architecture simple et un monolithe conviennent dans la plupart des cas, mais il faut veiller à éviter les problèmes liés aux entrées/sorties synchrones.
  • Les bugs d’intégrité des données sont un problème majeur à éviter dans les systèmes financiers.

[dangyup]

Pourriez-vous partager le lien vers la conférence qui traite des conseils de David Schmitz sur les échecs des microservices ?

[xguru]

Il s’agit de https://www.youtube.com/watch?v=r8mtXJh3hzM