Le cloud est en pleine croissance chez les développeurs, de plus en plus nombreux à utiliser des applications cloud natives, des conteneurs, des orchestrateurs, etc. Le serverless n’a par contre plus le vent en poupe ; son usage est en baisse.
La CNCF vient de publier un rapport baptisé « the state of cloud native development ». En préambule, le document rappelle que « la façon dont les logiciels sont développés a radicalement changé depuis que les conteneurs sont apparus ».
Wikipédia explique que la Cloud Native Computing Foundation (CNCF) « est un projet de la Linux Foundation qui a été fondé en 2015 pour aider à faire progresser la technologie des conteneurs et rassembler les industries technologiques autour de son évolution ». Sur son site, elle se présente comme un « foyer indépendant pour de nombreux projets open source à croissance rapide, notamment Kubernetes, Prometheus et Envoy ».
Nous en parlions récemment : « Une application est de plus en plus un ensemble de micro-services, d'API (REST, GraphQL), conteneurisés via Docker, orchestrés à travers Kubernetes et adaptés à la demande des utilisateurs en temps réel ».
Le but de ce rapport est donc de suivre l’adoption de ces nouvelles fonctionnalités chez les développeurs. Pour mener à bien son analyse, la fondation s’appuie sur une étude de SlashData pour dresser son bilan.
Applications cloud natives : qui sont-elles, quels sont leurs dévs ?
Commençons par une définition : « Les technologies "cloud natives" permettent aux organisations de créer et d'exécuter des applications évolutives dans des environnements modernes et dynamiques tels que les clouds publics, privés et hybrides. Les conteneurs, les services maillés, les microservices, l'infrastructure immuable et les API déclaratives illustrent cette approche ».
Le rapport commence par quelques chiffres globaux : « Nous estimons le nombre mondial de développeurs cloud natifs pour le premier trimestre 2021 à 6,8 millions, soit 41 % des développeurs backend [qui sont 16,6 millions, ndlr]. Ils sont 4,6 millions à utiliser des outils d'orchestration de conteneurs et 4 millions à utiliser des plateformes serverless ».
Alors que le nombre de développeurs cloud natifs « a augmenté de 0,3 million au cours des 12 derniers mois, la proportion de développeurs backend impliqués dans les technologies cloud natives a en fait légèrement diminué de 3 points, en raison d'une baisse de l'adoption des technologies serverless ».
Le rapport met aussi en avant une forte hausse du nombre développeurs utilisant les conteneurs (notamment pour des applications cloud natives). Ils sont désormais 10,2 millions, soit près de 61 % de l’ensemble des développeurs ayant participé à cette étude.
Au niveau régional, l’Europe de l’Ouest arrive en tête avec 73 % des développeurs qui sont passés sur des conteneurs. Seuls le Moyen-Orient et l’Afrique sont à moins de 50 %.
Focus sur Kubernetes
La CNCF se penche ensuite sur l’utilisation des conteneurs et de Kubernetes, une solution open source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Elle a été initialement développée par Google et ensuite transférée à la Linux Fondation.
Sur 7 000 développeurs interrogés, le pourcentage de ceux ayant eu recours aux conteneurs au cours des 12 derniers mois est relativement stable à 57/58 %. Par contre, on passe de 27 à 31 % pour une utilisation de Kubernetes. Une bonne nouvelle pour la fondation, qui ajoute tout de même qu’il « a sans doute encore de la place pour gagner des parts de marché ».
Respectivement 21 et 14 % des développeurs interrogés ont entendu parler des conteneurs et de Kubernetes, mais sans être certains de savoir à quoi cela correspond précisément. Enfin, 11 et 6 % n’ont jamais entendu parler de ces deux technologies. C’est légèrement en baisse pour les conteneurs, mais stable pour Kubernetes. Sauf surprise, la tendance à la baisse devrait être la norme pour les prochaines années.
Le fog computing (l'informatique en brouillard ou géodistribuée) et l‘edge computing (deux technologies proches) sont les principaux secteurs où les conteneurs et Kubernetes sont utilisés, avec respectivement 76 et 63 %.
Pour la CNCF, cet écart de 13 points reste raisonnable, même s’il existe là encore une bonne marge de progression. Il y a d’ailleurs largement pire : dans les mini-apps, l’écart est de 27 points. A contrario, il n’est que de 5/6 points dans les technologies de retour haptique et d’informatique quantique qui utilisent donc de manière importante Kubernetes.
Les conteneurs sont très utilisés dans les deux cas, mais avec ce qui semble être un plafond de verre autour de 80 à 85 %. Concernant Kubernetes, la situation est différente : les grosses entreprises y ont largement plus recours que les petites, quels que soient les usages.
Fog et edge computing à la loupe
Dans la troisième partie, le rapport se concentre sur les deux secteurs les plus porteurs pour les conteneurs et Kubernetes : le fog et l’edge computing. Dans ces domaines, 76 % des développeurs utilisent les conteneurs (stable sur un an), contre 63 % Kubernetes (+10 points sur un an).
Comme indiqué précédemment, le rapport pointe du doigt une baisse dans l’utilisation du serverless dans le cas de l’edge computing : alors qu’elle grimpait doucement de 53 à 56 % entre 2019 et 2020, elle est passée à 48 % au premier trimestre 2021, soit une baisse de 8 points en six mois seulement.
Si on prend en compte l’ensemble des développeurs, l’utilisation du serverless est aussi en baisse à 33 %, soit 3 points de moins en trois mois. Par contre, il grimpe de 3 point sur deux ans (il était à 30 % début 2019).
Quels « clouds » avec Kubernetes ?
La CNCF a ensuite demandé aux développeurs utilisant Kubernetes dans quel environnement s’exécutait leur code. Dans le cas du edge computing, ils préfèrent majoritairement les clouds privés, publics et sur site (on-premise), avec un taux d’adoption de 59 à 64 %.
Le multi-cloud (plusieurs clouds publics pour un même projet) et le cloud hybride (mélangeant cloud privé et public) ne sont qu’à 44 et 42 % respectivement. La tendance générale est par contre totalement inversée si on prend en compte l’ensemble des développeurs : le multi-cloud et le cloud hybride arrivent en tête (49 et 46 %), mais avec des écarts moins prononcés par rapport aux clouds publics (40 %), privés (42 %) et à la demande (35 %).
Amazon Web Services domine Microsoft et Google
Passons maintenant aux fournisseurs de cloud. Amazon arrive largement en tête chez les développeurs utilisant Kubernetes. Microsoft Azure et Google Cloud Platform se partagent les 2e et 3e places. Ils sont à quasi-égalité, mais à bonne distance d’Amazon qui domine les débats. On remarque aussi la bonne position des solutions auto-hébergées qui se placent en 4e position avec 42 % des développeurs Edge qui y ont recours et 33 % de l’ensemble des développeurs.
Avec 67 % de taux d’adoption, l'orchestration via Google Kubernetes Engine arrive en tête chez les développeurs edge. Amazon Elastic Kubernetes Service est second avec 57 % et les solutions maison troisième avec 51 %. Amazon Elastic Container Servicel, IBM Cloud Kubernetes Service, Red Hat OpenShift, Microsoft Azure Kubernetes Service et Service Fabric sont juste derrière avec 44 à 50 % d’utilisation.
Les solutions d’orchestration maison sont par contre en pole position si l’on prend l’ensemble des développeurs, suivi de très près par Amazon Elastic Container Service et Google Kubernetes Engine.
Serverless : il y a Amazon, Google, Microsoft et… le reste
Enfin, lorsque les développeurs ont recours à du serveless, AWS Lambda arrive en tête puisque 54 % indiquent l’utiliser. Google Cloud Functions est second à 41 %, Azure Functions troisième à 35 %… et on retrouve de nouveau Google en 4e position avec Google Cloud Run. Les différences entre Cloud Run et Cloud Functions – tous deux de type serverless – sont détaillées ici.
Bref, toujours les trois mêmes qui se partagent la plus grosse part du gâteau… ce qui ne devrait pas surprendre grand monde. Le premier concurrent est Cloudflare avec son offre Workers qui est à seulement 16 %, suivi par Netlify Functions à 15 %, etc.
Ubuntu aussi y va de sa petite analyse
Au même moment, Ubuntu propose une infographie sur l’usage des applications cloud natives et Kubernetes. Le périmètre de mesure n’étant pas le même, les chiffres ne sont pas forcément comparables, mais ils permettent d’avoir une autre approche.
Selon Ubuntu, 45,6 % des applications cloud natives utilisent Kubernetes en production, 15,7 % de manière exclusive. AWS arrive largement en tête comme plateforme de support pour Kubernetes puisque 50 % des développeurs l’utilisent. Microsoft Azure est à 34 %, Google Cloud à 25 %, VMWare à 25 % également, etc.
21,4 % des développeurs interrogés gèrent plus de 500 machines. En moyenne, ils utilisent 2,5 clusters Kubernetes et 4 % ont même plus de 21 clusters. Dans 65 % des cas, la principale motivation est d’améliorer la maintenance, la surveillance et l'automatisation, dans 46 % des cas de moderniser l’infrastructure.
Commentaires (6)
#1
En parlant c’est container, est ce que vous confirmez que c’est devenu la norme pr le poste du développeur ? Fini la VM, fini xxamp wamp local, un container jetable avec le code dans git et on en parle plus ?
félicitations pour le travail
Je vois encore un peu de local chez les presta mais ça se raréfie.
PS: nouvel abonné et content de rattrapper plein d’articles pas lus
#2
Je vois pas ça comme étant la norme sur le poste de dev. Tu parles de stacks php que je connais pas trop, alors je ne sais pas ce qu’il en est dans ces environnements, mais pour fréquenter plus des devs go / jvm / js certes les containers sont très utilisés mais pas forcément sur les postes de dev en local. Ça ajoute une interface entre toi et ton programme, donc en général, quand on recherche la simplicité/debuggabilité/réduire la surface de recherche en cas de problème… Ce n’est pas forcément l’idéal
#3
Ya un petit coté “mode” , aussi….
Je connais plein de gens qui ont perdu des données faute de comprendre que les containers étaient volatils. Et à mon sens ça permet de “simplifier” un peu le déploiement car du coup tout le monde bosse avec les mêmes distro et environnement du container, mais quand il y a des problèmes, ça devient tout de suite une affaire de spécialiste. Et vla le temps & la place que ça prends , surtout quand tu ne prune pas régulièrement… (à croire que ça a été inventé par les fabriquants de SSDet de CPU).
Et puis alors dès que ça commence à toucher au réseau … :-/
Perso j’utilise pas docker , je préfère podman et son option –userns=keep-id pour le dev (qui à l’avantage d’être présent dans redhat/debian de base, mais quand je peux j’évite quand même.
Là où l’utilité est indéniable c’est pour l’intégration continue.
#4
Le gros intérêt du container est d’assurer la reproductibilité du runtime de bout en bout puisque l’image de celui-ci repartira toujours de son état initial. Donc ça permet d’assurer un déploiement identique de bout en bout.
Pour ma part, je suis entre le dev et la production, et avoir contraint l’utilisation des containers pour les environnements d’exécution a été nécessaire pour arrêter d’avoir des boucles infinies de “ça marche sur mon poste” là où le code en preprod ou prod ne marche pas car le dev n’a pas indiqué les dépendances requises (vu que tout était déjà dans l’environnement de son IDE). Parce que historiquement, entre un dev qui teste sur sa VM Debian et livre un produit qui sera hébergé sur une RHEL, c’est toujours un risque d’emmerdes.
C’est pour ça que depuis, on dit “ça marche dans mon container”.
A titre perso, j’utilise énormément podman pour me mettre dans une situation au plus proche des environnements d’exécution afin de valider un outil ou un déploiement. Ca évite en grande partie les biais induits par l’OS de mon poste (qui est sous Fedora).
Mais attention, ce n’est pas magique. Il m’est déjà arrivé de me faire niquer car certains vont partir du Dockerfile pour build le container, mais oublier de re-pull l’image de base (parce que c’est pas forcément systématique). Ce qui peut induire les mêmes genres de régression pour peu que l’image de base ait induit des changements cassants. Dans notre cas, les devs utilisent l’image proposée dans notre registry et n’ont pas à devoir la build.
#5
Bonjour,
S’agissant de containers, on parle beaucoup de docker, podman…
Peu de LXC: c’est utilisé en prod ? (il est «estampillé» Ubuntu, certes, mais ça semble tourner partout).
Merci.
#6
Merci à tous !
Lxc jamais utilisé sorry