L’appellation ‘serverless’ est trompeuse, car il ne s’agit pas d’une informatique ‘sans serveurs’, mais de s’appuyer sur des serveurs bien réels… que la DSI n’a pas à maintenir. Voici 5 domaines qui présentent l’avantage d’être adaptés à ce type d’architecture ‘as-a-Service’.
Pour la DSI, une informatique ‘serverless’ peut se traduire par le téléchargement d’extraits de codes, le service d’hébergement faisant le reste. S’appuyant massivement sur Amazon AWS et Microsoft Azure - dans une moindre mesure sur IBM, Google, etc. - cette informatique fonctionne avec des blocs de code qui sont déclenchés par des actions spécifiques.
Voici 5 modèles d’applications construites sur le modèle ‘serverless’ :
API
L’API (Application Programming Interface) est du code des plus simple et plus directe, qui renvoie vers une application ou des données à consommer. Une API REST n’est généralement pas difficile à construire. Elle nécessite un cadre de base web, une bibliothèque pour le rendu des données dans le format de retour (généralement JSON), et le code à coller nécessaire pour communiquer avec les données. Avec une architecture serverless, le développeur peut se concentrer exclusivement sur l'écriture et le déploiement du code nécessaire pour servir l'API, et ne pas être distrait par beaucoup d'autres choses. Prix et poids légers en font un élément de base du Cloud.
Webhooks
Comme pour les API, le cadre ‘serverless’ est bien adapté aux webhooks, qui consistent à mettre en place des callbacks sur HTTP pour la mise en place des tuyaux et plugins dans des applications Web. Ils nécessitent peu de code, la surcharge est faible, l’entretien minimum, et la mise à l‘échelle est automatisée. Les actions de type webhook sont idéales pour une approche ‘serverless’.
Contenu statique
Les architectures 'serverless' fournissent également une méthode simple pour servir du contenu statique, comme des pages image, audio, ou HTML qui ne sont pas modifiées par une application. Les éléments statiques peuvent être stockés sur des clouds de stockage froid, et être accélérés grâce à un cache géolocalisé. Encore une fois, le gros avantage est que chaque pièce du puzzle se redimensionne automatiquement pour s’adapter la demande. Il est également relativement facile d'ajouter des fonctionnalités dynamiques au fil du temps si nécessaire. Cependant, le temps de chargement (spin-up) peut affecter les performances, le geocaching devient alors plus utile.
Applications sur une seule page
Pensez à cela comme une combinaison des approches ci-dessus. Les contenus de base pour une page peuvent être servis comme contenu statique ; les appels d'API peuvent se révéler nécessaires pour la mise en œuvre de fonctions sans serveur. Le rendu des données sur le poste de l’utilisateur s’effectue via un framework JavaScript. Chaque élément servi séparément à la demande peut évoluer de façon indépendante. L’inconvénient c’est que l'application doit être mis en œuvre comme un ensemble de fonctions disparates plutôt qu'un seul projet unifié, bien que cela ne devrait pas être un obstacle pour toute personne utilisant des techniques modernes de contrôle de sources et de gestion de projet. En outre, vous aurez besoin de mettre en œuvre un cadre frontal, mais encore une fois, tout développeur web qui se respecte devrait déjà en utiliser au moins un.
Applications basées sur les événements qui fonctionnent en arrière-plan
Les apps ‘serverless’ fonctionnent en réponse à des événements, mais rien ne dit qu’un événement doit être une requête HTTP. Il pourrait être un événement ou un message d'ambiance depuis un service dans le cloud, ou déclenché pour fonctionner sur un calendrier - une méthode pratique pour exécuter des fonctions passives ou de faible priorité.
Le détail le plus cohérent sur le travail avec une architecture ‘serverless’ c’est qu'elle implique la création de composants faiblement couplés, des microservices. Si l'application que vous avez à l'esprit ne se prête pas à être composée de cette manière ou si vous essayez de porter d'une application monolithique qui sera difficile à séparer et retravailler, ne déployez pas une configuration ‘serverless’ dans ce rôle. Il est préférable de construire de nouveaux petits éléments, et de les cultiver à partir de là.
Image d’entête 635755968 @ iStock Creative-Touch
