Maitriser le shell est toujours intéressant. J’utilise d’ailleurs régulièrement sur ma machine des commandes comme find, grep, ou awk, et j’ai quelques scripts qui me permettent de changer certains réglages.
Pour pas mal de petits besoins d’administration système, un script shell peut être suffisant. Pourquoi s’embêter à utiliser autre chose alors qu’un petit script avec quelques conditions et quelques commandes fait le job ?

Malheureusement, je pense que les "petits besoins" peuvent grossir rapidement, et pour moi des scripts shell trop longs sont vite un problème. Je vais essayer d’expliquer pourquoi avec un exemple.

Prenons comme exemple un grand classique de l’administration système: vous voulez écrire un script réalisant un backup d’une base de données quelconque.
A première vue, le besoin est simple et pourrait être réalisé par un script shell:

On pourrait très bien écrire un script shell réalisant ces deux actions.
Mais quand on réfléchit un peu plus à ce script, et à comment le rendre "prod ready", on se rend compte finalement qu’on veut aussi:

On peut ensuite imaginer plein d’autres trucs, comme un système de retry en cas d’échec par exemple. Peut être aussi qu’on aura également besoin d’un client S3 pour stocker le backup sur un object store, ou d’interagir avec des services cloud (pour les logs et les métriques).

Mon petit script est finalement en train de se complexifier, et devient de plus en plus un programme à part entière. De plus, chaque interaction avec un système externe apporte son lot de complexité (client spécifique nécessaire, authentification, mTLS…​) qui peut être difficile à réaliser en shell.

Je veux également que ce script (ou programme) ne soit pas gêré de façon différente par rapport aux autres programmes développés dans l’entreprise:

Je pense qu’il faut éviter de faire une distinction entre les scripts écrits par les ops et les programmes écrits par les développeurs.

Le cycle de vie de ces base de codes doit être selon moi identique, et utiliser un langage de programmation comme Go pour réaliser ce genre de tâche amène son lot d’avantages, comme par exemple :

Bref, du code c’est du code, que ce soit écrit par un dev ou par un ops. Les deux mondes doivent avoir les mêmes exigences sur le code produit. D’ailleurs, cela permet à tout le monde de travailler sur les différents programmes de l’entreprise de la même façon, et donc les développeurs peuvent aussi contribuer à l’outillage ops de façon standardisée.

Je ne dis pas qu’on ne doit jamais faire de shell, pour de petites tâches cela marche très bien, mais dès qu’on commence à avoir des centaines de lignes de shell, avec de la logique dans le script, c’est le signe qu’il est temps selon moi de passer à autre chose.

On me dit aussi parfois que coder en shell est plus rapide que dans un autre langage. C’est vrai que le shell se prête très bien à certaines choses, comme la rechercher et manipulation de fichiers par exemple. Si votre script ne fait que ça vous pouvez continuer comme je l’ai dit précédemment à faire du shell. Mais je ne pense pas que cet argument tient quand le script se complexifie, je dirai même que c’est l’inverse car le script sera plus maintenable dans un autre langage de programmation.

je pense que l’abus de shell est dangereux pour la santé. Un certain nombre de scripts seraient plus maintenables et plus fiables dans un langage comme Golang (je cite beaucoup Go ici car je pense que c’est un très bon langage pour ce genre de tâches. Mais rassurez vous, le langage a aussi ses défauts).

Les développeurs et les ops doivent travailler de la même façon sur leurs programmes, et le shell apporte trop de désanvantages pour être utilisé pour des programmes complexes.