Les nouvelles tendances IT à ne pas manquer
vendredi 16, avril 2021
Le digital envahit nos vies à coup sûr, et les applications qui permettent de répondre à nos besoins sont de plus en plus complexes. D’ailleurs, les impératifs, parfois contradictoires, d’agilité et de stabilité ont poussé les entreprises du digital à adopter de nouveaux outils plus adaptés à ces exigences.
"Les entreprises sont en train de payer très cher l’infrastructure dont elles ont besoin et essaient tout le temps de réduire les coûts”, déclare Tetiana Fydorenchyk, VP of Marketing à Jelastic. Intervenant lors d’un webinaire organisé par Safozi, société spécialisée en hébergement cloud, l’interlocutrice a indiqué que les entreprises essaient de perfectionner leurs réglages de manière à réduire les coûts sans pour autant impacter les performances de leurs applications. C’est dans ce sens que de plus en plus d'entreprises sont en train de migrer de l’hébergement classique vers l’hébergement cloud, indique Fydorenchyk. Et d’ajouter: “Nous sommes également en train de voir une croissance rapide de la conteneurisation vu tous les avantages qu’offre cette technologie”.
La révolution des conteneurs
La conteneurisation a permis de se rapprocher d’un pas de l’objectif ultime de toute entreprise: build once, deploy everywhere, ou construire une fois, déployer partout. Propulsée par Docker, une entreprise qui a mis sur le marché en 2013 une technologie éponyme, la conteneurisation permet de résoudre, du moins partiellement, les problématiques liées au déploiement des applications dans les environnements de production. Car un logiciel est rarement un morceau totalement isolé. Souvent, il vient avec son interpréteur, ses bibliothèques, nécessite un moteur de base de données, des fichiers de configuration, un serveur web et tout un tas d’autres composantes. Cet écosystème va être difficile à gérer tout au long de la chaîne de construction, aussi bien pour le développement, en phase de validation/qualification ou encore en production. Avant Docker, chaque étape nécessitait de remonter l’ensemble de l’environnement, d’y installer le logiciel (parfois à partir des sources via compilation), de le lancer…
Et le fait d’avoir l’application tourner en environnement de test ne garantit en rien que la même chose se reproduise en production, puisque la moindre déviation entre deux environnements pouvait conduire à des bugs non reproductibles en fonction de l’endroit où l’on lançait le logiciel. Avec Docker, ceci n’est qu’un lointain mauvais souvenir. Les développeurs construisent une image du logiciel qui va contenir tout ce qui lui faut pour fonctionner, depuis l’OS jusqu’au logiciel lui-même en passant par toutes les autres briques. S’ils sont satisfaits du résultat, ils livreront à l’étape suivante cette même image et pourra être lancée à l’identique, et ainsi de suite jusqu’à la très attendue mise en production. Les containers ont été victimes de leur succès. Très rapidement, les applications se sont transformées en des dizaines, voire des centaines, de composants indépendants. Et le besoin d’orchestrer tout ce chaos a donc vu le jour. Docker, naturellement, a développé sa propre solution, Swarm. Mais c’est l’offre de Google, Kubernetes, qui a, de loin, eu le plus grand succès.
Kubernetes, les pilotes de demain
Kubernetes a bel et bien gagné la guerre pour la domination de l'orchestration de conteneurs. Kubernetes (dit aussi K8s par les intimes) attire pourtant de plus en plus l'attention. Conçu à l'origine par Google en 2014, et désormais géré par la Cloud Native Computing Foundation, il s'agit d'un système open source permettant d'automatiser le déploiement, la montée en charge et la gestion des applications conteneurisées. Kubernetes (prononcé “koubeurnétyz”) est particulièrement populaire auprès des organisations qui utilisent les approches DevOps. Un sondage réalisé auprès d'entreprises utilisant des conteneurs révèle que 71% d'entre elles utilisent Kubernetes. Ce dernier est devenu un standard de fait, parce que la technologie est stable, et que les utilisateurs comme les fournisseurs le choisissent pour réaliser des investissements technologiques et architecturaux. De fait, Kubernetes est devenu un outil dans lequel les organisations ont confiance pour déployer des conteneurs en production.
Pour un administrateur spécialisé dans les instances virtuelles, les conteneurs sont clairement le domaine dans lequel la plupart des innovations vont arriver. Surtout l'adoption progressive du DevOps par les entreprises a comme conséquence de voir les workloads migrer progressivement des machines virtuelles vers les conteneurs. Donc le passage du test et du développement à la mise en production des conteneurs est une dynamique en place qui ne devrait que s'accentuer. Les développeurs ont été parmi les premiers à adopter la conteneurisation, car cela leur a permis de résoudre un gros problème : transférer des applications des environnements de développement vers des environnements de production. Les développeurs peuvent ensuite réaliser des tests applicatifs à la production tout en s'assurant que l'application se comportera exactement comme sur les machines de test. Les architectes informatiques en entreprise ont comme mission constante d'équilibrer le besoin de maintenir leurs applications legacy et la nécessité de développer des solutions capables de supporter l'innovation future.
Par le passé, les outils nécessaires pour chacun de ces besoins étaient très différents. De ce point de vue, Kubernetes est une technologie très intéressante car les clients peuvent l'utiliser en production pour non seulement créer de nouvelles applications de microservices cloud native, mais aussi migrer des applications existantes dans des conteneurs et les exécuter dans Kubernetes.
Les développeurs, un métier sans avenir ?
De prime abord, s'interroger sur l'avenir du métier de développeur après avoir passé plus de 700 mots à parler des devops semble plutôt mal placé. Détrompez-vous: avec l’apparition et le développement rapide des plateformes dites de low-code et de no-code justifient parfaitement cette question. Au fait, cela fait maintenant plus de 30 ans que les utilisateurs demandent de développer des fonctionnalités que les équipes techniques livrent souvent avec retard. La tentation de développer soi-même son service, son application s’est parfois imposée à certains départements de l’entreprise.
L’idée derrière ce développement est toujours la même : répondre aux besoins le plus rapidement possible. Ces besoins sont parfois très simples mais répondent à une réalité du terrain. Le problème est qu’en dehors du département IT, les compétences en programmation des collaborateurs sont, pour le mieux, très limitées. C’est ainsi que les solutions de low code ont vu le jour. Se présentant sous forme de plateforme, ces solutions permettent d’assembler, paramétrer et déployer une solution en quelques heures … sans avoir à programmer. Un peu de code est toujours indispensable pour créer la “glue” technique entre les composants ou pour personnaliser un module. Mieux encore, plusieurs plateformes arrivent aujourd’hui à offrir des solutions dites de no code. Il s’agit d’outils de création de services et/ou d'applications qui ne nécessitent aucune programmation.
Les entreprises croient dans le low code comme le prouve le marché, très dynamique, avec une quinzaine d’acteurs principaux dont Salesforce, OutSystems, K2, Mendix, ServiceNow, Appian, AgilePoint. Selon les études de Research And Markets, le marché pesait plus de 5 milliards de dollars en 2017 et dépassera les 27 milliards USD en 2022. Les solutions low code et no code visent essentiellement les entreprises, particulièrement les grandes organisations, pour répondre aux besoins croissants de l’automatisation logicielle et la nécessité de déployer de nouvelles applications, tout en réduisant les coûts et le temps de développement.
Le serverless: le next big thing?
L’architecture serverless est un modèle dans lequel le fournisseur de services cloud est responsable de l’exécution d’un morceau de code en allouant de manière dynamique les ressources. Et il ne facture que la quantité de ressources utilisées pour exécuter le code. Le code est généralement exécuté dans des conteneurs sans état pouvant être déclenchés par divers événements, notamment des requêtes http, des événements de base de données, des services de file d’attente, des alertes de surveillance, des téléchargements de fichiers, des événements planifiés (tâches cron), etc. Le code envoyé au fournisseur de cloud pour l’exécution est généralement sous la forme d’une fonction. Par conséquent, serverless est parfois appelé “Functions as a Service” ou “FaaS”.
Alors que le serverless isole l’infrastructure sous-jacente du développeur, les serveurs sont toujours impliqués dans l’exécution de ces fonctions. Étant donné que le code va être exécuté en tant que fonctions individuelles, les développeurs doivent être conscients de certains facteurs qui peuvent impacter les performances de leur application. Le plus grand changement auquel sont confrontées les entreprises lors de la transition vers un monde serverless est que l’application doit être structurée en “fonctions”. Ceci implique donc que l’application doit avoir une architecture en microservices où chaque fonction est isolée dans un service indépendant. Les fonctions sont généralement exécutées dans des conteneurs sécurisés (presque) sans état (stateless). Cela signifie qu’on ne peut pas exécuter de code sur les serveurs d’applications, qui s'exécutent longtemps après la fin d’un événement ou qui utilisent le précédent contexte d’exécution pour répondre à une requête.
En d’autres termes, le développeur doit supposer que la fonction est à nouveau invoquée à chaque requête. Et comme les fonctions sont exécutées dans un conteneur qui est créé à la demande pour répondre à un événement, une certaine latence lui est associée. Pour éliminer toute latence, certains fournisseurs préfèrent “conserver” un conteneur quelque temps après l’exécution d’une fonction. Si un autre événement est déclenché pendant ce temps, il répond beaucoup plus rapidement. La durée des démarrages à froid dépend de la mise en œuvre du fournisseur de cloud spécifique. Cela peut aussi dépendre de l’exécution (ou de la langue) utilisée, de la taille de la fonction (en tant que package) et bien sûr du fournisseur de cloud en question.
Les démarrages à froid se sont considérablement améliorés au fil des années, les fournisseurs de cloud optimisant nettement mieux leur temps de latence. Avec les technologies mises à leurs dispositions, les entreprises ont de moins en moins de prétextes pour ne pas adopter un cycle de développement plus agile qui prend en considération les attentes des clients et des usagers. Qui plus est, ces outils offrent un niveau de sécurité supplémentaire qui permet d’éviter les bugs et les dysfonctionnements qui, jusqu’à un présent très proche, représentaient une menace à la stabilité des solutions.
