Le film "2001 : l'Odyssée de l'espace", sorti en 1968, s'ouvre sur une scène mémorable de singes primitifs rôdant dans un désert, qui débouche sur une bagarre. Vers la fin de la séquence, un singe ramasse un os et l'utilise comme arme. Sa faction applaudit tandis qu'une musique classique dramatique est jouée (Thus Spake Zarathustra, Op. 30, de Richard Strauss, pour être précis).
Soudain, un bloc noir géant, appelé familièrement "monolithe", fait son apparition. Les singes tombent dans un silence collectif et le regardent avec stupéfaction... Bien que les détails du reste du film ne soient pas pertinents ici, le thème ne l'est pas. Dans "2001", une IA nommée HAL, qui a été installée pour commander un vaisseau spatial, devient incontrôlable. Ce qu'elle fait peut être une interprétation extrême de ce que les philosophes et les techniciens ont toujours considéré comme la façon la plus probable pour notre espèce de tomber en disgrâce - par des conséquences imprévues liées à l'utilisation d'une nouvelle technologie.
L'idée ici n'est pas de sombrer dans le catastrophisme mais, idéalement, de recadrer la façon dont nous envisageons l'adoption d'une nouvelle technologie. Que nous adoptions de nouveaux moteurs, de nouveaux processeurs ou de nouveaux modèles de conception de logiciels, nous devons toujours être conscients qu'ils nous prendront par surprise, précisément parce qu'il s'agit d'une nouvelle expérience pour l'humanité, sans parler de la vôtre ou de celle de votre équipe, de votre entreprise ou même de votre pays.
Les 5 facteurs de la surprise logicielle
Dans le cas du développement de logiciels et de son évolution, de nombreux développements au cours des dernières décennies ont modifié le paysage de manière significative. La nature même du développement de logiciels offre quelques raisons d'être constamment surpris. En voici quelques exemples :
1. Le matériel évolue constamment
Des pièces comme les processeurs et les accéléromètres qui nécessitent des pilotes spécialisés
Des appareils entiers tels que le matériel d'informatique en nuage ou les smartphones
Les logiciels qui nécessitent de nouveaux processeurs comme les TPU et d'autres puces axées sur l'IA ou de nouveaux GPU pour les jeux en haute résolution.
2. Les attentes des clients changent en fonction de ce qui est actuellement possible
La 5G permet des accords de niveau de service plus stricts, ce qui oblige les entreprises à mettre à niveau leur infrastructure.
Intégration d'API telles que Facebook, Google et Microsoft single sign-on (SSO)
Des services concurrents qui "font la course au sommet" en termes de qualité de service.
3. Les domaines et les paradigmes deviennent de plus en plus complexes, ce qui accroît la difficulté d'un travail rapide
Domaines nécessitant une conception complexe des données
Les paradigmes logiciels qui permettent d'obtenir de nouvelles fonctionnalités ou des gains d'efficacité au détriment de la simplicité technique.
4. Les exigences des clients évoluent rapidement, souvent plus vite que les logiciels ne peuvent être développés
5. Les plates-formes et les bibliothèques logicielles deviennent tellement omniprésentes que les clients exigent désormais de s'appuyer sur une base logicielle de composants et ne veulent pas construire un système à partir de zéro.
Ces cinq facteurs en particulier entraînent de nombreuses incompatibilités dans le paysage logiciel. Par exemple, les développeurs passent parfois des années à apprendre à utiliser des outils qu'ils ne savent pas construire mais qu'ils comprennent parfaitement sur le plan conceptuel, avant que cet outil ne soit remplacé par quelque chose de meilleur mais de plus complexe, qui peut également utiliser de nouvelles techniques matérielles et de conception.
Il peut s'agir d'une nouvelle bibliothèque de streaming avec des capacités accrues, ou peut-être d'un passage à graalVM pour des performances d'exécution accrues. Les développeurs doivent alors non seulement se convaincre que l'apprentissage de ces outils et le remplacement des anciens en valent la peine, mais aussi convaincre leurs responsables et leurs dirigeants que les avantages techniques et fonctionnels valent la peine d'être investis. Les développeurs doivent avoir le temps d'apprendre, et il peut être nécessaire de faire appel à de nouveaux développeurs. Si une entreprise hésite ne serait-ce qu'un an, elle risque de manquer complètement le coche et de se retrouver coincée dans l'"âge des ténèbres", avec des clients qui menacent de partir s'ils ne procèdent pas rapidement à une mise à niveau. Cette situation peut souvent conduire à une mise en service précipitée.
Si vous souhaitez éviter ce problème, vous êtes au bon endroit. En nous concentrant sur l'avant-garde et en gardant un œil vigilant sur l'avant-garde, nous pensons savoir à quoi ressemblera le développeur de l'avenir proche.
Quels sont les avantages des développeurs du futur par rapport aux développeurs actuels ?
Le développeur du futur est avant tout un développeur complet. Polyglotte, il est capable de gérer à la fois l'interface utilisateur du client et la programmation du serveur dorsal, y compris les tests, et DevOps (déploiement et maintenance, y compris la réponse aux erreurs en direct) si nécessaire.
Mais il faut espérer que la plupart des problèmes de DevOps seront évités grâce à quelque chose que le développeur du futur utilise beaucoup plus que les développeurs actuels : les services gérés et les plates-formes en tant que service (PaaS). En utilisant des plateformes de déploiement et d'observabilité externes, orientées vers le nuage et non construites de toutes pièces, comme GCP, AWS, ou même des plateformes qui génèrent également du code comme Kalix ou Golem, le développeur du futur peut se concentrer sur le développement plutôt que sur le déploiement. Bien que le développeur du futur s'occupe toujours de la supervision des déploiements, y compris la supervision des journaux, le signalement et la correction des bogues, et tous les correctifs nécessaires qui doivent être déployés, tous les problèmes de mise à l'échelle sont gérés sous le capot par des configurations non complexes basées sur le code, données au fournisseur de services gérés ou au fournisseur de PaaS.
Le développeur du futur, qui a une préférence pour un style de codage particulier, peut dépasser ses préjugés pour répondre à n'importe quelle préoccupation - tant qu'il dispose d'outils qu'il sait utiliser suffisamment bien pour faire le travail. Si cela implique l'utilisation de l'IA pour générer du code afin de construire des services rapidement, ou même si un nouveau langage doit être appris, qu'il en soit ainsi.
Services réactifs (axés sur les messages)
Le développeur du futur croit également en la construction de systèmes réactifs, pilotés par les messages. Pour ceux qui ne sont pas familiers avec ces termes, faisons un peu de déballage.
Un service piloté par les messages est un concept qui diverge fortement des architectures traditionnelles qui dépendent de la récupération d'une base de données à chaque appel de requête. Les architectures axées sur les messages permettent le traitement de données qui peuvent être séparées en services individuels, ce qui permet d'ajouter de nouvelles fonctionnalités sans modifier les services existants et sans stocker tout ce qui se passe dans une base de données avant de pouvoir agir. En permettant aux bases de données d'être plus facilement intégrées dans les applications en temps réel et en séparant leurs responsabilités en fonction de la manière dont les données sont censées être extraites, nous pouvons répondre aux demandes de la multitude d'utilisateurs qui émettent des requêtes avec les temps de réponse rapides attendus. Cela nous permet également d'évoluer de manière élastique en fonction de l'utilisation d'une manière précise, de sorte que nous n'évoluons que ce qui doit évoluer lorsque le besoin s'en fait sentir.
Les architectures axées sur les messages comportent quatre types de messages : les commandes, les requêtes, les événements (choses qui se sont déjà produites) ou les résultats d'une commande ou d'une requête. Ici, les commandes et les requêtes sont toujours tournées vers l'avenir, tandis que les événements font toujours référence à quelque chose qui s'est produit dans le passé. En optimisant la base de données de messages pour la relecture d'événements et le stockage de leur état dans des systèmes de récupération de données en temps réel, les architectures axées sur les messages permettent aux systèmes de se souvenir d'anciens états si nécessaire, ce qui pourrait poser des problèmes de version dans les systèmes traditionnels basés sur des bases de données.
Dans les systèmes axés sur les messages, nous utilisons couramment le "modèle d'acteur" pour des raisons d'évolutivité et de résilience en évitant les problèmes de concurrence. Le modèle d'acteur est un modèle de conception qui impose de petites entités délimitées en fonction de leurs homologues dans le monde réel. Cela signifie bien sûr que la conception du domaine est nécessaire avant le développement. Cependant, nous pensons que cela devrait toujours être le cas afin que nous ne nous lancions pas dans le développement sans avoir réfléchi à notre modèle de données, ce qui nécessiterait d'importants changements en raison de l'évolution des données. De même, si le domaine est petit, nous pouvons nous concentrer davantage sur le développement dans le cadre d'un engagement court. Toutefois, si le domaine est très complexe, il se peut que seule une petite partie soit réalisable au cours d'une courte mission et que des techniques, des plateformes ou des bibliothèques spécialisées soient nécessaires.
Le modèle de l'acteur présente de nombreux avantages sur le plan technique. Tout d'abord, il nous permet de conserver les données dans de petites unités découplées les unes des autres, ce qui permet une architecture basée sur les microservices qui s'adapte aux besoins des objets du domaine. Cela contraste avec un service monolithique traditionnel qui s'adapte à tout, répliquant les processeurs, l'infrastructure et les données même lorsque cela n'est pas nécessaire, simplement parce que les nombreux domaines sont couplés dans un seul déploiement de service. En découplant les entités les unes des autres, le modèle Actor offre également une certaine résilience en permettant à une partie du système de tomber en panne sans entraîner les autres parties avec elle. Cela signifie également que les développeurs peuvent déployer des correctifs pour un seul service sans s'inquiéter que d'autres services soient pris entre deux feux et rendus indisponibles pendant la mise à jour. De plus, en utilisant la mémoire vive pour conserver les données appartenant à ces entités Actor, nous pouvons traiter et envoyer des données aux services d'analyse en temps réel sans bloquer les bases de données qui doivent se synchroniser les unes avec les autres lorsque de nouvelles données sont introduites.
Cela vous a peut-être semblé être un long déballage. Mais vous pouvez maintenant constater qu'avec ces avantages de cohérence du domaine, d'élasticité, de résilience, de réactivité et de récupération des données en temps réel, les systèmes réactifs pilotés par les messages nous permettent de faire un bond en avant par rapport à l'architecture conventionnelle en ce qui concerne certaines mesures de la qualité et de l'efficacité. En outre, ce modèle peut être appliqué à n'importe quel langage ou cadre, ce qui permet au développeur du futur d'être une infrastructure, non entravée par des préjugés pour les langages ou les cadres, et uniquement préoccupée par la satisfaction des attentes en matière de temps, de qualité, d'évolutivité, de résilience, de réactivité et d'autres spécifications.
