Sommaire

1. Comment économiser de l’argent et donc du CO2 avec Azure 💸🌳
2. Svelte, ou pourquoi je ne veux plus faire de React
3. Gestion de la dette d'architecture dans un contexte d'hyper croissance
4. Still not into State Machines in 2023?!

Comment économiser de l’argent et donc du CO2 avec Azure 💸🌳

Rédigé par Clément Lechevallier

Sur le cloud, on peut très vite se retrouver avec plein de ressources non utilisées ou mal utilisées.

Le but de cet article va être d’énumérer quelques bonnes pratiques pour économiser de l’argent sur Azure. Cette liste est non exhaustive mais elle peut vous aider à réduire considérablement vos coûts sur Azure.

Azure Advisor

Cet outil est fourni par Azure et il permet de vérifier que toutes les optimisations basiques sont faites sur votre compte Azure. Ce service est totalement gratuit et analyse vos ressources pour savoir si vos VMs sont trop utilisées ou pas assez utilisées par exemple.

Adresses IP publiques

Chaque adresse IP publique a un coût qui est certes faible mais quand on le multiplie par 1000 machines, cela peut représenter une économie importante. Chaque adresse IP coûte 2,67$, donc cela fait 2670$ d’économies sur les 1000 machines. Ce n’est pas négligeable.

Transfert de données entre datacenters

Si vous utilisez plusieurs régions pour vos services, assurez-vous d’utiliser le moins de régions possibles. En effet, le transfert de données entre datacenters est payant et cher : 0.01$ par Go entre zones de disponibilités, 0.02$ à 0.05$ par Go entre régions. Il est essentiel d’avoir plusieurs zones de disponibilité/régions pour avoir un SLA élevé mais il ne faut pas en abuser.

Il est conseillé d’utiliser les zones de disponibilités au sein d’une même région. Ensuite, une 2ème région est possible pour améliorer la disponibilité et la latence en changeant de continent mais cela n’est pas forcément utile. Il est préférable d’utiliser Azure Front Door pour améliorer les performances entre les régions.

Ressources de développement

Les environnements de tests n’ont pas besoin de ressources avec un SLA élevé ou de redondances. Il est conseillé d’utiliser des instances SPOT. Ces instances sont beaucoup moins chères que les classiques car elles peuvent être arrêtées à tout moment si Azure a besoin de puissance de calcul. Ces instances peuvent apporter des économies jusqu’à 90% par rapport au prix à la demande.

Réserver les ressources

Si vous savez que vous allez avoir besoin de certaines ressources durant un certain temps, il est grandement conseillé de les réserver. Cela signifie que vous aurez la machine pendant 1 an par exemple. Il est même possible de résilier la machine avant la date d’expiration mais avec quelques pénalités. Les économies peuvent atteindre 80% si l’on réserve une machine virtuelle pour 3 ans.

Mettre à jour les versions des services

Lorsque Azure déploie une nouvelle version de ses services, elle peut être moins chère. Il est essentiel de vérifier que l’on a bien la version la moins chère qui est utilisée

Gérer les politiques de déploiement

Certaines ressources ne sont utilisées qu’à certains moments de la journée. Par exemple, les ressources de l’environnement de dev ne sont pas utiles la nuit car les développeurs ne travaillent pas la nuit. De même avec les applications internes qui sont utiles pour les employés uniquement. Éteindre ces environnements environ 8h par jour peut vous faire économiser beaucoup d’argent.

Svelte, ou pourquoi je ne veux plus faire de React

Rédigé par Valentin Dewez

Lors de cette conférence, Romain Crestey nous partage son retour d’expérience sur Svelte.
Il commence dans un premier temps avec la courbe npm trends, comparant les téléchargements entre React et Svelte.

Dans un premier temps, il explique ce qu'a apporté Facebook avec React :
des composants, Flux, le Virtual DOM et la syntaxe JSX, mais aussi la difficulté qu’a apporté React dans le front-end.

React est est également composé d'un package très lourd (même nu), et le virtual DOM qu’il apporte a ses défauts : le principe est de créer un DOM virtuel à chaque événement, puis de comparer chaque élément du DOM virtuel à chaque élément du DOM "réel" afin de voir les différences et de mettre à jour les éléments correspondants. De ce fait, les comparaisons en permanence sont très coupas optimal.
De plus, React n’est pas vraiment réactif. La boucle de rendu permanente est un gros point faible.

Svelte

Svelte est un compilateur. Toutes les relations entre data et UI sont explicitement décrites au build time. Aucune boucle de rendu, pas de DOM virtuel et l’optimisation est faite par défaut.

Lors de cette conférence, Romain Crestey prend le parti de démontrer la simplicité de Svelte, avec un livecoding.

La réactivité en Svelte

Il insiste sur la partie script qui sera jouée une seule fois (contrairement à React). Mais comment rendre ma variable réactif si le script est valide qu’une fois ? Grâce à la syntaxe JS label $:.

<script>
	let money = 10;
	let height = 180;

	$: moneyInYens = money * 94;
	$: heightInM = height / 100;

	$: rich = money > 10;
	$: tall = height > 200;
</script>

Ici, tout est inscrit à build time. Seulement les blocs préfixés de $: seront réactifs.

Composition d’un fichier

En Svelte, tout est au même endroit, le script, la partie html et le style. Un fichier svelte est composé des 3.

Les props

En Svelte, on utilise le keyword export dans la partie script.

export let items = [];
export let current = 0;

Les blocs de compilation

Les blocs de compilation vont nous permettre en Svelte, de réaliser des boucles, des comparaisons, et bien plus encore !

Prenons l’exemple d’une boucle. Comme on le ferait en Vue avec un v-for, en Svelte, nous utilisons un bloc de compilation  #each.

<h1>{project.id} : {project.name}</h1>
<h1>Shopping list</h1>
<ul>
    {#each items as item}
    <li>{item.name} x {item.qty}</li>
    {/each}
</ul>

Il en existe d’autres comme les blocs de compilations if et else pour des comparaisons.

{#if hasCurrent}
<Slider items={toDisplay} {current} let:item>
  <Pokemon infos={item} />
  <img
    src={previous.sprites.front_default}
    class:caught={$bag.has(previous.id)}
    alt="Previous pokemon"
    slot="previous"
    let:previous
  />
    <img
    src={next.sprites.front_default}
    class:caught={$bag.has(next.id)}
    alt="Previous pokemon"
    slot="next"
    let:next
  />
</Slider>
{:else}

Les stores

Ici, en quelques lignes le store est mis en place. Celui-ci est personnalisable et il est accompagné de base avec les méthodes set et update.

import { writable } from 'svelte/store'

const { subscript, update } = writable(new Set())

export const bag = {
  subscribe,
  toggle: (id) =>
    update((list) => {
      if (list.has(if)){
        list.delete(id);
      } else {
        list.add(id);
      }
      return list;
    }
  )
}

Svelte Kit

Comme tout framework, Svelte est également accompagné de son méta framework, comme on peut retrouver Next.js pour React et Nuxt.js pour Vue.
On retrouve ainsi SvelteKit : https://kit.svelte.dev/

Benchmark

Finalement, Romain nous présente les performances de Svelte

Conclusion

Pour conclure, cette conférence insiste sur la simplicité et la facilité de développer en Svelte. C’est simple et cela permet de se concentrer sur ce que l’on veut faire et éviter la perte de temps à optimiser et à débugger son code.

Enfin, Romain Crestey insiste sur l’importance d’avoir tous ces différents frameworks (React, Vue, Svelte), qui mutuellement s’inspirent les uns des autres et se tirent vers le haut pour s’améliorer.

Enfin, j’ajouterai personnellement que cette conférence montre les points forts de Svelte mais que celui-ci a une communauté qui est encore petite et que les opportunités d’emplois en Svelte sont assez minces. A sa connaissance, l’auteur de cette conférence nous indique qu’il est le seul à le pratiquer sur Bordeaux de manière quotidienne et professionnelle.

Si Svelte vous intéresse, il existe sur Bordeaux des communautés comme celle-ci.

Retrouvez ici les sources et le Github de la conférence.

Gestion de la dette d'architecture dans un contexte d'hyper croissance

Rédigé par Jean-Rémy Revy

Cyril Beslay — Architecte Solution chez Mano Mano — commence par faire un parallèle avec un crédit bancaire, qui dans un contexte de croissance est un accélérateur nécessaire. Elle revêt bien des aspects : fonctionnelle (bug), technique (code), sécurité, légale ou d’architecture … Mais sommes-nous malgré tout de bons payeurs ?

Concernant la dette d’architecture, Cyril postule qu’elle peut être évaluée en regard de l’écart avec les standards ou les principes directeurs de l’entreprise … pour peu qu’ils soient partagés et accessibles. Les raisons sont diverses, comme un choix trop facile de solution en regard d’une meilleur approche de conception voire le mauvais choix de framework ou encore des migrations non achevées.
Par exemple, un principe légitime qui recommande d’utiliser un circuit breaker avec tous les appels externes induit une fois édicté que toutes les applications qui ne l'implémentent pas encore sont en écart. Un POC qui irait en production pour vérifier une hypothèse métier ou un intérêt client mais qui resterait en l’état non industrialisé en regard des standards impliquerait également une dette d’architecture.
Mais contrairement à la dette “technique” classique (de code), il n’existe aucun outil capable de la calculer simplement ou de manière suffisamment exhaustive.

Les causes réelles de contracter ce type de crédit sciemment ou accidentellement, peuvent être externes à l’équipe de développement : les acteurs métiers imposant pression et délai ou ne comprenant pas ce concept, le manque de standards d’architecture ou simplement le temps qui passe et rends les composants obsolètes. Les causes internes sont tout aussi nombreuses et importantes : manque de connaissance ou choix erronés, manque d’anticipation ou simplement le facteur “humain”. Et tout ceci a des impacts, visibles au travers de symptômes que nous connaissons tous, comme l’augmentation du coût de développement (bug ou feature), ou encore la concentration de la connaissance sur une seule personne voire sa perte.

Cyril nous présente ensuite comment il gère cette dette chez Mano Mano, pour éviter la banqueroute (tout jeter pour tout refaire) tout en rappelant à nouveau que contracter une dette permet de saisir des opportunités commerciales ou métier nécessaires. Dans les pratiques évidentes, concevoir correctement son architecture et anticiper les besoins se passent de commentaire, tout en traçant les décisions et leur contexte dans des ADR.
Plusieurs stratégies sont disponibles, de la plus proactive comme la règle du boy scout adjointe d’un temps dédié à la suppression de cette dette idéalement matérialisée dans le backlog, à la plus passive consistant à ne pas la réduire du tout car inutile en passant par une stratégie réactive essentiellement opportuniste.
À cette fin, Mano Mano crée son propre framework d’évaluation de la dette d’architecture, sur ses différentes déclinaisons, de l’UX à l’infrastructure : la Mano Tech Matrix. Celle-ci étant propre à l’entreprise et son domaine, elle ne saurait être pertinente ailleurs. Sans tout dévoiler dans ce résumé, un ensemble de questions et d’interviews leur permettent d’identifier la dette et de qualifier les solutions build blocks concernés avec un scoring permettant de prendre de meilleures décisions.

En substance, la dette n’est pas une mauvaise chose en soi, tant qu’elle est identifiée et non “cachée sous le tapis”. Pour celà, Cyril nous conseille évidemment de définir (et de communiquer) les standards de l’entreprise, d’identifier et gérer cette dette tout en étant pédagogue à son sujet et construire ses propres outils à ce propos.

Still not into State Machines in 2023?!

Rédigé par Merlin Boyer

La conférence de Guillaume s’ouvre et un exemple de code apparaît dès la seconde slide.Le ton est donné, ces 45 minutes seront dédiées à la tech et au live coding !

Il nous explique alors un cas d’usage qui me fait rapidement écho, c’est une problématique que j’ai déjà rencontré :

• Vous avez besoin de récupérer une liste d’items depuis une API tierce et de les afficher.
• Pour cela vous mettez un bouton “load items”, lorsque l’utilisateur clique dessus le bouton disparaît et est remplacé par un spinner de chargement.
• Lorsque le chargement prend fin, le spinner est remplacé par la liste des items à afficher.

Guillaume nous propose alors plusieurs implémentations que nous allons aborder dans cet article.

La solution avec des conditions

L’approche la plus souvent implémentée consiste à mettre 3 bloc if dans le DOM :

• if “list_item vide” ➡️ afficher bouton
• if “en cours de chargement” ➡️ afficher spinner
• if “list_item non vide” ➡️ afficher list_item

Mais cette implémentation est un peu trop naïve. Si par malheur l’état interne de notre système se retrouve corrompu et que 2 conditions sont vérifiées en même temps, alors l’affichage se retrouvera buggé car 2 blocs s'afficheront en même temps.

Une façon de se protéger serait de rajouter des conditions plus strictes :

• if “list item vide && pas en cours de chargement” ➡️ afficher bouton
• if “list item vide && en cours de chargement” ➡️ afficher spinner
• if “list item non vide” ➡️ afficher list item

On s’assure ici que 2 blocs ne puissent pas apparaître en même temps.

Bien que cela se fasse facilement avec les frameworks modernes tel qu'Angular ou Vue.js, on se rend rapidement compte que si le nombre d’états possibles, et donc le nombre de conditions, augmente, le code va devenir lourd à écrire comme à maintenir. En outre, on affiche de la donnée métier dans la vue ce qui n’est pas une bonne pratique.

Eh bien, nous avons un bon cas d’étude résolvable avec une machine à état fini (ou state machine dans la langue de Shakespeare) !

La solution state machine

Enfin, nous y voilà. Nous allons nous plonger dans l’univers des machines d’état ! Cette approche consiste simplement à déplacer les conditions que nous avons vu dans l’exemple précédent dans une variable qui représente l’état de notre système. On appelle cela un behavior design.

Voici un exemple du principe :

L’état du chien peut prendre 2 valeurs, asleep ou awake. Ces valeurs changent lorsque les évènements fall asleep ou wakes up sont reçus.

De façon plus générique une machine à états finis c’est :

• un nombre d’états possibles fini
• un seul état initial
• n états finaux
• un seul état en cours

XState

En Javascript, il existe un package npm très complet qui permet de créer et de paramétrer des machines à états finis : XState. Cette librairie met aussi à disposition une interface graphique permettant de dessiner sa machine puis de l’exporter en code. Il existe aussi un plugin VSCode. Elle est aussi mentionnée dans ce quickie.

Nous ne rentrerons pas dans tous les détails de la librairie ici, pour cela je vous invite à aller voir le replay de la conférence, mais dans les grandes lignes une machine va ressembler à ceci (en VueJS) :

Étape 1 : créer une machine

import { useMachine } from '@xstate/vue';
import { createMachine } from 'xstate';

const toggleMachine = createMachine({
  id: 'toggle',
  initial: 'inactive',
  states: {
    inactive: { on: { TOGGLE: 'active' } },
    active: { on: { TOGGLE: 'inactive' } }
  }
});

Avec la librairie XState c’est facile il suffit d’appeler la fonction createMachine. Il faut alors lui renseigner :

• Un id pour pouvoir l’identifier parmis plusieurs machines par la suite
• un état initial, qui doit être l’un des états définis dans le bloc states
• une liste de states, chacun ayant un nom ainsi qu’une liste d’évènements à écouter permettant de passer sur un autre état. Exemple ici : si on est dans l’état inactive et que l’on reçoit l’évènement TOGGLE alors on passera dans l’état active.

Étape 2 : exporter la machine

export default {
  setup() {
    const { state, send } = useMachine(toggleMachine);
    return { state, send };
  }
};

La fonction useMachine de XState renvoie deux arguments :

• state : l’état courant de la machine
• send : une fonction pour envoyer des événements à la machine

Étape 3 : utiliser la machine

<button @click="send('TOGGLE')">
  {{
    state.value === 'inactive'
      ? 'Click to activate'
      : 'Active! Click to deactivate'
  }}
</button>

On peut alors utiliser la machine dans le DOM, ici on a défini un bouton dont le texte change suivant le state de la machine. Pour changer l’état il suffit d’appeler la fonction send et de lui passer l’évènement que l’on a défini dans la machine. Lorsqu’un état reçoit l’événement TOGGLE, la machine passera dans l’état défini dans l’attribut : on{'TOGGLE' : <etat_a_activer}

Pour aller plus loin

Dans sa conférence Guillaume va plus loin que l’exemple cité ici, il nous montre qu’il est possible avec XState de gérer plusieurs états en parallèle ou encore que l’on peut conditionner les changements d’un état à un autre. Il faut aussi noter que la librairie s’intègre bien avec les stores, on peut utiliser le state dans d’autres composants. Il est aussi possible d’ajouter du contexte dans les machines de XState. Un contexte représente un état étendu, c’est un état n’est plus représenté par un attribut seul mais par un ensemble d’attributs. Pour faire simple cela veut dire qu’au lieu d’identifier un état avec un nom on l’identifie avec une structure qui a plusieurs champs.

Conclusion

Cette conférence était centrée sur un live coding de la librairie XState en Vue.js, nous en avons fait un résumé ici mais si vous voulez retrouver toutes les fonctionnalités je vous invite à aller voir le replay de la conférence sur youtube où directement la documentation sur XState.

Mon ressenti est que cette librairie est assez mature pour être utilisée dans un vrai projet, le point fort étant l’écosystème de plugins comme celui de VsCode qui permettent de créer graphiquement une machine d’état avant de l’exporter en code. Cela permet d’avoir un visuel qui est très parlant pour représenter des états et leurs transitions. Cette conférence m’a rappelé mes études et les cours sur les machines de Moore et tous les avantages qu’elles apportent. Si l’occasion se présente je vous recommande d’essayer de mettre en place des machines à état, elles vous permettront de sortir de la logique métier du DOM et de garantir une cohérence de l’état interne de votre système à toute épreuve.