Développement Go
Un binaire, une tâche, et il tient
Nous employons Go pour produire des binaires autonomes, dédiés à une tâche précise et capables de tenir la charge — le plus souvent des services réseau. Nos propres serveurs SMTP en sont faits.
- Binaires autonomes : rien à installer sur la machine
- Conçus pour tenir la charge, sur peu de ressources
- Services réseau, traitements, outils dédiés
- C’est ce qui fait tourner notre propre infrastructure
Le principe
Ce que nous en faisons pour nous-mêmes
Quatre exemples, pas des promesses
C’est l’argument le plus vérifiable de cette page : Go fait tourner des morceaux de notre propre infrastructure, ceux qui n’ont pas le droit de tomber. Nous nous en servons aujourd’hui pour :
- notre outil de redirection HTTP, qui voit passer le trafic de nos clients ;
- un outil de vérification de la présence d’adresses IP dans des listes noires ;
- une application d’identification des botnets qui nous attaquent en SSH ;
- nos serveurs SMTP entrants et sortants — ceux-là mêmes qui routent plus de cinquante mille e-mails par jour.
Quand nous disons qu’un service Go tient la charge, ce n’est pas une lecture de documentation : c’est ce que nous exploitons.
Un binaire autonome
C’est la caractéristique qui change tout en exploitation. Un programme Go se compile en un fichier unique, sans interpréteur ni bibliothèques à installer sur la machine qui l’exécute. On le dépose, on le lance.
Les conséquences sont concrètes : rien à faire correspondre entre le poste de développement et le serveur, un déploiement qui consiste à remplacer un fichier, un retour en arrière qui consiste à remettre le précédent, et une empreinte mémoire qui se compte en dizaines de méga-octets là où d’autres technologies demandent des centaines.
Le terrain où il excelle
Une tâche précise, beaucoup de sollicitations, peu de logique métier. Un service réseau qui répond vite et souvent. Un traitement qui doit avaler un volume important sans consommer toute la machine. Un outil interne dont la fiabilité prime sur la richesse fonctionnelle.
C’est aussi le bon outil pour extraire d’une application existante la partie qui la ralentit : plutôt que de tout réécrire, on sort ce morceau dans un service dédié.
Là où il n’est pas le bon choix
Go n’a pas la richesse d’écosystème de PHP ou de Java pour construire une application de gestion complète avec ses écrans, ses formulaires et son administration. Sur ce terrain, Symfony ou Spring Boot vous coûteront beaucoup moins cher. Nous ne proposons pas Go pour un extranet ; nous le proposons pour ce qui doit encaisser.
Les usages
Ce que nous construisons avec
-
Services réseau
L’usage principal. Nos serveurs SMTP entrants et sortants et notre outil de redirection HTTP en sont faits — ils tournent en permanence.
-
Outils de sécurité
Vérification d’adresses IP en listes noires, identification des botnets qui nous attaquent en SSH : des traitements nombreux et rapides.
-
API à fort débit
Quand une API doit répondre vite et souvent, avec peu de logique métier, Go donne le meilleur rapport entre charge tenue et ressources consommées.
-
Extraction d’un goulot
Sortir d’une application existante la partie qui la ralentit, dans un service dédié — plutôt que de tout réécrire.
-
Un fichier à déployer
Pas d’interpréteur, pas de bibliothèques à installer. On dépose le binaire et on le lance ; le retour arrière consiste à remettre le précédent.
-
Empreinte réduite
Quelques dizaines de méga-octets de mémoire là où d’autres technologies en demandent des centaines. L’hébergement s’en ressent.
Questions fréquentes
Go : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Go pour une application de gestion ?
Rarement, et nous vous le dirons. Go n’a pas la richesse d’écosystème de PHP ou de Java pour construire écrans, formulaires et administration : Symfony ou Spring Boot vous coûteront moins cher sur ce terrain. Go se justifie pour ce qui doit encaisser, pas pour ce qui doit être riche.
Go ou Node.js pour une API ?
Node.js quand le sujet est le nombre de connexions en attente et que le traitement est léger, ou quand un seul langage du serveur au navigateur a de la valeur. Go quand il y a du travail réel à faire à chaque requête, et que les ressources comptent.
Peut-on n’en faire qu’une partie du système ?
C’est même l’usage le plus fréquent et le plus rentable : extraire d’une application existante le morceau qui la ralentit, et le remplacer par un service Go dédié. Le reste ne bouge pas, et le gain est mesurable immédiatement.
Comment est-ce hébergé ?
Très simplement, et c’est l’un de ses arguments : un binaire autonome, sans environnement à reconstituer, sur un serveur privé ou un conteneur. L’empreinte mémoire réduite permet souvent de faire tenir plusieurs services sur la même machine.
Qu’est-ce qui ralentit votre système aujourd’hui ?
Si la réponse tient en un composant précis, c’est souvent lui qu’il faut sortir — et Go est fait pour ça.