📻 RDO #9 - Jusqu’où conteneuriser?

[aselkim]

@jderrien

Je parle de l’image qui restera la même à travers les années.

DevOps et déploiement continue ou pas, tu auras toujours des projets qui seront abandonnés d’un point de vue développement mais qui devront continuer à fonctionner en prod.

C’est exactement le même souci avec une VM ou un serveur baremetal. Tu ne pourras plus mettre à jour l’OS et donc tu vas le laisser en l’état. Un exemple très simple, les entreprises qui ont toujours de vieux OS pour faire tourner des appli compatibles PHP4.

Encore une fois, Docker n’est pas une réponse à ce genre de boites.

@jderrien

Si la prod repose sur des containers Docker, ce n’est justement pas le cadet de ses soucis.

C’est le cadet de leur soucis dans le sens où visiblement les boites qui en arrivent là ont un vrai problème organisationnel et de vision. Et clairement, Docker n’a pas vocation à répondre aux besoins de ces boites là. Pour ces boites il faut une réponse autre que technologique.

@jderrien

Il y en a tellement que je n’ai pas de liste finie. Les problèmes de performance, de sécurité, le monitoring devient plus complexe, l’orchestration qui impose pratiquement d’avoir un cluster k8s, les images non maintenues et/ou pas mal conçues, etc. Chacun de ces points pourrait être développé, mais je n’arriverai pas à être exhaustif.

En terme de performance le surcout reste tout à fait acceptable et négligeable, je parle ici des containers et de docker, la surconsommation lié à l’orchestrateur n’est pas imputable à la conteneurisation.

La sécurité c’est le même problème qu’avec du baremetal ou des VMs, il faut pouvoir détecter les mises à jour nécessaires et les appliquer, encore une fois, les images sont sensées avoir un cycle de vie court et donc être reconstruites souvent, on ne compte plus le nombre d’outils pour cela.

Le monitoring n’est plus complexe de nos jours, il y a de nombreux outils et services SaaS pour cela. Par contre, monitorer correctement une infra peut être compliqué (docker ou pas).

Les images non maintenues et mal conçus, cela relève de la mauvaise utilisation de la technologie, de la mauvaise organisation.

Lorsqu’on intègre une technologie à son infrastructure il faut la comprendre et la maitriser… et surtout il faut en avoir le besoin.

Docker n’est pas une solution universelle magique qui règle tout les problèmes.

Je pense que le plus gros problèmes des boites est le manque de maitrise et d’organisation, je le vois bien avec nos clients, et je ne parle pas spécialement de Docker mais en général.

[jderrien]

@aselkim

C’est exactement le même souci avec une VM ou un serveur baremetal. Tu ne pourras plus mettre à jour l’OS et donc tu vas le laisser en l’état. Un exemple très simple, les entreprises qui ont toujours de vieux OS pour faire tourner des appli compatibles PHP4.

Non, ce n’est pas le même soucis. C’est ce que j’expliquais dans une précédente réponse. Dans une VM, le kernel et la libc resteront compatibles vu qu’ils ne seront pas mis à jour.

Cela pose bien sûr un problème de sécurité à terme. Mais ça reste cohérent et stable dans le temps.

D’où l’idée que les images de container qui sont buildées une fois et déployées “partout” n’est pas idéal. Si la version du kernel et/ou de la libc changent, il sera toujours plus prudent de recompiler. Ne pas le faire marche dans un certain nombre de cas. Mais c’est jouer à l’apprenti sorcier, et au final on est en train de recréer le monstre de Frankenstein, pour donner une image.

Et donc, ce côté “au petit bonheur la chance” reste quand même une hérésie lorsque l’on parle d’environnement de production.

@aselkim

C’est le cadet de leur soucis dans le sens où visiblement les boites qui en arrivent là ont un vrai problème organisationnel et de vision.

Tout n’est jamais (ou rarement) tout blanc ou tout noir dans une organisation. Heureusement. Quand tu mets un projet en production à l’instant T sur K8s, tu ne sais pas quel sera le statut de ce projet à l’instant T+3 ans, par exemple. Et bien c’est exactement le problème.

Pour le reste de ta réponse, je ne vais pas commenter chaque point. Mais ce ne sont que des généralités, et qui sont pour bon nombre erronées lorsque l’on s’attache à regarder dans les détails.

Il y a tout un tas de problèmes qui peuvent survenir, et qui sont intrinsèquement liés à Docker ou à la topologie de K8s. Et donc qui ne se retrouvent pas dans un environnement virtualisés ou bare-metal.

Je ne les connais pas tous, et loin de là. Mais au fil des années, j’en ai vu passer un certain nombre au hasard de ma veille technologique. Par exemple, pour les containers https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f

Et un autre exemple pour K8s, https://twitter.com/danielepolencic/status/1280087657968627713

[mcorbin]

En tout cas je regrette pas d’avoir déclenché la discussion

Pour clarifier ma position, je pense (comme je l’ai dit à plusieurs reprises sur différentes discussions) que les conteneurs et Kubernetes sont des technologies intéressantes et répondent à certains besoins (et comme toute techno, elles ont des avantages et des inconvénients).

Mais par contre je trouve qu’il y a trop de raccourcis entre “infra as code” et conteneurs, ou “microservice” et conteneurs/K8s… Cela devient la seule façon de travailler. Et c’est ça qui généralement me gêne sur les discussions sur les conteneurs/Kubernetes, c’est qu’il y a peu de discussions sur les alternatives. On oublie vite que:

• La majorité des entreprises ne font pas des microservices (à raison d’ailleurs, c’est pas forcément le sujet ici mais le microservice est un d’architecture bien spécifique avec des avantages mais aussi beaucoup de défauts, une architecture orientée service classique est bien suffisant surtout si on est pas Google ou Netflix).
• La majorité des entreprises n’ont pas d’énormes besoins. Un Jetty sur une VM classique peut prendre sans problème des centaines ou milliers de requêtes/sec. Je vois trop de projets sur k8s/microservices où quelques VMs avec un load balancer devant suffirait (j’ai même vu un projet à plusieurs millions échouer à cause de ça).
• Trop de boites partent sur ces technos pour de mauvaises raisons (mais là c’est pas de la faute de la techno ).
• Il y a une course en avant sur cet écosystème (1 million d’outils de déploiements/monitoring/tracing/operators/network plugins… beaucoup plus ou moins en alpha). Faudrait à un moment ralentir et se demander de quoi on a vraiment besoin.

Je rejoins également @jderrien sur le fait que le manque d’alternative est un problème, je dis souvent que Kubernetes a “cannibalisé” l’écosystème DevOps et aujourd’hui tout (nouveaux outils de monitoring, déploiements…) est centré sur lui.
Et c’est bien dommage, car ça empêche selon moi d’autres solutions d’émerger (et de toute façon si on propose autre chose qu’une infra non basée sur Kubernetes on est limite plus pris au sérieux).

Mais certains projets se prêtent très bien à Kubernetes. Je prépare par exemple un talk sur un projet où Kubernetes occupe une place assez importante, et où son utilisation est intéressante car c’est un projet où il fallait entre autre déployer un grand nombre de fois le même software (à chaque demande cliente en fait), sur des hosts spécifiques. La partie scheduling/tolérance aux pannes de Kubernetes aide pas mal dans ce cas.
Comme @bat79a l’a également montré, un Kubernetes managé et s’intégrant avec les services du Cloud Provider est également plus simple à gérer (mon expérience est peut être un peu biaisée par le fait que je l’ai toujours utilisé en prod on premise, mais mon équipe travaille actuellement sur une offre Kubernetes managé qui j’espère arrivera bientôt donc je suis également en plein dans le sujet ).

En conclusion, j’aimerai qu’on parle moins des conteneurs/Kubernetes comme l’unique solution aux infras modernes d’aujourd’hui, qu’on se penche plus sur les alternatives et surtout qu’on sorte de la hype actuelle où si l’on a pas Docker/Kubernete sur son CV c’est la fin du monde (et ça c’est un vrai problème, les gens qui rentrent de 3 jours de confs tout inquiets car ils ne connaissent pas Kubernetes et se disent “OMG si je le mets pas en prod je suis has been” c’est une réalité).

[aselkim]

Effectivement tu as bien fait de lancer le sujet car c’est un sujet fort intéressant.

Oui Kubernetes n’est pas indispensable, comme on l’a déjà dit, si tu n’as pas besoin d’orchestration, tu n’en as pas besoin. Tu peux déployer des containers sans avoir recours à Kubernetes, ni à un orchestrateur.

Et oui toutes les entreprises n’ont pas besoin d’adopter une architecture microservices, la plus part des entreprises ont des besoins basiques.

Par contre, je pense aussi qu’il y a de réels facteurs qui font (à tord ou à raison) le succès grandissent de Kubernetes, notamment :

• L’approche multi-cloud/hybride-cloud favorise le recours à Kubernetes comme vecteur commun.
• L’échec dans une certaine mesure des solutions de private cloud comme Openstack.
• L’adoption du DevOps (souvent mal compris et mal exécuté mais c’est un autre sujet).

Je partage aujourd’hui ton constat sur le fait que malheureusement Kubernetes étant devenu le standard de facto, la majorité des outils sont uniquement compatibles avec cette plateforme.

J’ai commencé à utiliser Docker en 2015 en production avec AWS ECS puis Rancher sur du on-premise, l’orchestrateur Cattle suffisait largement à nos besoins mais malheureusement on a finalement pas trop eu le choix que de migrer à Kubernetes après l’annonce de l’abandon de Cattle avec Rancher 2.

Aujourd’hui l’ensemble de nos développements est déployé sous forme de containers mais on préfère toujours utiliser des VMs pour les bases de données (et certains autres composants). On est entrain d’étudier le passage à gVisor ou Kata afin de renforcer l’isolation, en attendant, on a des noeuds Kubernetes dédiés par projets.

On a tout ce qu’il faut pour gérer le provisionnement de VMs : packer, terraform, ansible, les outils ne manquent pas pour faire de l’Infrastructure As Code avec des VMs et des technologies de virtualisation comme VMWare.

[alxsbn]

Sur cette histoire de microservices, bcp oublient ce qu’ils ont permis de résoudre, à savoir un pb organisationnel. Et à part travailler dans une équipe de grande taille, on oublie vite qu’un bon monolithe fait le job pour 99% des besoins. Même Fowler s’est rendu compte du désastre en écrivant son anti-pattern “MonolithFirst”.