« Je développe & je construis mon usine de développement » : 3e partie de notre livre blanc sur le cloud

Blog Single
Cloud

Les applications Serverless bien conçues sont découpées en services autonomes et utilisent un minimum de code (cf. cold start chapitre 2). Au fur et à mesure qu’un projet se développe, l’objectif principal va être de maintenir un faible niveau de complexité.

La bonne gouvernance de l’usine de développement participe à garder une bonne maîtrise de l’application et indirectement un niveau de complexité le plus faible possible

Ce chapitre fournit des recommandations pour la conception et la gestion des référentiels de code (stockage des codes sources applicatifs) dans des projets Serverless, et des bonnes pratiques en termes de déploiement de versions, CI/ CD (Continuous Integration, Continuous Deployment).

 

  • Organisation des référentiels de code (repositories)

Dans l’univers du FaaS (et plus généralement des microservices), la tentation est grande de prendre des raccourcis en venant enrichir le périmètre d’une fonction existante. Ainsi, une fonction AWS Lambda simple au départ va voir son niveau de complexité augmenter au fil du temps pour devenir en quelque sorte un monolithe à elle seule.

Ce “monolithe” est alors représenté par une seule fonction AWS Lambda effectuant plusieurs tâches, et dont la logique applicative est contenue dans un seul et unique référentiel de code.

Si cela peut fonctionner pour des applications Serverless assez simples (tâches cron, traitement de données, processus asynchrones), à mesure qu’elles évoluent en intégrant de nouvelles fonctionnalités, il devient important de passer par une étape de refactoring.

L’utilisation de frameworks tels que AWS Serverless Application Model (SAM) ou Serverless Framework facilite le regroupement de fonctionnalités dans des services plus petits. Chacun d’eux peut avoir un référentiel de code distinct. Pour SAM, le fichier template (.[yaml|yml]) contient toutes les ressources et définitions de fonctions nécessaires à une application.

Par conséquent, la division d’une application en microservices avec des modèles séparés est un moyen simple de diviser les référentiels et les groupes de ressources.

Dans la plus petite unité d’une application Serverless, il est également possible de créer un référentiel par fonction. Si ces fonctions sont indépendantes et ne partagent pas d’autres ressources AWS, cela peut être approprié. Les fonctions de traitement d’événements simples sont des exemples de candidats pour ce type de structure de référentiel.

Dans la plupart des cas, il est logique de créer des référentiels autour de groupes de fonctions et de ressources qui définissent un microservice. En prenant un exemple e-commerce, le « traitement des paiements » est un microservice avec plusieurs fonctions connexes plus petites qui partagent des ressources communes. 

Comme pour toute application, la conception du référentiel dépend du cas d’utilisation, de la structure et de l’organisation des équipes de développement. Un référentiel centralisé rend plus difficile le travail sur des fonctionnalités différentes, la gestion du repository et les livraisons. À contrario, le fait d’avoir un trop grand nombre de référentiels peut amener à de la duplication de code et des difficultés de partage des ressources entre référentiels.

Trouver le bon équilibre pour son projet est une étape importante et aura un impact direct sur l’agilité et la facilité que l’on aura à maintenir son application.

 

  • Utilisation de services en lieu et place de bibliothèques de code

Les services proposés par un cloud provider sont des éléments importants que les applications Serverless vont pouvoir consommer. Ces services offrent souvent une mise à l’échelle, des performances et une résilience supérieure à des frameworks fournissant des fonctionnalités similaires.

Exemple avec l’utilisation de l’API Gateway/Lambda d’AWS.
Amazon API Gateway est un service managé, qui permet aux développeurs d’exposer, de surveiller, de sécuriser facilement des APIs.

Des applications Web migrées vers des fonctions Lambda peuvent utiliser des frameworks tels que Flask (pour Python) ou Express (pour Node.js) qui prennent en charge le routage et la gestion des utilisateurs. Ces solutions conviennent bien lorsque l’application s’exécute sur un serveur Web.

Pour lire la suite et aller plus loin sur le sujet, téléchargez notre livre blanc (disponible au format PDF interactif).