je pense qu’il faut dissocier l’application en elle même (et donc son développement) de la plateforme d’exécution (où l’application tournera). En effet, une application aura toujours besoin:

Cela n’a aucun rapport avec la plateforme d’exécution de l’application. Par exemple, mon endpoint de health peut aussi bien être utilisé par un load balancer comme HAProxy, par un agent comme Consul, ou bien par Kubernetes.

Une application devrait pouvoir passer très facilement d’une plateforme d’exécution à une autre, comme par exemple d’un déploiement sur machines virtuelles classiques, sans conteneurs, à un déploiement dans Kubernetes. Si cela n’est pas possible, cela veut dire qu’on a lié l’application à sa plateforme, et ce couplage fort rend la possibilité de changement beaucoup plus difficile.

En effet, on parle beaucoup aujourd’hui de Kubernetes, mais comme je le dis toujours, ce n’est pas la plateforme miracle. Même si vous déployez vos applications sur Kubernetes aujourd’hui, rien ne dit que vous ne voudrez pas les "sortir" de Kubernetes l’année prochaine pour une raison ou une autre.
De la même façon, il devrait être facile de passer d’une application hébergée sur une machine virtuelle à une application tournant sur Kubernetes. L’outillage autour de l’application va changer, mais pas l’application en elle même.

A part docker-compose qui est je trouve intéressant pour démarrer facilement des dépendances comme des bases de données, je ne vois pas pourquoi on devrait parler de conteneurs lors de la phase de développement. Comme dit dans le paragraphe précédemment, c’est beaucoup trop tôt.

Le développeur doit pouvoir développer sans se soucier de la plateforme d’exécution. Ce sera dans la plateforme d’intégration continue que la plateforme d’exécution aura un impact (pour construire un conteneur, un package…​ à partir du projet).
Bien sûr, il y aura toujours dans le dépôt Git du projet quelques fichiers en lien avec cela (Dockerfile par exemple), mais cela n’a aucun impact sur le développement de l’application elle même.

Et surtout, quand je développe, je ne veux surtout pas à avoir à construire des conteneurs, installer un minikube ou avoir à déployer sur des clusters Kubernetes depuis mon poste de dev.
Pour moi, cela doit être le job de la plateforme d’intégration continue. Je pousse mon travail, et je peux d’une façon ou une autre déployer mon application sur ma plateforme. Cela permet également une certaine tracabilité.

En local, je veux travailler en isolation.

Je pense sincèrement qu’il faut pouvoir s’abstraire de la plateforme d’exécution lors du développement.
Les développeurs perdront un temps fou à configurer leurs postes, seront frustrés, à chaque montée de version plus rien ne fonctionnera etc…​ si développer demande trop de dépendances.

En conclusion: Evitez de faire fuiter votre infrastructure sur vos postes de développement.