Confoo 2020 : Retour sur l’édition 2020 Montréal

Tous les ans s’organise ConFoo, une conférence multi-technologies pour développeurs orientée vers des solutions pragmatiques pour développeurs, qui compte 155 présentations par des conférenciers internationaux populaires. C’est aussi la plus grande conférence de développeurs à Montréal.

Comment doubler sa mémoire et surmonter la surcharge d’informations ? Claire Jeong

Information Overload Syndrome (IOS) : notre problématique du siècle

Dans notre société actuelle, nous sommes bombardés d’informations tout le temps.

Nous avons créé un problème et il se nomme IOS.

IOS ou Syndrome de Surcharge d’Informations affecte des milliers de personnes à travers le monde. Je vous invite à regarder cette vidéo explicative qui nous a été présentée par Claire Jeong lors de sa keynote.

On commence à oublier parce que l’on a créé beaucoup trop d’informations à retenir, comme Starbucks qui a commencé par une idée simple : ramener l’expresso italien en Amérique du Nord en 1971.
On s’est retrouvé ensuite avec des multitudes de produits. En 1995, ils ont ajouté les ice drinks, après cela le thé, puis la nourriture, puis le cold brew et finalement le café au lait : café crème et le pink drink (unicorn) frappuccino…

Comme vous le voyez, on a beaucoup de choix chez Starbucks. Et quand on nous demande “comment puis-je vous aider ?”, on regarde ce menu touffu de produits et on est surchargé d’informations.

Un autre exemple : Youtube, avec plus de 6000 nouvelles heures de vidéos chaque heure. Pensez-vous qu’il y a toujours de nouvelles choses? 
Vous devez rester à la page. Vous devez assister à beaucoup de réunions. Vos employeurs demandent trop de choses. Cela vous surcharge et vous ne dormez pas assez !

La solution des experts : un digital detox. Ce qu’il nous faut, c’est une solution pratique pour nous, car une détox numérique est quasiment impossible.

En se basant sur sa propre expérience lors du championnat de mémoire, Claire souhaite nous permettre d’améliorer notre mémoire. Comment utiliser notre cerveau d’une façon plus efficace.

Quand Claire avait 12 ans, sa famille originaire de Corée du Sud vivait en France.
Sa mère faisait des recherches en IA. Elle nous a donc parlé d’une expérience que faisait ce laboratoire de recherche sur elle en étant enfant sur comment fonctionne notre cerveau : comment on apprend et comme on se remémore les choses. Le cerveau est divisé en plusieurs parties qui communiquent entre elles. Les parties qui nous intéressent le plus ici sont la mémoire court terme et la mémoire long terme. Le premier type de mémoire est utilisé lorsque vous regardez le menu d’un restaurant et vous choisissez votre menu préféré, il fonctionne comme la RAM de votre ordinateur alors que la mémoire long terme est votre disque dur. Elle nous a également fait part de la découverte d’une partie du cerveau (le cortex) qui ne peut être mature qu’à l’âge de 25 ans, ce qui explique certains comportements de vieux adolescents pourtant considérés comme des adultes.

La Solution : I’M A CEO

IM pour Intent to Memorise (l’intention de mémoriser). 
On ne peut pas se rappeler d’un coup toute chose et de fait, le processus de sauvegarde de notre cerveau est important : il ne peut sauvegarder qu’une information à la fois. L’idée est de faire le focus sur ce qui est important quand vous travaillez, quand vous parlez à votre client et donc, traitez les points un à un.

A pour Association :
pour booster notre mémoire si on veut se rappeler quelque chose. L’idée étant de l’associer à autre chose. Par exemple, la couleur d’une carte de poker que l’on souhaite mémoriser peut être associée à une célébrité tandis que la valeur serait associée à une action. C’est la technique qui est utilisée par les champions du monde de mémoire.

C pour Chunk :
essayer de regrouper plusieurs informations permet de booster encore plus votre mémoire.
Les chunks permettent d’optimiser l’utilisation de la mémoire à court terme.

EO pour Efficiently Organize
pour une organisation optimisée il faut savoir deux choses : nous venons au monde sans une organisation innée donc nous la construisons au cours de notre vie au fil des expériences passées ce qui permet d’avoir plusieurs variations et plusieurs façons de mémoriser selon les personnes.

Ce que je retiens de ce talk

Il faut éviter d’être submergé par les informations en les priorisant et en enlevant ce qui n’est pas pertinent par exemple avoir des filtres sur nos mails. Regarder de moins en moins les réseaux sociaux sauf pour des sujets précis, éviter les écrans pendant certains moments de la journée. Ça ne peut qu’être bénéfique pour notre santé…

systemd pour les développeurs et les devOps. Christian Heimes

Christian nous as présenté l’un des sujets les plus controversés dans la communauté linux : systemd.

Commençons par l’avant Systemd : POSIX et Linux 101. Christian commence par nous explique qu’au niveau de la mémoire nous avons le User space: espace dans lequel s’exécutent les processus utilisateur. Kernel space : l’espace ou les processus du noyau Unix vivent.

Le User space communique avec le kernel space en faisant des appels à la fonction syscall.

Un processus propose des fonctions de gestion de son cycle de vie : fork() ou clone() pour la création de processus, exit() ou sig(SIGTERM) pour arrêter un processus.

Christian nous explique que c’était compliqué avec l’ancien init : des script shell très complexes, un démarrage en série donc impossibilité de paralléliser, un ordre de démarrage inflexible et pas de système de gestion de service. L’un des inconvénients du système init est la gestion de démons avec des opérations complexes pour les garder en vie. Autre souci, la gestion de la sécurité : par défaut un service est démarré par l’utilisateur root  ce qui lui permet d’écrire dans des fichiers du noyaux, faire n’importe quelle opération qui pourrait vous nuire (lire vos mails, utiliser vos bitcoins, changer le temps, votre hostname, …).

C’est là qu’intervient systemd qui se veut un alternative à init  : Une possibilité de démarrer des processus en parallèle, un démarrage avec le minimum de processus, un inventaire et une traçabilité des processus, une API facile à utiliser, une configuration déclarative.

systemd en bref est :

  • un système d’installation pour Linux pour gérer les services.
  • une collection de plus de 50 binaires de services et d’outils.
  • un projet open source mature : plus de 10 ans d’existence, plus de 1000 contributeurs dans le monde et présent sur quasiment toutes les distributions Linux.

Les composants de systemd sont:

  • systemd: processus principal (PID1) et instances utilisateurs.
  • dbus: permet d’exposer l’API de systemd 
  • systemd-journald: logs de systemd
  • systemd-udevd: événements hardware et firmware.
  • systemd-logind: gestionnaire de connexion
  • systemd-localed: internationalisation et mapping des clés
  • systemd-machined: virtualisation et gestionnaire de containers
  • systemd-timedated: gestion de temps et timezone

Maintenant que nous connaissons les composants, nous pouvons commencer à l’utiliser.
L’exemple que nous donne Christian est une création et la configuration d’un service simple et de le démarrer sous systemd.

Pour vérifier que notre service fonctionne, systemd nous offre des commandes permettant de vérifier l’état des services tel que systemctl avec l’option status.

Pour gérer le cycle de vie de notre service, systemctl est ce qu’il vous faut avec ses différentes options: start, stop, restart … .

Christian nous a aussi montré qu’on peut personnaliser le fonctionnement d’un service avec un fichier configuration qu’on appelle unit file

Il existe plusieurs types de unit :

  • target unit : groupement de unit permet la synchronisation entre les services (un service peut avoir besoin de se lancer avant ou après un autre service).
  • service unit : permet de définir la configuration d’un service (son type, les fichiers de configuration dont il dépend pour démarrer, ses fichiers d’exécutions, sa politique de redémarrage lors d’un crash, …)
  • activation unit : permet d’activer un service selon certaines conditions (temps comme les CRON, présence d’un fichier, socket…)

Par la suite, Christian nous parle d’un des plus grands avantages de systemd : la sécurité.

systemd permet de limiter l’accès à certains fichiers selon l’utilisateur ou groupe d’utilisateurs et donc éviter le problème qu’on avait avant avec init qui donnait un accès root aux services. Encore mieux la notation de namespace qui permet de définir des droits en lecture ou d’écriture pour plusieurs unit utilisateurs ou groupe d’utilisateurs.

Ce que je retiens de ce talk

tout est unit dans systemd partant du processus (service), activation (time, path, socket), le groupement de services (target),  la gestion des ressources (service units) et la sécurité (namespaces). Cependant, systemd reste un sujet controversé car il ne respecte pas les standards POSIX/UNIX. 

Les bases de données dans le monde microservices. Rob Richardson

Les bases des données dans le monde microservice sont l’un des sujets qui m’intrigue le plus. Avant de parler de base de données, Rob commence par nous relater l’évolution de l’architecture logicielle.

Puis il nous explique les caractéristiques qu’un Microservice doit avoir :

  • faire un seul travail (pas plusieurs).
  • être facile à déployer (utilisation des containers).
  • pouvoir scaler indépendamment des autres Microservices.
  • être facilement remplaçable.
  • être propriétaire de ses données.

Par contre, beaucoup d’entre nous implémentent une pseudo architecture microservice de cette façon :

Pourquoi ? 

Pour les raisons suivantes :

  • provisionner une base de données est compliqué
  • le DBA a dit non (ça arrive aussi)
  • beaucoup de toutes petites bases de données
  • nous devons toutes les sécuriser, non ? (argument DBA)
  • est-ce que toutes ces bases ont un backup chacune ? (argument DBA)

Rob nous indique que seuls les Bounded Context (terme venant du Domain Driven Design) permettent de découper la base de données, ce qui nous conduit à la notion des micro-bases de données.

Le principe est simple:

  • Chaque microservice a sa propre base de données 
  • Si un microservice a besoin de changer les données d’un autre Microservice, il doit demander à ce microservice de changer les données (via une API par exemple).
  • Pour les jointures : une base de données d’un microservice peut envoyer un événement via un BUS (Kafka par exemple) qui sera utilisé par les autres Microservices.

Ce qui nous ramène à un autre point : les Microservices n’ont pas besoin d’avoir le même type de bases de données.

Rob passe ensuite en revue les caractéristiques des différentes bases de données avec les différents avantages et inconvénients. Dans ce résumé, je vous ai fait une sélection parmi celles présentées par Rob.

Les bases de données relationnelles

Caractéristiques :

  • Des lignes et des colonnes
  • Un grand serveur (en termes de ressources)
  • Tables avec des lignes et des colonnes consistantes 
  • Compliant ACID
  • Requêtes SQL pour toute opération

Avantages:

  • Schéma strict
  • Possibilité de faire des jointures de tables.
  • Moteur d’exécution des requêtes très optimisé.
  • Langage familier pour la plupart des développeurs.

Inconvénients:

Usages:  

  • Presque partout (sauf les cas particuliers qu’on verra avec les autres types de bases de données).

Les bases de données document (NoSQL)

Caractéristiques:

  • Des documents JSON.
  • Distribuées (sur plusieurs machines).
  • Optimisées pour la lecture.
  • Cohérence à terme.

Avantages:

  • Mise à l’échelle ( distribuées sur plusieurs machines).
  • Pas de schéma (structure de documents flexible)
  • Dénormalisé (donc lecture rapide)

Inconvénients:

  • Augmentation du stockage, transfert réseau, temps de lecture aussi pour des lectures partielles d’un document
  • Pas de standard, voire de langage de requête, ce qui les rend moins universelles.
  • pas de transactions.

Usages:  

  • besoin de résultats rapides par exemple :
    • Catalogue produit
    • CMS

Les bases de données New SQL

Caractéristiques:

  • SQL.
  • Partitionnées sur plusieurs machines.

Avantages:

  • pas cher à scaler (en termes de ressources)

Inconvénients:

  • Latence réseau (vu la partition sur plusieurs machine)

Usages:  

  • Base de données grandissante:
    • Beaucoup de données à adresser.
    • Besoin de plusieurs utilisateurs.
    • Besoin d’un temps de réponse rapide (par rapport au classique SQL).

Ce que je retiens de ce talk

  • Utiliser les bases de données as a service si c’est possible (RDS pour AWS par exemple).
  • automatiser le maximum d’opérations si l’on a plus d’un serveur base de données.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

%d blogueurs aiment cette page :