Docker / Kubernetes - Revue technologique 2020 (stackoverflow survey)

[Sheepux]

Ce sujet porte sur l'analyse de https://insights.stackoverflow.com/survey/2020 qui est le sondage annuel de stackoverflow pour identifier les tendances et attentes de la communauté (65.000 réponse).

Note: Aucune relecture, de nombreuses réécritures partielles de phrases. Certains passages peuvent donc être un carnage.

Les pourcentages sont à considérer avec une réponse à choix multiple (la somme ne fait donc pas 100%).
Pourquoi une analyse spécifique à docker/kubernetes et pas le reste ? Tout simplement parce que ces 2 domaines apparaissent dans le top 3 et que c'est mon domaine et donc je peut essayer de contextualiser les chiffres.

1.  Popularité des plateformes de déploiement

1.1 (plateforme appréciée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-loved5

Citer

% of developers who are developing with the language or technology and have expressed interest in continuing to develop with it

1 - Linux	76.9%
2 - Docker	73.6%
3 - Kubernetes	71.1%
4 - AWS	66.4%

Nous retrouvons Linux en top 1 car son succès global (Android, serveur) n'est plus à prouver. Nous pouvons cependant souligner le lien très étroit entre les images docker et les socles Linux.
Jusqu'à il y a encore peut de temps les conteneurs Windows étaient à l'étude. et les déploiements .net passaient par des conteneurs .net core 
Tout les conteneurs reposaient donc sur des socles Linux avec comme toujours la bataille des différentes distributions (Ubuntu puis Alpine et autres). Ubuntu était devenu (et est toujours) le standard mais désormais ce sont les distribution Alpine qui tendant à passer devant par leur rapidité de démarrage et la taille des images (ainsi que la réduction des surfaces d'attaque en réduisant le nombre d'outils inclus de base).
A noter cependant qu'avec Alpine de nombreux soucis ont été rencontrés pour le portage de nombreuses libs (exemple OpenJDK) car la bibliothèque glibc qui sert à de nombreux process a été remplacée par musl libc qui a des comportements différents selon les situations. Lors du passage à la conteneurisation des connaissances/compétences avancées en socle Linux sont devenus parfois nécessaires.

Docker et Kubernetes suivent en tant que technologies les plus appréciées. Succès s'explique par plusieurs points:

• La maturité des fondamentaux système (LXC, namespace) et outils ( compose, helm, registry entre autres)
• Les nombreux retours d'expériences (articles)
• Les nombreuses communautés  (une technologie quelle que soit sa bonne conception ne percera qu'avec des communautés actives).
  Même docker(l'entreprise) a perdu sa propre bataille d'hyperviseur de conteneurs : "Swarm VS kubernetes" (alors que Swarm apportaient de trés bonnes réponse à certaines problématiques).
• L'adoption et contributions par de nombreux acteurs majeurs (Google, Amazon, Microsoft, IBM etc... ) et la portabilité entre ces différents hébergeurs cloud.
  Exemple d'ouverture publique des problématiques de la solution AKS d'Azure https://github.com/Azure/AKS 
• La liberté système que permet l'approche (permettant à docker de répondre à de nombreux cas d'usage).
• et surtout le fait que les conteneurs (tels que vu par docker) a été libéré par docker (à l'origine 

Kubernetes a percé car a su répondre aux problématique d'industrialisation du déploiement et d'exploitation (avec notamment de nombreuses métriques) en production dans un écosystème multi-service et multi-host en capitalisant et introduisant (pour docker) des concepts simples permettant non seulement d'organiser les relations au sein d'une application mais également de s'intéresser aux éléments extérieurs (ingress gérant le provisionnement automatique d'équilibreurs de charge externes et des DNS) et surtout de laisser le choix de l'implémentation à différentes solution évitant de forcer l'utilisation d'une technologie en particulier. Exemple: liberté de choix  du reverse-proxy (nginx, traefik), du composant de CNI (la couche réseau: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) et aussi du runtime engine ( docker ou CRI-O  ou containerd) https://kubernetes.io/docs/setup/production-environment/container-runtimes/).
Kubernetes a su répondre également aux enjeux de l'auto-hébergement en démontrant qu'il pouvait s'installer sur les serveurs locaux d'entreprise ("on-premise")
A noter cependant que Kubernetes ne représente qu'une petite partie des sujets docker (https://trends.google.fr/trends/explore?date=all&geo=FR&q=docker,kubernetes ). La problématique kubernetes reste limitée à des projets d'une certaine taille et ayant les moyens pour y consacrer du temps (retour d'expérience: 40 clusters (gérants 150 VM) vs 5000 VM docker). C'est cependant un élément vital pour les applications nécessitant de la haute disponibilité.

Nous pourrons également souligner l'organisation très ouverte mais bien structurée des contributeurs en SIG : Special Interest Group https://github.com/kubernetes/community/blob/master/governance.md  permetant aux différents contributeur de retrouver des communautés dédiées à chaque problématique (voir la liste: https://github.com/kubernetes/community/blob/master/sig-list.md ).

Pourquoi retenir AWS dans l'extrait du top ? Tout simplement qu'à l'heure actuelle l'écosystème AWS pour kubernetes est (avis personnel d'utilisateur multi-cloud) le plus avancé (en terme d'offre de services) et le plus mature (stabilité et autres).

1.2 (plateforme désirée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-wanted5

Citer

% of developers who are not developing with the language or technology but have expressed interest in developing with it

1 - Docker	24.5%
2 - AWS	20.2%
3 - Kubernetes	18.5%
4 - Linux	16.6%

La conteneurisation avec Docker et Kubernetes retient l'attention car c'est en effet la technologie en vogue pour de nombreuses entreprises et projets (retour d'expérience personnel : il nous arrive même de conseiller un projet à ne pas basculer sur la conteneurisation car non adapté au projet principalement "trop couteux pour cause de coût de transition (formations/niveau de maturité des équipes)").

Les offres d'emplois continuent pour l'instant d'évoluer en ce sens https://www.beseen.com/blog/talent/kubernetes-career-trends/  ou https://www.itjobswatch.co.uk/jobs/uk/kubernetes.do que ce soit au niveau projet ou chez les cloudeurs (à noter OVH, Scaleway pour parler des français).
Cependant de nos jours les virages technologiques sont parfois assez violent (retour d'expérience personnel: kubernetes enterrant openstack https://trends.google.fr/trends/explore?date=all&geo=FR&q=kubernetes,openstack ).

Nous pourrons noter une très forte affinité de kubernetes avec les déploiement en agile/devops; la technologie impliquant un travail étroit entre les équipes de développement et celles en charge du déploiement/exploitation. (A titre personnel je n'ai rencontré que de très rares projet kubernetes qui ne soit pas sur ce modèle).

1.3 (plateforme détestée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-dreaded5

Citer

% of developers who are developing with the language or technology but have not expressed interest in continuing to do so

Nous ne commenterons pas la présence de WordPress au top1 😛

 

14 - AWS	33.6%
15 - Kubernetes	28.9%
16 - Docker	26.4%

Pour autant, bien que les précédents points glorifient ces technologies il n'y a pas de lumière sans ombre.
Kubernetes sont en bas de ce classement (donc c'est positif) cependant les pourcentages sont quand même notable.
Sans plus de détails sur les causes de ces votes je vais extrapoler à partir de mon expérience.

Principale cause, à mon sens, les développeurs doivent désormais s'occuper de l'aspect packaging et parfois avec des problématiques système ce qu'un développeur n'apprécie pas toujours (souhaitant se concentrer sur les problématique fonctionnelles/code).
L'organisations en service/microservice impose de penser les applications d'une nouvelle manière ce qui n'est pas toujours simple. Il est même parfois plus simple de faire "à l'ancienne", c'est parfois la raison d'un échec projet : avoir voulu utiliser les technologies tendances alors qu'elles n'avaient pas forcément de plus value et on entrainer un "enfer de nouveauté" (transition technologique, problème de maturité etc...).
Notons également le changement des habitudes des développeurs sur l'écosystème avec par exemple la disparition des fichiers de logs en tant que tels et l'utilisation de commandes/outils pour consulter les journaux. Cela a été dans mon cas de nombreuses sources de conflit ("Les logs sont sur la sortie standard! Pas dans des fichiers!") .

Egalement, lorsqu'il y a des "bugs" lié à la plateforme ceux ci sont parfois très complexe dépassant complètement les développeurs et peuvent parfois prendre un certain temps à être identifiés et corrigés (par Kubernetes ou par le cloudeur qui réalise une implémentation spécifique à son socle). Les cloudeurs tardent parfois à proposer les dernières versions kubernetes entrainant un gap pour avoir un correctif de certains problèmes.

En point final, de très fortes différences entre le niveau d'expérience d' équipes sachant déjà faire du docker et les débutantes. Si nous pouvons déjà le voir entre 2 équipes "Java" (simple exemple) on rajoute à nouveau une surcouche de compétence en docker/Kubernetes pouvant encore creuser la différence. Nous pouvons aussi le voir sur la qualité des différentes images présentes sur le hub docker: il faut souvent savoir faire le trie.

N'hésitez pas à commenter vos problématiques.

2. Technologies liées

https://insights.stackoverflow.com/survey/2020#correlated-technologies

Intéressons nous maintenant aux technologies liées avec un focus sur celles autour de la conteneurisation.

Comme indiqué précédemment, Docker est très lié à Linux (et donc en complément à la pratique de bash pour étudier les problématiques système).

Nous pouvons remarquer que les technologies qui gravitent autour de la conteneurisation sont surtout des bases PostgreSQL et des outils tels que Elasticsearch (c'est l'outil préféré pour le stockage des logs).

Le succès de postgreSQL s'explique principalement par l'attrait des développeurs (et pour les mêmes raisons qu'évoqué au point 1 de kubernetes). Par contre son lien avec docker & kubernetes s'explique par sa très bonne conteneurisation (permetant un travail en local), sa flexibilité et sa capacité de mise à l'échelle avec notamment des implémentations cloudeur qui permettent une offre haute disponibilité (exemple: AWS RDS).
Si redis est lié à Docker, nous pouvons voir qu'il est aussi lié à Kubernetes. Il s'agit tout simplement de la technologie retenue lors de besoin du passage en services qui permet de synchroniser simplement des états entre les conteneurs d'un même périmètre.
Nous retrouvons AWS comme cloudeur principal des offres de conteneurisation mais je trouve étrange qu'Azure ne soit pas plus présent.
Go est lié à kubernetes car les modules sont écrit en Go 🙂
Terraform et Ansible sont des outils classiques des approches Devops et s'intègrent très bien (bien que le besoin de terraform pour kubernetes soit, à mon sens, assez réduit étant donné sa capacité à décommissioner dynamiquement les ressources provisionnées) . Plus proche de kubernetes je rajouterai HELM et pour docker Compose.

J'inclurai également Prometheus comme outil de consolidation des métriques qui est le couple recommandé (avec Graphana) bien que des outils propriétaires tels que datadog ont une progression notable ces 2 dernières années par leur intégration globale unifiée (un outil pour les gouverner tous).

En terme de langages, j'ai surtout vu au niveau projets du nodeJS et du Java, mais cela ne semble pas se refléter sur ce sondage.

3. Le mot de la fin

En espérant que la lecture vous a intéressé 🙂 Cet article est amené à évoluer selon vos retours !

Peut être le proposer en article/news Nxi ? (nécessite probablement une réécriture/adaptation)

[jotak]

Un autre rapport dans la même veine mais centré sur kubernetes : https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf (CNCF SURVEY2020)

[Sheepux]

Yep, je voulais prendre le temps de faire un résumé. Probablement pendant les vacances de noyel

[jotak]

À mon avis il est pas mal biaisé. Quand je vois que 27% des répondants affirment utiliser un service mesh en production, je me dis qu'il y a beaucoup de "early adopters" parmi les répondants.

[Sheepux]

J'ai vu énormément de projets demander du Istio pour l'observabilité des échanges micro service et pour les thématiques théoriques Blue/Green (genre ca fait tendance). Aprés en effet 27% utilisé en prod, ca me semble plus qu'étrange car ce n'est un use case que pour les gros projets.