Technical Tutorials

Pendant des années, la recette standard pour construire des outils internes impliquait un maillage complexe de fonctions AWS Lambda, de configurations API Gateway, de politiques IAM et de buckets S3. Bien que puissant pour les applications destinées au public, cette approche axée sur l'infrastructure est souvent excessive pour les tableaux de bord internes, les pipelines de données ou les panneaux d'administration. C'est ici qu'intervient Windmill, une plateforme open source auto-hébergée (ou hébergée dans le cloud) qui transforme le code en workflows, offrant une alternative simplifiée à la pile backend serverless traditionnelle.

Dans cet article, nous explorerons comment Windmill peut servir de backend serverless robuste pour vos outils internes, en réduisant le code boilerplate, en simplifiant le déploiement et en améliorant l'expérience développeur.

Pourquoi se tourner vers autre chose que Lambda + API Gateway ?

La combinaison d'AWS Lambda et d'API Gateway est un modèle éprouvé, mais elle comporte un surcoût important :

Complexité de configuration : La gestion des rôles IAM, des stades d'API Gateway et des variables d'environnement Lambda peut être source d'erreurs et chronophage.
Logique dispersée : La logique métier est souvent répartie sur plusieurs fonctions Lambda, ce qui rend difficile le suivi du flux de données.
Démarrages à froid (Cold Starts) : Bien qu'ils s'améliorent, les démarrages à froid de Lambda peuvent toujours affecter la réactivité des outils internes où les utilisateurs s'attendent à un retour immédiat.
Difficulté de débogage : Le débogage de fonctions serverless distribuées nécessite de reconstituer les journaux à partir de multiples sources.

Windmill répond à ces défis en fournissant un environnement unifié où vous pouvez écrire, planifier et orchestrer des extraits de code (en JavaScript/TypeScript, Python ou Bash) directement depuis le navigateur. Il agit comme un « backend-as-a-service » spécifiquement conçu pour les cas d'usage internes.

Comment Windmill agit comme un backend serverless

Windmill vous permet de définir des « scripts » (extraits de code) qui peuvent être exposés comme des points de terminaison HTTP, déclenchés par des événements ou planifiés. Cela élimine le besoin d'une couche API Gateway séparée. Voici comment l'architecture évolue :

Extraits de code en tant que fonctions : Au lieu de déployer une Lambda, vous collez votre code dans Windmill. Il s'exécute dans un bac à sable isolé.
Déclencheurs HTTP intégrés : Vous pouvez générer instantanément une URL sécurisée pour n'importe quel script, servant de point de terminaison API.
Orchestration de workflows : Enchaînez plusieurs scripts pour construire une logique complexe sans gérer l'état ou les callbacks.

Exemple pratique : Construire une API d'export de données

Construisons un simple outil interne qui exporte les données des utilisateurs depuis une base de données PostgreSQL vers un fichier CSV et les stocke dans S3. Avec Lambda + API Gateway, cela nécessiterait :

Une fonction Lambda avec un pool de connexions à la base de données.
Un point de terminaison API Gateway configuré pour déclencher la Lambda.
Des autorisations IAM pour S3 et RDS.
Des variables d'environnement pour les identifiants de la base de données.

Avec Windmill, vous pouvez obtenir le même résultat dans un seul script :

// Windmill Script: export_user_data.js
import { query } from "windmill-postgres";
import { uploadFile } from "windmill-s3";

// Récupérer les données depuis PostgreSQL
const users = await query(`SELECT * FROM users WHERE active = true`);

// Convertir en CSV
const csvContent = "user_id,email,created_at\n" + users.map(u => 
    `${u.id},${u.email},${u.created_at}`
).join("\n");

// Téléverser dans S3
const s3Key = `exports/users_${new Date().toISOString()}.csv`;
await uploadFile("my-internal-bucket", s3Key, csvContent);

// Retourner l'URL S3
return {
    status: "success",
    url: `https://my-internal-bucket.s3.amazonaws.com/${s3Key}`
};

Une fois enregistré, Windmill génère automatiquement un point de terminaison HTTP POST pour ce script. Vous pouvez maintenant appeler ce point de terminaison depuis votre frontend interne, sans configurer d'API Gateway ou de rôles IAM. Windmill gère l'authentification, la limitation de débit et l'environnement d'exécution pour vous.

Principaux avantages pour les outils internes

Itération plus rapide : Modifiez le code et déployez instantanément. Aucun pipeline CI/CD n'est requis pour les petites modifications.
Observabilité unifiée : Tous les journaux, traces et historique d'exécution sont regroupés en un seul endroit.
Efficacité des coûts : Pour les outils internes, vous ne payez souvent pas pour la capacité Lambda inactive. Le modèle basé sur l'utilisation de Windmill peut être plus prévisible.
Support multi-langage : Mélangez Python, JS et Bash dans le même workflow, en exploitant le meilleur outil pour chaque tâche.

Quand utiliser Windmill par rapport au Serverless traditionnel

Windmill est idéal pour :

Les panneaux d'administration et tableaux de bord internes
Les pipelines de données et les tâches ETL
Le prototypage rapide de la logique backend
Les rapports et notifications automatisés

Restez sur Lambda + API Gateway pour :

Les API destinées au public avec des SLA stricts
Les scénarios à grande échelle et forte concurrence
Lorsqu'une intégration profonde avec des services spécifiques à AWS (comme les flux DynamoDB) est requise

Conclusion

Windmill offre une alternative convaincante à la pile backend serverless traditionnelle pour les outils internes. En abstrayant les préoccupations d'infrastructure et en fournissant un environnement unifié pour l'exécution et l'orchestration du code, il permet aux développeurs de se concentrer sur la logique métier plutôt que sur la plomberie technique. Si vous construisez des outils internes et que vous trouvez que Lambda + API Gateway représente plus de surcharge que de valeur, il vaut la peine d'expérimenter avec Windmill pour voir combien de complexité vous pouvez éliminer.