6 janvier 2020

Développement d'applications, conteneurs et plateforme d'exécution

De plus en plus d’applications tournent dans des conteneurs, et de plus en plus de conteneurs tournent sur des plateformes types Kubernetes. Devons nous changer nos habitudes lorsque nous développons des applications conteneurisées ?

La plateforme d’exécution n’est pas importante

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:

  • D’exposer un endpoint de health indiquant si l’application fonctionne correctement et est prête à fonctionner (et donc prête à recevoir du trafic pour une application web par exemple).

  • D’exposer des métriques (au format Prometheus par exemple), ou alors de les générer dans votre format préféré (Graphite, InfluxDB…​).

  • De générer des logs corrects, avec une manière de contrôler la verbosité des logs etc…​

  • …​

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.

L’impact des conteneurs lors du dev

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.

Conclusion

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.

Tags: programming
Top of page