À une conférence, un spectateur nous a demandé à quoi ressemblerait le métier d'hébergeur dans 10 ans.
10 ans dans le futur, ça fait loin, 10 ans dans le passé, et ce n'est pas si long que ça si on est né au XX° siècle.
Quoi de neuf depuis 10 ans
Hardware
On va partir sur du Dell, par ce que c'est très commun, et que leur logo est un hommage à Evil Corp, dans Mr Robot.
Donc, chez Dell, un petit serveur génération 11, en 2011, c'est 1U, 1 CPU Intel avec 4 coeurs hyperthreadés et 16Go de RAM. En 2021, on est en génération 15, et un petit serveur, toujours en 1U, c'est un 1 CPU AMD avec 64 coeurs, et 2To de RAM.
La fréquence plafonne autour de 3GHz, pour embêter Moore.
Donc, en 10 ans, au doigt de Dell mouillé, on a 8 fois plus de coeurs, 125 fois la RAM (le ratio RAM par core est multiplié par 15).
Les SSDs sont déjà bien implantés en 2011, avec des tailles et des tarifs crédibles. En 10 ans, le SSD arrête de tricher en se faisant passer par un disque à plateau SATA, pour directement se coller au cul du PCI Express, avec le NVMe, pour des débits niagaresques.
Pour les gros volumes, les disques à plateaux passent de 3 à 16To. Attention, le SATA n'a pas augmenté son débit, pour reconstruire un RAID avec ce genre de titan, prévoyez de la place dans votre planning.
Les gros hébergeurs ne vont pas forcément racker du Dell comme à la belle époque, mais utiliser du matériel spécifique, voir maison, pour densifier et optimiser sa consommation énergétique. Quand la limite au gigantisme de votre datacenter est la puissance électrique disponible il faut commencer à travailler correctement, et pas tout passer en force. Les hébergeurs communiquent quelquefois sur leurs innovations (les tours à air sans clim d'OVH, le mur de gouttes de Facebook…), mais sans trop s'étendre dessus et quantifier leur progrès.
Processeurs
Intel pensait pouvoir profiter pépère de son monopole, mais non, les ARMs, propulsés par les smartphones et autres tablettes ont continué de progresser. Conflit classique de petit boutiste et grand boutien : est il plus simple d'améliorer la consommation énergétique d'un Xeon, ou de rajouter de la puissance à un ARM ?
Autre surprise pour Intel, il est simple d'acheter une licence ARM et de rajouter un peu de sa magie, pour avoir des puces maisons. Apple l'a fait avec son M1, mais sans cibler le marché du serveur, par contre AWS, lui, déploie son processeur maison, le Graviton. Scaleway avait été le pionnier du serveur en arm64, mais sans arriver à avoir du matériel fiable (et avec une gestion du réseau farfelue). Trop tôt, pas assez sec pour Scaleway, Amazon lui, sort sa 3° itération avec fierté.
Pour continuer a embêter Intel, AMD sort sa gamme Epyc qui ringardise les Xeons (et sans recompiler, on reste dans une architecture amd64 comme Intel).
Un processeur, c'est pratique, c'est versatile, mais sur un serveur, tout le monde ne fait pas des maths ou de la compression vidéos. De toutes façons, quand on a besoin de cruncher des chiffres, une carte dédiée pourra faire des merveilles. D'abord avec des GPU, aka les cartes graphiques de Nvidia, qui ont évolué pour bosser avec autre chose que des float (utilisé en 3D), pour arriver aux TPU de Google suivi par des offres de Nvidia (comme le V100 disponible dans les P3 d'AWS). Le monde de l'IA a rapidement mis en place des abstractions, comme Tensorflow pour travailler sur son code métier, sans trop se soucier d'où ça tournera.
Pour héberger du site web classique, les processeurs font peu de calculs compliqués, mais beaucoup de coordination et de gestions d'IO. Pour faire ça, et pour partager l'usage d'un serveur, avoir plein de coeurs est plus interessant que des coeurs qui vont vite. ARM est plutôt bon pour empiler des coeurs sur une puce, ce qui donne des monstres comme le ThunderX3, 96 coeurs pour 384 threads (x3 donc, mieux que le x2 de l'hyperthread d’Intel).
Abstractions hébergement
Cloud
Les 3 gros cloudeurs sont bien implantés, mais ça n'empêche pas l'apparition de nouveaux challengers. Petits et teigneux comme DigitalOcean en 2011, Vultr en 2014. À une autre échelle, Baidu, en 2012, sort son offre cloud, se positionnant tout de suite comme un Amazon chinois.
OVH sort son offre de Cloud public en 2015, basée sur OpenStack, qui deviendra par la suite un des plus gros cluster OpenStack.
Toujours en 2015, Free sort propre Cloud, novateur et ambitieux : Scaleway. Quelques temps après, la marque Scaleway remplace les noms Free et Illiad.
Du côté des morts importants, on notera Rackspace qui lâche son matériel en 2016 pour se recycler dans le consulting, ainsi que Joyent trublion du cloud (basé sur un fork maison de Solaris) qui nous a légué Nodejs, qui lâchera son cloud public en 2019.
Virtualisation
En 2010, la virtualisation est bien en place, avec Xen depuis 2003, et KVM depuis 2007.
OpenStack
En 2010, la NASA et Rackspace mettent en place OpenStack, une solution libre pour gérer son propre cloud. C'est gentil de leur part, mais ça part en sucette très vite : en 2010, on a le choix entre C++, Java et Python pour ce genre de projet, Python est choisi, mais à cette époque Python n'a pas de stack asynchrone décente, et son GIL n'empêche d'utiliser des threads. Le vrai problème, c’est la gouvernance du projet, OpenStack est un complot de lobbyistes, il y a plein de spécifications pour arriver à brancher son offre propriétaire sur les services qui composent le nuage. Dans le vrai monde, il faut un référant technique par brique de service, et des montées en version dantesques. Le ticket d'entrée d'OpenStack est monstrueux, l'idée est de mutualiser les coûts des gros acteurs, surtout pas de faciliter l'entrée de nouveaux arrivants. En France, dans les hébergeurs connus, seul OVH a eu le courage d'affronter OpenStack.
Provisioning
Le provisioning se généralise dans les années 2010, on passe de la bête gestion de configuration a du déclaratif : on réclame un état, le logiciel se charge de ne faire que les actions nécessaires, et ne relance que les services dont la configuration a changée.
Puppet) (2005) sert d'inspiration pour créer Chef) en 2009. On est dans le monde confortablement blingbling pour l’époque du Ruby, avec de l'héritage magique et des abstractions élégantes. L'autre monde possible est celui de Python, avec Salt) qui apparait en 2011, puis enfin Ansible) en 2012, avec plus de YAML que de Python. Ansible se fait racheter par RedHat en 2015.
Normaliser les API clouds
L'histoire est simple, AWS sort des tonnes d'acronymes avec des nouveaux services derrière; les autres galèrent pour suivre, et pour déterminer ce qui est un standard de fait méritant un clone.
libcloud tente de proposer une API neutre qui va normaliser à la truelle, pour exposer une API censée être universelle. Libcloud veut être neutre, il est finalement fade et naïf.
Les API cloud ne sont pas conçues pour des humains, mais pour du code, qui lui, sera utilisé par un humain.
Terraform
Terraform) apparait en 2014, et secoue les îlots de l'hébergement cloud.
Terraform attrape le problème par l'autre bout, en passant au déclaratif : on décrit ce que l'on souhaite avoir, le logiciel établit un plan des modifications à appliquer pour y arriver (en parallélisant ce qui le peut).
Terraform, c’est clairement de l'infra as code, mais pas du provisioning.
Terraform est devenu un standard de fait, et les gros hébergeurs cloud (AWS, GCE, Azur…) sortent le plugin terraform adéquat lorsqu'ils annoncent un nouveau service dans leur offre.
Terraform ne va pas se perdre dans la recherche d'un dénominateur commun entre les différentes offres cloud, et permet d'utiliser toute les finesses de votre cloud préféré. Changer d'hébergeur ne sera pas magique, mais le portage de la configuration Terraform sera simple. Si vous voulez un cloud portable, ce qui est un oxymore, le cloud n'a pas du tout envie que vous alliez voir aiileurs, il faudra utiliser des services libres qui pourront être déployé sur les différents cloud, en profitant des spécificité. Hashicorp, auteur de Terraform se positionne sur ce créneau avec Vault, Consul, Nomad (concurrent de k8s).
Conteneurs
Google, qui a eu besoin de scaler avant que les processeurs soient adaptés à la virtualisation, a développé le concept de conteneur qui permet une isolation et une juste répartition des ressources, sur un simple process, et en partageant le kernel avec l'hôte. Les outils de base sont les namespaces pour isoler, et les cgroups pour répartir l'accès aux ressources.
Docker
2013 voit la naissance de Docker) qui normalise la notion de conteneur, en utilisant les briques kernels libérées par Google utilisé pour leur projet Borg).
Docker prends rapidement le dessus sur les alternatives telles que Rkt et LXC.
Kubernetes
Kubernetes apparait peu de temps après, en 2014.
En 2015, K8s impose la normalisation des conteneurs sur Linux avec containerd, sous l'égide de la Cloud Native Computing Fundation. Containerd sert de base à Docker et K8s.
K8s est le baiser de la veuve de Google Cloud à Amazon Web Service.
K8s permet enfin de tenir la promesse "le cloud est élastique", mais sans dépendre d'un cloud spécifique. Petit détail important, sur un gros cloud, personne ne déploie son Kubernetes, mais tout le monde s'appuie sur l'offre infogérée du cloud, qui va proposer des solutions propriétaires pour gérer correctement l'abstraction réseau de k8s, point faible du produit. k8s devient la spécification pour que Google Cloud et Azur puisse proposer une alternative au rouleau compresseur AWS.
Podman
Redhat sort, un poil aigri, son Podman en 2017, en implémentant les spécifications issues de Docker, mais en se focalisant sur le rootless et l'absence de daemon.
Unikernel
Des chercheurs se sont demandés ce qui empêchait d'entasser plus de machines virtuelles sur un serveur. La conclusion est qu’avec de plus petites VM, on peut en mettre plus.
Pour diminuer la taille d'une VM, les Unikernel proposent de tout enlever, de n'avoir plus qu'un seul espace mémoire, quelques libs pour accéder à des trucs comme le réseau, et du code métier.
Ça marche plutôt bien, il est possible d'avoir un serveur web qui spwan une VM par requête, à un débit infernal.
La radicalité de l'approche peut être tentante, mais dans le monde réel, c'est une tannée à débuguer, et il faut tailler une roue avec son petit couteau pour chaque service.
lightvm
Les conteneurs sont fort pratiques, mais leur isolation n'est pas suffisante pour faire cohabiter des projets agressifs entre eux. Ça tombe bien, la virtualisation, avec les instructions spécifiques du processeur, ont une faible surface d'attaque, et sont considérés comme sécurisés. Ok, kvm a quelques CVEs, mais tous les services d’hébergements Cloud vous ferons partager une machine avec des inconnus.
Le principe de la lightvm est de partir d'un conteneur (un bout d'arborescence et une commande), mais de le lancer dans une vraie VM, avec un kernel minimaliste (aucun vrai driver, que du virtio), un init dépouillé.
Baidu utilise katacontainer alors que AWS utilise firecracker.
Les lightvms sont particulièrement adaptées au lambda (parfois nommé serverless) : elles démarrent vite, font une action avec un timeout rigoriste, et repartent tout aussi vite, le tout sur une machine massivement mutualisée.
Virtualisation matérielle
AWS, pour pousser encore plus loin le rendement de sa virtualisation utilise maintenant Nitro, des cartes dédiées pour exposer des disques durs, des cartes réseaux ou des enclaves pour la sécurité. Ces cartes permettent de simplifier le travail de l'hyperviseur (et donc libérer du CPU pour les hôtes), et même de partager des services avec des bare metals.
Sécurité et chiffrement
Au début des années 2010, Les outils et technologies de chiffrement étaient dans un drôle d'état, avec pas mal de drama pour OpenSSL, avec fort peu de ressource dédiées en comparaison avec son importance et de son nombre d'utilisateurs.
TLS passe en 1.3 en 2018 et apporte les courbes elliptiques, et moins d'aller-retour pour établir une première connexion.
Des outils matures et agréables apparaissent enfin :
cfssl remplace l'infâme easy-rsa pour se faire une PKI en ligne de commande.
Vault, en 2015, permet de bien gérer ses secrets et de générer des certificats temporaires.
Letsencrypt (2015) défonce le monde des certificats auto signés, et permet de rendre obligatoire la connexion chiffrée aux différents services Internet. HTTPS partout !
Wireguard (2016) rebat les cartes du VPN, pour tenter d'éradiquer IPsec, et déprécier OpenVPN. Intégré au kernel Linux, disponible sous plein d'OS, il est largement déployé par les offres VPN qui sponsorisent tant de contenus Youtube
Keybase (2014) permet enfin de lier une clef GPG à des identités publiques, et enfin arrêter le système de réseaux de confiance qui n'a jamais réellement fonctionné. 2020, coup de froid, Zoom se paye un peu de karma en rachetant Keybase et en gelant le projet.
Authentification
L'informatique adore les mots de passe, et le post-it collé sous le clavier, pour pas l'oublier.
Un mot de passe faible, ou utilisé sur plusieurs sites, c'est la garantie d'un drame.
D'ailleurs, allez jeter un oeil dans les listes de mots de passe compromis pour savoir si vous êtes contaminés : https://haveibeenpwned.com/
Sur cette décennie, une partie de l'effort a été fait en pédagogie, comme ces recommandations de l'ANSSI, l'autre partie avec les trousseaux et des mots de passe générés aléatoirement, renforcés par une double authentification.
La dématérialisation a bien avancé sur cette décennie, exposant plus de trésors à piller, rendant indispensable un réel effort sur la sécurité.
OAuth2
Oauth2 permet de déléguer l'authentification sur un site de confiance. La version 2, la première version recommandable sort en 2013.
D'abord adoptée par des sites grands publiques (pour avoir tout de suite des utilisateurs qualifiés, pas pour rendre service), il s'avère redoutable pour déprécier les SSO corporate, et le compte centralisé sur un LDAP.
Si votre application ne gère pas de base l'OAuth2, allez jeter un oeil à OAuth2-proxy il ya des patchs à nous dedans, pour mieux gérer Gitlab.
Deux facteurs
Pour limiter les risques d'avoir un de ses comptes compromis, il faut empiler les authentifications.
L'usage des SMS pour ce genre de chose est maintenant déprécié (grâce à des arnaques de doublets de cartes SIM), il faut utiliser un outil normalisé comme OTP, ou des outils spécifiques. Ces outils sont disponibles sur les téléphones/tablettes, ou au travers de petits objets, comme une Yubikey.
Web
Terminaux
Les appareils mobiles deviennent majoritaires sur le web en 2017. Si vous lisez cette page depuis un ordinateur, vous êtes minoritaire.
HTTP
HTTP/2 arrive en 2015, et permet le multiplexage, chose fort utile pour se passer de la concaténation souvent baroque des assets d'une page web. HTTP/3 propose de se passer de TCP, pour encore améliorer les latences sur les connexions intermittentes, mais ça ne devient testable qu’en 2021, pas encore bien sec.
Navigateurs
Internet Explorer disparait : déprécié en 2015, fin de vie en 2021. Il est remplacé par un outil utilisant le moteur de Chrome.
Ni oubli ni pardon pour la version 6 d'Internet Explorer.
Firefox continue son chemin, avec des choix excellents comme l'utilisation de Rust et autres optimisations sioux. Ça n'empêche pas son déclin face à l'envahissant Chrome : il passe de 28% à 6% entre 2011 et 2021, pendant que Chrome passe de 21% à 63%.
Firefox tente un Firefox OS à destination des smartphones en 2013, pour finalement l'enterrer en 2015, laissant un amer goût de gâchis.
Multimédia
Flash est mort. Déprécié en 2017, fin de vie en 2020. Il est dignement remplacé puisque du multimédia arrive dans la stack HTML5.
WebRTC (2011) amène la visioconférence dans le web, WebGL (2011 aussi) permet de faire souffler les ventilateurs, et WebAssembly permet de lancer des applications dans les navigateurs web.
Serveurs web
Après une longue et un peu vaine bagrare, Nginx dépasse Apache httpd en 2021 (Apache passe de 71% à 31% en 10 ans). Nginx fait maintenant partie des boring technologies, et c'est très bien comme ça, si vous voulez du frais, c'est vers Caddy qu'il faut aller zieuter.
Cloudflare (2009), une offre de CDN et WAF représente en 2021 plus de 20% des serveurs http}(https://w3techs.com/technologies/history_overview/web_server/ms/y). Ça marche bien, mais ça centralise un truc qui devrait être décentralisé, et ça s'occupe de votre terminaison TLS.
Une nouvelle niche apparaît : l'ingress, un proxy http devant votre nuée de conteneurs, qui va router vers qui de droit, en suivant le cycle de vie des conteneurs.
Il existe des outils pour configurer des proxys traditionnels (Nginx ou Haproxy), mais on voit apparaître des ingress native, comme Traefik qui sort sa v1 en 2016.
Développement
Méthodologie
Le développement logiciel s'industrialise, et se concentre sur la collaboration entre les différents membres participants (tous métiers confondus) au projet. Pour accompagner cette approche collaborative, apparaît Github (lancé en 2008, racheté par Microsoft en 2018), puis Gitlab en 2011.
Pour améliorer cette collaboration apparaît l'incontournable pull-request, une interface web pour discuter du développement fait sur une branche git. Pour améliorer la qualité (et couper court à toute une famille de polémiques), l'intégration continue lancera une analyse statique et surtout les différents tests, à chaque push. De fait, la CI participe à la discussion d'une pull request en râlant dés qu'une modification pète un truc. Jenkins), sorti en 2011 est un pionnier de l'intégration continue, mais il est ringardisé par des produits plus récents (les Gitlab-runners sont tellement plus élégants).
L'étape suivante est le déploiement continu (la CI déploie si les tests passent), pour faire des micro livraisons (et un éventuel rollback en cas de drame). Corriger le petit bout qui a changé est de fait plus simple que de faire le pompier sur une livraison big bang qui explose dans tous les sens.
Éditeur
La décennie commence pépère, coincée entre les tous vieux (vim et emacs) et les tout gros (Eclipse et Netbeans).
Github, clairement de culture web sort Electron) en 2013, un mashup de Chrome et Nodejs, pour créer des clients lourds.
En 2014, Github sort Atom) utilisant son Electron. Ça fait le job, la courbe d'apprentissage est plate (take that vim!), les plugins sont nombreux, et le partage d'éditeur facilite le peer coding avec un autre utilisateur Github. Le rachat de Github par Microsoft, qui a déjà un éditeur dans le même style éteint le projet. Github récidive en 2021 et lance de nouveau un éditeur, Zed bien plus ambitieux, en Rust, et toujours centré sur l'édition collaborative. Curieux de voir ce que ça va donner.
En 2015, Microsoft humilie Atom en démontrant comment utiliser correctement Electron, et sort VSCode. La complétion et le debug sont fluides, tout tombe sous la main, cet éditeur est impressionnant : on retrouve les fonctions d'un Eclipse mais sans l'impression de rouler en semi-remorque dans un centre ville.
Vim a toujours la cote, tous les éditeurs se doivent de fournir un plugin pour avoir les commandes Vim, mais son code est raide, et son dialecte pour écrire les plugins est en fin de vie.
Du coup, paf, un fork, et en 2014 sort Neovim, avec une architecture asynchrone (les plugins ne peuvent plus bloquer l'édition), et le Lua remplace l'infame vim-script. nvim est toujours un éditeur dans le terminal, avec différents projets pour proposer des interfaces utilisateur.
Analyse statique
La profusion d'éditeurs (qui s'ajoute à ceux qui existent déjà), et l'apparition de nouveaux langages met en valeur un nouveau drame : Pour que les éditeurs gèrent correctement tous les langages, ça oblige à remplir toutes les cases d'un tableau éditeur/langage.
Originellement développé par Microsoft pour les besoins de VSCode, normalisé avec l'aide de RedHat, en 2016, sort https://langserver.org/. Un protocole simple qui permet de développer un serveur par langage, et avec juste un client LSP, n'importe quel éditeur pourra profiter du langage.
LSP fonctionne si bien qu'il est maintenant utilisé pour effectuer des recherches dans du code (et pas juste en full text) et même de naviguer dans l'affichage web d'un projet comme le propose Github.
Sourcegraph, pionnier de l'indexation de code est libéré en 2018.
Chaque langage propose maintenant ses outils d'analyse statique, mais dans un fouillis assez pénible. Il existe un méta analyseur pour ajouter un analyseur à la liste.
Sonarqube existe depuis toujours (en 2006).
Code climate apparaît en 2015, et Gitlab l'intègre a son offre. Code Climate est juste un méta analyseur avec une config et un format de sorti normalisé.
Semgrep fork d'un des outils de Facebook, datant de 2020, permet de définir des règles pour attraper du code dangereux.
Cette approche, lancée sur l'intégralité de Github doit permettre de trouver de chouettes 0day.
Github le fait, avec son CodeQL et offre des analyses à ses utilisateurs.
Typage statique
L'analyse du code permet aux éditeurs de faire du coloriage pour l'affichage (comme le fait pygments), mais le vrai confort vient de la complétion. Pour avoir de la complétion correcte (et pas juste la magie crédible que propose Vim), il faut que le langage utilise du typage statique.
En proposant Typescript comme dialecte Javascript, Microsoft apporte surtout le typage statique qui permet aux éditeurs de faire de la complétion correcte. Eclipse le propose depuis toujours pour Java, et bien il n'y a pas de raison que les autres langages ne puissent pas le faire. Le gain du typage fort pour qu'une personne entre sur un projet existant est énorme.
Python a longtemps daubé le typage fort, pour aller plus vite, mais en 2014, sort la PEP 484, qui permet d'annoter les types, mais promis juré, le runtime n'en tiendra pas compte, Python reste Python avec son typage mou.
Javascript doit avoir un des typages les plus yolo, les versions successives d'ecmascript amènent une rigueur et un déterminisme bienvenu, mais il faut se tourner vers Typescript pour avoir un vrai typage.
Les PHP récents apportent le typage, mais pas d'inquiétude, Wordpress ne l'utilise pas.
Java et ses dialectes l'ont de base, tout comme Golang ou Rust.
Langages
Le petit monde des langages utilisés sur les serveurs a bien bougé ces 10 dernières années.
On a vu doucement s'éteindre Perl, mais pas de nostalgie, le flambeau du code de poète est repris courageusement par Ruby.
Erlang qui a eu son heure de gloire retombe dans les limbes, mais les rubyistes ont décidé de créer Elixir, même runtime sans la syntaxe masochiste. Crypto-élitiste, Elixir est quand même un bel hommage à Joe Amrstrong (1950-2019)) qui n'a jamais eu peur de la parallélisation et la résilience.
JavaScript
Nodejs, en 2009 montre qu'il est possible d'avoir un langage de script nativement asynchrone et avec des performances correctes grâce au JIT. Nodejs est un emballage de V8, le moteur javascript de Chrome, et il a démarré avant que les spécifications de ecmascript atteignent leur rythme de croisière, frileux à l'idée de proposer une idée qui sera contredite dans la prochaine release de V8, nodejs refuse d'avoir une stdlib ambitieuse et délègue tout à la notion de micro-libraries : on va piocher dans plein de petites bibliothèques que l'on serait capable de réécrire si le mainteneur change de hobby. Le résultat est catastrophique, les dossiers de vendoring ont des tailles indécentes, et on peut être assurés que n'importe quel code de plus d'un mois renverra des alertes de sécurité.
Nodejs apparaît au moment où le javascript coté client gagne en ambition (poussé par Chrome, suivi par Firefox). Il est maintenant impensable qu'un développeur web ne maîtrise pas javascript, ne serait-ce que pour farcir son HTML5. De fait, le vivier de développeur javascript (front et back) devient énorme. Les performances et la tenue à la charge de Node en font un bon choix, pour peu que votre pm2 compense votre mauvaise maîtrise des erreurs, et que vous publiez régulièrement votre code, mis à jour à chaque livraison.
Le créateur de Nodejs, cramé par son oeuvre, revient plus sereinement en 2018 avec Deno) toujours basé sur V8, mais avec minimalisme et hygiène : la glue est en Rust, une stdlib rigoureuse est fournie…
Le but premier du JS est de rendre possible la création d'applications, sans dépendre d'un OS, et de permettre les mises à jour sans demander l'avis de quiconque. Google l'a utilisé pour pousser ses produits sans demander l'avis de Microsoft. Microsoft qui se venge en créant Typescript en 2012, un dialecte qui se compile en javascript, mais qui apporte le confort d'esprit du typage fort, et une belle intégration aux éditeurs de code (complétion et analyse statique).
Autre effet surprenant, javascript annihile la guéguerre des langages (PHP vs Python vs Ruby vs Whatever) pour s'imposer dans le build des assets. Techniquement, le JIT de javascript n'est pas actif lors de la première itération et donc les outils en ligne de commande en JS sont de gros veaux, mais c'est trop tard, Sass, Less et autre webpack sont dans la place.
Electron, une créature de Frankenstein basé sur Chrome et Nodejs, permet de créer des clients lourds cross plateform, avec uniquement des technos web. Il faut compter 2Go de RAM par application, sans avoir de gain réel par rapport à une application web. Globalement décevant, Electron sert de socle à quelques pépites comme VSCode.
Golang
Google en a marre de perdre du temps à compiler du C++ qui n'utilise pas de manière correcte et systématique les IOs. Java qui était censé corriger les problèmes de C++ n'a pas réussit, et Python, autre langage officiel de Google est complètement inadapté à la programmation système. Du coup, Google crée un nouveau langage, compilé, qui gère bien les IOs, et n'est pas freiné par la cryptographie. Conçu dés le départ comme non innovant (il n'apporte aucun nouveau concept), il ne fait pas d'effort pour être aimé, mais ce n'est pas possible de le détester. Golang commence sa vie comme boring technology. Golang compile vite et livre un gros binaire qu'on a qu'à déposer sur un serveur pour déployer son application. Golang, poussé par la volonté (et la thune) de Google se permet de débuter avec une stdlib de référence, et une implémentation en assembleur de tout ce qui touche à la cryptographie. Aucun langage basé sur une communauté de fanboys ne peut se permettre ça (et c'est un poil frustrant).
Golang fait exploser la barrière technique pour écrire du code système, et taille des croupières à Java pour cette spécialité. Sa stabilité et sa parcimonie dans l'utilisation de la RAM en font l'ami des administrateurs.
Sans Golang pas de Docker, Influxdata, Hashicorp, Kubernetes ou Prometheus.
Rust
Rust, lancé en 2006 montre qu'il est possible d'avoir un langage de bas niveau, concurrent crédible du C, tout en maitrisant la mémoire pour enfin éradiquer toute une famille de failles de sécurité. Son adoption par Firefox le propulse du labo de recherche à la hype du monde réel. Beaucoup de petits outils, quelques applications, mais avec son potentiel, on peut s'attendre à de chouettes surprises.
WASM
Des gens se sont amusés à brancher une sortie javascript sur le compilateur LLVM, avec emscripten. Bon, ça fonctionne bien, mais livrer des tonnes de javascript généré, c'est loin d'être efficient. Des tâtonnements ont été faits, comme livrer un javascript déjà parsé, pour finalement prendre du recul et bosser à la fois sur le format et le runtime, c'est ainsi que WASM naquit en 2015. Initialement conçu pour les navigateurs web (et les processeurs Intel et ARM), WASM s'avère être un format pour livrer du code sans surcoût de performance, isolé dans un bac à sable vigoureux.
Rust étant le langage de prédilection pour fournit du WASM, il est maintenant courant que des applications en Rust acceptent des plugins en wasm. Ça nous change de Lua, et surtout ça vexe bien Golang qui est incapable de proposer quelque chose d'aussi élégant et efficace.
L'abstraction du langage et la qualité de son bac à sable font de WASM un format universel pour créer des plugins ou des offres serverless.
WASM aurait-il tenu la promesse du Java des origines ?
React
React apparait en 2013, et bouscule le monde des applications web. L'ère de jquery est enfin close. React permet de faire des applications monopage web performantes, mais il impose aussi un workflow de compilation (webpack et ses amis). Le concept de React est de confier à son moteur de rendu le soin de ne modifier que les portions de page nécessaires. React promeut la création de composants réutilisables.
PHP
PHP s'emmèle les pinceaux dans un PHP6 qui ne verra jamais la lumière du soleil, mais permettra la sortie d'un PHP 7 en 2015. PHP tente le grand écart entre garder une compatibilité ascendante (et une logithèque vieillissante) et devenir un langage moderne et performant, adapté à la complétion des IDE et à l'analyse statique. Une 8.0 sort en 2021 et amorce l'ère du JIT et de l'asynchrone.
On peut ricaner sur les PHPteurs, mais en 2021, PHP est utilisé par presque 80% des sites webs répertoriés par W3tech
Wordpress atteint son sommet de hype en 2015, pour redescendre à la même vitesse que sa montée.
Drupal rentre dans le rang avec sa version 7 en 2011, et bazarde sa lib perso pour utiliser Symfony.
Symfony reste le boss en France, mais dans le reste du monde, c'est Laravel qui ravit la place en 2014
Python
Python tente la migration vers une nouvelle version majeur, la 3.0 en 2008, il faut attendre 2015 pour avoir une version 3.x correcte, avec de l'asynchrone. Python 2 est déprécié en 2020. Cette migration n’a été rien de moins que traumatisante.
Python qui n'a jamais vraiment aimé le web (mais il a des amis pour ça, comme requests, django ou flask), est devenu l'ami des scientifiques et des startups. Numpy est une base saine pour manger de la matrice, et donc construire des outils comme du machine learning (sklearn) ou du traitement du langage (Spacy).
L'arme secrète de Python pour la science est Jupyter, sorti en 2014, une console disponible via une interface web, pour faire tranquillement des itérations en visualisant ce que l'on fait. Le notebook peut être repris et rejoué par une autre personne, ou utilisé pour générer un document.
Java
Il y a 10 ans, Java a eu un coup de mou (il passe dans le giron d'Oracle via le rachat de Sun), et Scala) (sorti en 2004) donne un peu de fraicheur avec une double approche objet/fonctionnel et de la parallélisation efficace.. Avec du recul, la syntaxe ambiguë en hommage à Ruby n'aide pas à la maintenance et Twitter se dit que finalement, du java lisible, c'est pas plus mal. Surtout que l'arme secrète de Scala est une lib en Java : Akka pour avoir du passage de message pour avoir des applications résiliantes et distribuées (à la Erlang, quoi).
La montée en puissance des applications web propulsées par la reprise de l'évolution des navigateurs web, fait de l'ombre aux applications natives des smartphones. Cordova, liberé en 2011, mouline des sites web en applications pour téléphone.
Pour avoir de l'exclusivité et de meilleures performances (une meilleure gestion de l'énergie essentiellement), les smartphones doivent avoir des applications natives, et non des portages automatiques. Pour attirer plus de développeurs, Google, en 2017, recommande pour Android Kotlin) (sorti en 2011), un dialecte Java. Kotlin est le pendant Android du Swift) d'Apple pour iOS, en 2014.
Télémétrie
Avant, le Web consistait à avoir une présence en ligne, si la home s'affichait, tout le monde était heureux, et on passait à autre chose. Ça, c'était avant.
Maintenant, on veut des sites qui ont des utilisateurs, qui font des trucs, et si ça rame, ils vont voir ailleurs.
Mesures
Un des pionniers de la télémétrie est New Relic, sorti en 2008. Ses tarifs et son ton alarmiste (avec des images de serveurs qui prennent feu) ont lassé.
En 2010 sort Datadog, plus rationnel.
En libre, graphite et Statsd sont dans la place, mais bof, on ne peut pas en faire grand chose.
Grafana est à l'origine un obscur projet pour visualiser des métriques. Il servira de base au projet Grafana, qui en profite pour refaire le backend en golang, et aussi de fork pour Kibana le K de ELK.
En ce début de décennie, le stockage de mesures passe par des bases à taille fixe, comme les rrdtools ou le whisper de graphite.
Basé sur l'outil employé en interne par Google, en 2012 sort Prometheus). Prometheus a une approche originale, c'est lui qui va chercher les mesures (du pull plutôt que du push), et il débarque avec Alertmanager pour qu'un peu de mathématiques et des mesures déclenchent une alerte.
Influxdb sort 2013 et propose une base de données orientées timeseries plus classique, accompagné de Telegraf, qui va aller chercher des mesures à pousser dans Influxdb.
Influxdb fait le pari d'utiliser un presque SQL, erreur fatale, un SQL est complet ou n'est pas, du coup, sa version 2 propose un élégant dialecte orient flux, nommé Flux, qui permet de faire des jointures et autres mathématiques évoluées. Influxdb, devenu Infludata était fourni avec Kapacitor, un outil de requête pour générer des alertes. Fausse bonne idée, l'outil s'avère inutilisable, en plus d'être inadapté à l'infra as code. Qu'à cela ne tienne, Flux permet tout aussi bien de requêter dans le but d'afficher des trucs que de lever des alertes.
Les timeseries, c'est bien, mais ça gère mal l'arité (pour Prometheus tout comme Influxdb). Le concept d'une timeseries, c'est d'avoir des événements horodatés avec un ensemble d'étiquettes pour faire du tri, et de valeurs, pour faire des maths. Dans les labels, on met le nom du projet et de la machine par exemple. L'arité sera le nombre de projets ou de machines, dans cet exemple, et ça passera tranquillement. Si par exemple, vous avez comme label le nom des conteneurs, qu'ils sont déterminés aléatoirement, et relancés régulièrement parce que ce sont des crons, et là… l'arité va exploser.
Influxdb promet IOx un moteur de stockage en Rust s'appuyant sur Arrow, DataFusion (pour avoir du vrai SQL), Parquet pour un stockage orienté colonnes dans des fichiers à la S3. IOx promet plein de choses, mais il reste beaucoup de travail.
Influxdb, tout comme Prometheus, promettent de ne plus craindre les grosses arités, en 2022. On attend de voir.
Traces
En 2015 sort Zipkin suivi en 2016 de Jaeger (par Uber) qui fait maintenant partie du CNCF, deux outils de tracing.
Le principe du tracing est d'échantillonner des mesures de toute une grappe de services.
Par exemple, une page web va faire quelques requêtes SQL et des appels à des services tiers. Le tracing permettra de voir ce qui est parallélisé, ce qui bloque, et comment est composé la latence de cette requête.
Grafana lance Tempo, en 2020 pour lui aussi manger de la trace.
Journaux
Ranger ses journaux, ça existe depuis la nuit des temps, avec syslog par exemple. Depuis, on a évolué, avec des services non bloquants, mais en TCP, qui envoie des lots compressés, peut attendre un peu, relancer un envoie raté, et en face, on peut maintenant ranger et rechercher (pas juste un gros grep).
Logstash pousse des trucs bien rangés dans Elasticsearch depuis 2009. Bon, le jruby qui met une minute à se relancer pour lire sa nouvelle configuration, c'est maintenant ringard. Filebeat fait moins de choses, mais en Golang, et à un coût bien moindre que Logstash.
Fluentd transporte et range les logs depuis 2011. Fluentd est en Ruby, et juste comme forwarder de logs, ce n'est pas raisonnable. Fluentbit vient épauler le gros Fluentd en 2014, il est en C, sans dépendance pénible pour le déployer et permet de ranger vos logs avant de l'envoyer a un endroit approprié, pas juste vers Fluentd.
En 2018, Grafana ajoute le dernier éléments de sa stack, Loki, son mangeur de logs. L'architecture basée sur celle de Prometheus, a commencé par être ambitieuse (gros volume entassé dans du S3, index en Cassandra, services distribués) avant de revenir à la raison avec sa version 2, et une installation avec un simple binaire.
Normalisation de la télémétrie
Les clouds sont friands de télémétrie, et comme c'est tellement facile de mettre du bazar dans le cloud, la visibilité est importante. Les services fournis par les clouds sont maintenant équipés de sonde, mais le Graal est d'arriver à assembler les mesures métiers, et les mesures des services.
Grafana a atteint le statut de standard pour la visualisation de données, et des plugins permettent de taper dans des mesures propriétaires, spécifiques aux hébergeurs.
Fouiller dans les mesures, c'est bien, mais normaliser leur recueil est encore mieux.
Google s'est attelé à cette tache, car il adore défoncer les exclusivités d’AWS, avec Open Telemetry, qui va clairement faciliter l'instrumentation du code métier, sans dépendre d'un hébergeur spécifique.
Bases de données
Belle décennie pour Postgresql, qui passe de la 9.1 à la 14. Poussé par la concurrence, Postgresql lâche son approche rigoriste, et gère maintenant le JSON, des droits fins, une réplication intégrée, des tables orientées colonne.
Le rachat de Mysql par Sun, lui-même racheté par Oracle, met en avant un de ses forks Mariadb. Debian acte cette transition en mettant du Mariadb par défaut depuis sa version 9.
Les bases de données qui apparaissent montrent que le SQL reste un standard incontournable. Facebook prouve le contraire en proposant en 2012 une approche inverse avec graphql, qui permet à l'application de naviguer dans des données relationnelles avec une syntaxe simple, sans passer par un ORM, sans avoir à créer un backend spécifique.
Orienté fichiers
Mongodb (2009) a survécu, saluons l'effort de communication pour y arriver, ainsi que la haine grandissante du SQL qui a permis cela. AWS propose de cannibaliser Mongodb avec son service DocumentDB, entrainant un changement de licence (en 2019) pour ne plus permettre de proposer une offre as a service
Riak et Couchdb, eux, n'ont pas survécu.
Rethinkdb fait un départ en fanfare en 2009, pour finalement être lâché par son éditeur 2016, et confié aux bons soins de sa communauté.
Orienté colonnes
Une surprise arrive de Russie, avec Clickhouse en 2016, par Yandex.
Un plugin pour Postgresql, Citus permet de goûter aux joies des colonnes depuis 2016.
Le mail se fait martyriser par les outils de discussion comme Télégram, Whatsapp et Slack. Le mail sert maintenant à récupérer un mot de passe et recevoir des notifications de Linkedin.
Pourtant, il y a des nouveautés importantes, comme DKIM en 2011, SPF en 2014 et finalement DMARC en 2015, pour tenter d'endiguer une partie du SPAM.
GPG, en 10 ans n'a pas évolué d'un iota, même si Thunderbird le gère en natif depuis peu.
GNU/Linux
GNU/Linux poursuit son chemin et apporte son lot de nouveautés. La blague "est-ce que Linux est enfin prêt pour le Desktop" n'a plus droit de cité, la faute à Android, mais ça n'empêche pas les développeurs d'avancer sur le sujet.
Les namespaces (2002) et les cgroups (2008) permettent de bien ranger ses process.
NetworkManager (2004) pour retrouver son wifi et ses différents VPN.
D-bus en 2006, pour pouvoir faire des trucs sans être root, et pour avoir des bureaux intégrants différents services.
iwd pour avoir du wifi (avec du DBus dedans).
systemd remet à plat l'init de Linux en 2010, Debian le déploie dans sa version 8, Jessie en 2015.
Wayland) Dans Debian 10, en 2019. Pour avoir une interface graphique, et aller au delà de ce que peut proposer X11.
Btrfs 2013 pour pimper vos disques durs. XFS est ringard, Ext4 fonctionne, ReiserFS s'est fait assassiner, il reste "Better FS" qui comble la frustration amenée par ZFS, le dernier cadeau de Sun pour les BSD.
eBPF 2019. Les Berkley Packet Filter ont démontré leur utilité pour filtrer du réseau. Solaris a depuis des lustres le magnifique DTrace, que les linuxiens lui envient. Pour améliorer le tracing et le debug de bas niveau, Linux a maintenant eBPF, une généralisation de BPF pour coller du bytecode dans le kernel, et démultiplier les possibilités d'exploration.
polkit 2006, nouveau nom en 2012. Pour avoir une gestion des droits fine, sans la violence de sudo, mais avec de chouettes CVE comme CVE-2021-4034.
Ligne de commande et outils
Une partie des outils que l'on pensait immuables ont maintenant des alternatives, et encore, ce n'est que le début, les rustacéens ont décidé de tout recoder en Rust : coreutils.
ipremplaceifconfig(pour tripoter le réseau)zshdétrônebash(le shell)ssremplacenetstat(pour voir qui cause)tmuxremplacescreen(pour partager un terminal)curldétrônewget(le client réseau universel)libvpsdétrôneimagemagick(pour bidouiller du pixel)sftpremplacescp(pour bouger des données)
Quoi de neuf dans 10 ans
Faire une rétrospective n'est pas si compliqué, faire de la prospective est d'une autre envergure, avec la certitude de se vautrer sur une partie des points.
Laurent Alexandre sera backupé dans un bucket S3, mais on aura perdu la clef de chiffrement, ce qui est ballot.
OS
On aura un réel usage pour Fuchsia plutôt qu'une chouette hégémonie de Linux ?
On aura certainement plus de Rust dans le kernel (Linux et Windows, ne soyons pas sectaire), et finalement du Rust à tous les étages.
License
Le laminage de la GPL par les BSD va continuer, Stallman va bouder.
La SSPL va devoir être dégainer fréquemment pour limiter le pillage du libre par les gros du cloud.
Communauté
Plus de fondations pour limiter le nombre de mainteneurs qui meurent de faim, alors que leur projets sont utilisés par tant d'autres.
L'échec de l'UX libre ne va pas s'arranger, le libre va progresser, mais dans les entrailles, pas au contact des utilisateurs finaux, sur le modèle d'Android ou même iOS.
Langages
Tous les langages vénérables comme Python, PHP, Ruby, sont des langages de script développés à l'époque ou les machines avait un seul processeur qui passait son temps à attendre le disque dur qui grinçait.
Maintenant que le stockage se fait en SSD sur des bus de carte vidéo (le NVMe), ou utilise de la RAM persistante avec des connexions réseau approchant les 100Go, la donne est différente. Le langage ne fait plus confiance à l'utilisateur pour ne plus faire d'erreur, et il faut optimiser l'utilisation du CPU, les IOs n'étant plus un frein. Les langages doivent être a minima asynchrones, utiliser une compilation (implicite avec du JIT ou explicite). La vélocité de développement et le coût des ressources restent évidement un critère, mais la composition avec un peu de code métier (un peu lent) avec des services (performants) va devenir la norme.
Le développement côté front est maintenant déverrouillé par l'écosystème Javascript et Webassembly, et le code côté serveur n'a plus à se soucier de générer du HTML à la demande, il se contente de fournir des services, composables côté client, et même avec des technologies non web, spécifiques aux smartphones. La personnalisation se fait côté client, ou sur du edge computing lié à un CDN.
Materiel
Pour continuer à créer de la données et du calcul, en diminuant la facture énergétique, il va falloir continuer à densifier, et spécialiser une partie des tâches (FPGA, puis silicone pour les grandes séries).
Les notations sur le coût de l'hébergement (énergie et extraction de matière première) vont favoriser les gros cloud, qui vont bénéficier des économies d'échelle et d'une maitrise de bout en bout de leur offre, du matériel au logiciel.
La sur-spécialisation des usines s'avère être très fragile, une inondation suffit à créer une pénurie de disques durs. On peut espérer un retour du silicone près de chez nous.
Les nouveautés issues des smartphones vont continuer d'irriguer les laptops et ensuite les serveurs. La notion de mises en veille, de tâches de fonds, et de périodes de burst vont avoir leur place sur les serveurs. En plafonnant les débits des différents bus, la notion de localité d'un service va être de plus en plus floue. Cette mobilité permettra de concentrer les tâches sur une partie des machines physique, et de mettre en veille le reste. Ce flou existe déjà dans les smartphones. Vous savez ce qui est fait sur place ou à distance, stocker sur place ou plus loin vous ?
Le stream de tout et n'importe quoi (musique, vidéos, jeux) va avoir du mal à se verdir, surtout avec l'augmentation des possibilités de stockage.
Les améliorations réalisées pour les réseaux chaotiques, tout comme l'accès à une énergie intermittente devrait amener un peu de résilience, les technologies anciennes (radio LO, FM, HF…) vont continuer de rendre service. Les accès Internet via les flottes de satellites qui salopent les photos d'astronomie devrait décoincer les zones blanches et pallier la promesse qui a fait pshitt de la fibre partout. Les réseaux maillés et peer to peer, pourront aider pour les zones mal couvertes, mais surtout pour contourner des histoires de censures, la carte compact flash à dos de mules a fait ses preuves, on peut espérer des trucs à base d'ondes radio.
Coté terminaux, l'obligation de pouvoir réparer, et d'avoir cycles de vie plus longs vont changer le rythme et l'apparence du matériel, et . Les 3 ans pour un laptop, 18 mois pour un smartphone, était clairement pousse au crime. Le parc de terminaux va devenir plus hétérogène. iFixit va pouvoir distribuer de la bonne et mauvaise note! Le dilemme entre optimiser et attendre la prochaine génération de matériel va trouver une réponse définitive. Le chargement par induction va se faire engueuler, son rendement est lamentable. Attendez-vous à un retour des écrans LCD verdâtres, des claviers mécaniques et des batteries que l'on peut changer.
Moore a terminé son cycle, on avait le ciel pour limite, et bien on a atteint le ciel. Nos yeux ne peuvent pas voir plus de pixel qu'un écran retina, les latences réseau sont bien souvent meilleures que celles de votre cerveau, les débits largement décadents (pour peu que vous soyez dans une mégapole), vous n'avez déjà plus le temps de tout écouter, tout voir, tout liker, les besoins en RAM et en calcul ont aussi atteint un plafond. Black Mirror n'est pas une prophétie ou un mode d'emploi.
Ce n'est pas grave, hein, c'est juste le passage de l'adolescence avec sa forte croissance et l'exploration de tous les excès, vers l'âge adulte.
Il restera toujours du contenu à produire et découvrir, des humains avec qui partager.
