“La meilleure qualité d’un informaticien c’est la paresse.”
Dans son talk, Florent Jaby nous rappelle que c’est la répétition d’une même tâche rébarbative qui nous pousse, nous les développeurs, à écrire des scripts dans le but d’automatiser un maximum ces tâches fastidieuses. Comme, par exemple, construire et déployer une image Docker depuis une CI GitLab, dans le but d'éviter de le faire à la main.
“Pour faire plus de choses, il ne faut faire que celles qui comptent et donc il faut faire des choix. En informatique, on a tendance à faire des choses qui n’ont pas beaucoup de valeur pour notre entreprise.”
On utilise généralement la pyramide des ressources IT (pyramide du build vs. buy) pour déterminer sur quoi concentrer nos efforts.
Au sein de notre système d’information, on peut disposer les assets informatiques en trois catégories :
- les différenciants. Ils définissent notre cœur de métier et incitent les clients à apprécier notre produit davantage par rapport à celui de la concurrence. “C’est là où se trouve l’investissement pour innover”.
- les standards de secteur. Ce sont des logiciels qui sont utiles à tous les acteurs du secteur. Par exemple, les progiciels qui s’occupent des réservations des numéros de vols dans les aéroports.
- les commodités. Historiquement, on peut les appeler des denrées parce qu’elles peuvent s'acheter en vrac au kilo. Il y a peu de différences entre des commodités vendues par un marchand ou celles du marchand d’à côté. Exemple : la bureautique, les e-mails.
On voudrait concentrer nos efforts sur les différenciants (en haut de la pyramide) et c’est pourquoi on évite de faire à la main ce qui se trouve en bas de cette pyramide, en particulier les commodités.
Nous pouvons observer le même problème grâce à la méthode du coût de délai.
“Pour une activité dont on identifie un potentiel revenu mais qu’on n’a pas encore développée, le temps qu’on passe à ne pas offrir ce service-là c’est de l’argent pas gagné. Plus on attend, plus l’argent non gagné, quelque part une perte, s’accumule jusqu’au moment où on arrive à mettre en production la fonctionnalité. A ce moment-là, les pertes cessent de s’accumuler.“
Florent nous propose l’exemple suivant : vendeur de billets dans un train. Le vendeur souhaite avoir un petit dessin où il peut choisir exactement la place qu’il souhaite, en sachant où est placée la fenêtre ainsi que les autres personnes. Il s’agit d’une fonctionnalité très différenciante pour le marché.
Plusieurs dépendances sont induites par cette nouvelle fonctionnalité (cf l’image ci-dessus). Pourtant, pour gagner de l’argent, il faut proposer aux utilisateurs ce qu’ils souhaitent avant tout : la nouvelle fonctionnalité. Ainsi, on voudrait pouvoir sauter les étapes précédentes, pour finalement arriver à un coût de délai réduit.
“Cette différence-là, c’est des euros. Et les euros, c’est cool.”
Une dernière manière de voir le même problème avec encore un angle différent : la Wardley map. Il s’agit d’une méthodologie ouverte. Des groupes de discussion sont présents partout sur Internet.
Selon Simon Wardley, les outils et produits informatiques (mais pas seulement) passent par quatre grandes phases.
La genèse permet la recherche d’invention de choses nouvelles, de manière libre, tout en maximisant l’apprentissage. Une fois l’idée trouvée et reconnue comme étant une bonne idée, les entreprises chercheront à la construire de manière répétable, en améliorant sa qualité (modèle de l’artisan). Plus tard, quand l’utilité et le modèle de coût - voire le modèle de revenu - seront connus, l’entreprise ou l’écosystème fera de cette fonctionnalité un produit “manufacturé”.
Pour entrer en compétition, les entreprises devront proposer plusieurs prix pour optimiser leur marge. On va se retrouver avec un petit groupe d’acteurs proposant à la vente le même type de produits.
Les Web Apps, les APIs et les bases de données (custom built), tout comme les certificats HTTPS et les load balancer (product), ce n’est pas la première fois que nous devons en faire. Les VMs et les disques, sur lesquels on mettra, par exemple, du Kubernetes, sont des denrées (commodity) : peu de différences existent entre les différents marchands.
Nous allons mettre le maximum de ressources et de talents sur les sujets importants : la nouvelle feature (ce qui est tout à gauche) et ainsi renoncer aux autres sujets.
Nous arrivons au top 5 des choses qu’il est préférable de déléguer. Mais avant de faire ces choix, il y a deux questions importantes à se poser :
“Est-ce que cette activité-là, c’est ce que vous vendez ?”
Dans ce cas, cela signifie que votre client vous affirme que c’est ce produit qu’il attend et que vous allez pouvoir lui donner.
“Et si ce n’est pas ça, est-ce que ça vous distingue, par la manière dont vous le faites, de vos concurrents ?”
Vous pourriez arrêter de déployer et configurer des serveurs et des volumes de stockage que vous hébergez pour une base de données SQL. A l’heure actuelle, le marché des BDDs SQL est très concentré (Microsoft pour les BDDs propriétaires et SQL/NoSQL répartis sur le marché de l’open-source). Des gens ont trouvé le modèle de coût et de rentabilité de ces bases de données.
Elles doivent pouvoir distribuer le stockage pour qu’il soit redondé, résilient, on doit pouvoir faire des backups régulièrement et restaurer ces backups. Cela nécessite des compétences et de l’optimisation pour les rentabiliser. Ainsi, vous pourriez utiliser des DBaaS.
Chez les fournisseurs Cloud, il suffit de cliquer pour provisionner une base de données Postgresql. Heroku et Amazon RDS en sont des exemples.
Est-ce que monter et arrêter votre cluster Kubernetes vous-même vous distingue de vos concurrents ?
La réponse n'est pas forcément évidente. Cela permet de déployer plus rapidement des applications, de scaler, de faire beaucoup de choses que vos concurrents ne savent pas faire.
Oui mais est-ce que c’est vraiment ce qui vous distingue ?
C’est plutôt son utilisation qui permet de vous distinguer auprès de vos concurrents. A la place, vous pourriez utiliser des Caas ou des Kaas.
Kaas (Kubernetes as a Service) est une offre de cluster avec beaucoup de machines à la demande (Google Kubernetes Engine, Scaleway Kubernetes Kapsule…).
Caas (Container as a Service) est plus haut niveau (entre IaaS et le SaaS/PaaS. Il permet de démarrer un container à la demande (Fargate AWS).
Vous pourrez vous différencier en livrant plus vite ou en scalant comme vous le souhaitez. Il devient alors superflu de connaître le métier d’opérer un cluster Kube de manière correcte et - surtout - rentable.
Il est peu probable que vous vendiez des certificats HTTPS à vos clients. Par ailleurs, la petite pastille verte qui apparaissait dans les navigateurs lorsque vous génériez votre propre certificat HTTPS n’existe plus depuis maintenant trois ans.
“Il n’y a absolument rien à gagner à faire des HTTPS différents de tout le monde. Vous avez juste le risque de faire un HTTPS médiocre qui va dire à votre utilisateur “franchement je n’irais pas à ta place sur ce site-là”.”
Let’s Encrypt est la solution proposée à ce problème. Let’s Encrypt est gratuit, open source et reconnu sur tous les navigateurs et OS. Il permet d'automatiser la création, la vérification du nom de domaine et surtout le renouvellement du certificat (valable 1 mois et demi). C’est aussi Let’s Encrypt qui s’occupera de mettre à jour vos suites cryptographiques et tous les paramètres de gestion cryptographique qui évoluent sans cesse.
Vous pourriez arrêter de déployer et configurer des serveurs Apache, Nginx ou Caddy pour servir des fichiers statiques (i.e. HTML, CSS, Javascript, même des Zip, des CSV, des JSON). Un “sudo apt-get install nginx” semble simple. Cependant, il y a d’autres problématiques à gérer quand on expose des fichiers sur Internet. Comme, par exemple, des organismes malintentionnés qui souhaiteraient faire tomber votre site parce qu’ils ont un intérêt malveillant.
Opérer des serveurs statiques qui savent résister à ce genre d’attaques et qui savent distribuer rapidement des fichiers de manière sûre et fiable à tout utilisateur n’est pas simple. Il faut des nœuds réseau plus proches des utilisateurs et répliquer la donnée sur une grande partie du réseau Internet.
Ainsi, Florent propose d’utiliser plutôt un Content Delivery Network. Les fichiers à exposer sont déposés sur un bucket S3 ou S3 compatible et le service va s’occuper de diffuser cette donnée-là sur tous les edges de son réseau pour qu’elle soit au plus près des utilisateurs.
Par exemple, Florent nous raconte que l’année dernière, il a pu développer un site très demandé et qui était même passé sur le journal de TF1. Ce site était déployé sur GitLab Edges, dont le CDN est géré par Google. Des fichiers, générés sur un serveur, étaient diffusés sur Internet par le CDN.
Le load balancing permet d'avoir un serveur qui va répartir la charge sur plusieurs autres serveurs et qui permet de scaler massivement ses serveurs applicatifs. Il existe beaucoup de projets, principalement open source, offrant ce service. La référence en la matière est HAProxy.
La mise en place d’un load balancer est simple, mais pas le déploiement continu de la configuration des différents serveurs sur lesquels le load balancer doit répartir la charge. Tout comme le fait de retirer des serveurs, d’en rajouter, de changer la version applicative et de faire du blue-green deployment.
La plupart des Cloud Providers proposent des load balancer as a service (LBaaS) pour soulager cette charge de travail. Nous parlons aussi bien d’AWS, d’Azure, que des français, Scaleway et Outscale par exemple qui ont tous plus ou moins une offre de load balancer as a service.
Nous sommes arrivés à la fin du top 5 mais il y a un numéro bonus.
Si vous utilisez une technologie suffisamment standardisée, c’est-à-dire suffisamment répandue (Ruby on Rails, Node.js, Spring Boot, etc.), il est inutile de compiler, stocker et gérer le cycle de vie de vos artefacts applicatifs, de les télécharger, de les bouger au bon endroit sur le réseau, de démarrer ni d'arrêter des serveurs avec votre interface applicatif (votre JAR). En effet, tout le monde s’accorde sur la manière de compiler, de distribuer, de démarrer et de configurer votre serveur.
Heroku (un PaaS : Platform as a service) est la référence en la matière. Il existe beaucoup de services calqués sur le même modèle : nous pouvons citer Azure App Service, AWS Elastic Beanstalk, Google App Engine, Scalingo, Clever Cloud…
“Entre le moment où vous dites, tiens j’aimerais bien faire un “hello world” pour tester et le moment où il est disponible dans le monde entier avec une latence hyper faible, il peut se passer quelque chose comme 5 minutes”. D’un point de vue coût de délai, en comparaison avec le fait de devoir démarrer des VMs, déployer, compiler… c’est un bon gain de temps.
“Si un middleware existe, alors il est disponible en self-service sur le Cloud.”
Il existe nécessairement quelqu’un qui s’est spécialisé sur le sujet et qui propose le middleware as a service à la demande.
Par ailleurs, Florent nous rappelle, qu’en tant qu’ingénieur, nous avons tendance à régler nos problèmes en rajoutant encore plus de problèmes par-dessus. Pourtant il serait légitime de se demander si nous n’en aurions pas moins en retirant des choses de notre système.
“Si le contexte change, vous devez changer d’avis.”
“Enfin, à cause des coûts perdus, des coûts cachés, des biais d’ingénieurs, vous êtes à risque de perdre le focus sur ce qui est le plus urgent, le plus important pour votre organisation : continuer d’apporter rapidement de la valeur à vos utilisateurs.”