Architecture sans serveur : quoi, où et pourquoi ?

Malgré son nom, l'architecture sans serveur n'est pas vraiment sans serveur. Cette appellation impropre est source de confusion quant à la définition exacte d'une architecture sans serveur.

Après tout, les applications ont besoin d’un serveur quelconque pour fonctionner. Une architecture sans serveur implique qu’un prestataire de services cloud, tel que Google, Amazon Web Services (AWS) ou Microsoft Azure fournit une infrastructure dorsale pour votre application. Sa popularité est partiellement due aux services comme Kubernetes qui a soudainement suscité une vague d’intérêt parmi les entreprises pour l’hébergement payant de leurs applications sur d’autres services. Toutefois, même si cette approche présente plusieurs avantages, ce processus n’est pas si simple.

Le temps presse

Le principal avantage de l’implémentation d’une architecture sans serveur est qu’elle dispense les développeurs des tâches chronophages de maintenance opérationnelle et permet à votre entreprise d’éviter des coûts opérationnels élevés.

Puisqu’ils ne possèdent pas l’infrastructure dorsale sur laquelle reposent les applications, vos développeurs ne sont plus responsables de certains tâches de maintenance, telles que le provisionnement et la mise à l’échelle. En fait, l’un des arguments de vente les plus percutants en faveur de l’adoption d’une infrastructure dorsale décentralisée est la mise à l’échelle automatique et le débogage proposés par les prestataires de services cloud via une architecture sans serveur.

En partageant le fardeau de la maintenance du système dorsal, les développeurs peuvent consacrer plus de temps à des projets plus importants. Par exemple, ils ne doivent plus consacrer de temps à planifier la capacité, car ce n’est plus de leur ressort. De la même façon, le prestataire de services cloud automatise l’architecture sans serveur pour en permettre la réduction ou le développement de l’activité selon les besoins, le tout sans aucune directive de la part d’un développeur.

Une architecture sans serveur présente également des avantages en matière de responsabilité. En cas de problème sur le système dorsal, c’est le prestataire et non le développeur qui est tenu de corriger la situation. Ainsi, si un composant tombe en panne, on n’attendra pas des développeurs qu’ils consacrent du temps et des ressources pour le réparer.

En fin de compte, selon la taille de votre entreprise et ses besoins uniques, une architecture sans serveur peut représenter une option rentable. En faisant gagner du temps à vos développeurs, vous économisez de l’argent et réduisez les coûts opérationnels globaux. En outre, l’autre avantage souvent négligé que présente l’adoption d’une infrastructure dorsale hors site est que vous pouvez retirer le poste "expert en serveurs" de la longue liste de qualifications que vous utilisez pour recruter du personnel.

Si les coûts opérationnels pèsent sur votre entreprise, l’architecture sans serveur est une option intéressante à envisager. 

Obstacles à prendre en compte

Pourtant, rien n’est jamais si simple et le fait qu’une architecture sans serveur soit décentralisée présente quelques problèmes.

Tout d’abord, il est presque impossible pour les entreprises de surveiller les applications exécutées en arrière-plan sur des systèmes dorsaux qui ne sont pas les leurs et qu’elles ne peuvent pas superviser directement. Cette visibilité limitée se traduit parfois par des suppositions dangereuses qui forcent les développeurs à deviner les performances d’une application. On en constate les répercussions lorsque les spécialistes tentent de résoudre des problèmes de performance ou d’assurer le suivi des analyses de performance clés.

La préoccupation majeure est la sécurité. Avec une surface d’attaque plus étendue, le risque de sécurité que présente une architecture sans serveur est parfois plus important que lorsque vous contrôlez vos systèmes en interne. Finalement, tout revient à la capacité du prestataire de services cloud à gérer les risques. Renseignez-vous bien avant de migrer vers le cloud pour vous assurer que l’infrastructure est sécurisée. Comme le dit le fameux proverbe, vous n’êtes jamais plus sécurisé que votre maillon le plus faible.

Pour finir, certaines applications n’ont tout simplement pas été conçues pour une architecture sans serveur. Ce n’est pas une solution universelle aux plaintes concernant le système dorsal. Par exemple, le prix dépend souvent des ressources utilisées par une application. Les applications conçues pour consommer des volumes considérables de ressources de calcul entraîneront une réelle augmentation des coûts pour votre entreprise, auquel cas, vous auriez intérêt à les héberger en interne.

Cas d’utilisation d’une architecture sans serveur

Une entreprise a souvent besoin d’une architecture sans serveur lorsqu’une de ses applications est conçue pour exécuter du code et des tâches basées sur des déclencheurs. On dit de cette application qu’elle est de type "régler et oublier". Dans ces cas, l’application reste passive sur l’infrastructure et attend un événement déclencheur. Les architectures sans serveur sont utiles pour ces applications, car elles augmentent l’utilisation des ressources à la hauteur des besoins de l’événement déclenché, ce qui limite les coûts.

En outre, l’architecture sans serveur est tout à fait adaptée aux projets d’intégration continue/de livraison continue (CI/CD), car elle permet aux développeurs d’actualiser constamment le code en production sans devoir se soucier d’avoir à mettre à jour le serveur. L’actualisation du code en temps réel permet d’accélérer le délai de livraison.

Si votre activité est ralentie par la maintenance opérationnelle, l’architecture sans serveur est sans doute une solution rentable. Mais ne brûlez pas les étapes et renseignez-vous sur votre prestataire avant de vous engager pour vous assurer que ses systèmes sont parfaitement sécurisés et identifiez les besoins de vos applications avant de choisir une architecture sans serveur.