Conseil

Développement d’applications Cloud-natives : ce qu’il faut savoir

Serverless ou API-First ? Les applications natives pour le Cloud reposent sur une nouvelle architecture qui exploite pleinement les spécificités du Cloud. Cet article fait le point.

Zachary Flower
par
Publié le: 05 déc. 2017

Avec l’omniprésence des fournisseurs de Cloud, à l’image d’Amazon, Microsoft ou encore Google, « Cloud-native » est devenu un concept intégré désormais dans  les projets de développement d’applications modernes. En bref, une application native pour le Cloud (Cloud-native donc) est une application qui a été conçue spécialement pour le Cloud. C’est aussi simple que cela. De telles applications sont conçues et architecturées avec à l’esprit une infrastructure et des services Cloud. Au lieu de se reposer sur des serveurs installés en interne, ou encore des bases de données, ces applications s’adossent à des services qui font abstraction des couches hardware et de leur maintenance – et dans certains cas de l’OS. Les développeurs peuvent ainsi se concentrer sur ce qui compte, à savoir le produit en lui-même.

Ces couches d’abstraction, si elles rendent plus gérables l’infrastructure et les équipes dédiées, permettent aussi de réduire les coûts, comparé aux solutions de virtualisation, par exemple et aux installations bare-metal : moins de ressources, moins d’équipes et moins de risques. Toutefois, il ne faut pas perdre de vue que ces applications Cloud-natives comportent également leur lot de difficultés qui leur est propre. Parmi l’une d’entre elles, l’intégration de tous les composants est la plus courante.

Au démarrage, une API

Dans le développement traditionnel, il est une constante : le code a un accès direct à toutes les ressources dont il a besoin. Cela donne une base de code monolithique, peu flexible, qui reste difficile à découpler. Si le Cloud peut certes supporter de telles applications, il peut être compliqué de bénéficier de toutes les spécificités du Cloud et du gain associé, comme le dimensionnement ou la distribution sur l’infrastructure.

C’est là que l’approche « API-first » peut être d’une grande  aide. Pour ceux qui ne connaissent pas, cette méthode de développement consiste à concevoir, documenter et créer l’API d’une application avant tout autre chose. L’avantage : cela unifie la logique métier et l’isole des clients, tout en proposant une unique source sur le fonctionnement de l’application.

Toutefois, cela peut s’apparenter à une vraie contrainte. Avec une telle approche, les autres facettes de l’application sont développées une fois cette API finalisée. Heureusement, avec les standards de documentation, comme API Blueprint, il est possible de monter une API factice qui suit parfaitement la documentation pour tester les phases d’intégration avant même que l’API soit développée.

Mais l’un des plus gros avantages de cette approche « API-First » n’est finalement pas cela. L’avantage principal est que cela permet de disposer d’une forme de reversibilité dans la prise de décision.

Avec une technologie serverless

Ces deux concepts ne sont toutefois pas exclusifs. On peut développer une application Cloud-native sans API et une application bâtie sur une API sans Cloud. Mais ces deux concepts sont en parfaite harmonie dans les environnements serverless. Ces derniers, comme leur nom ne l’indiquent pas, ne veulent pas dire qu’ils sont dépourvus de serveurs, mais qu’ils ne nécessitent pas de se préoccuper de serveurs.

Au lieu de développer une application ou une API qui s’exécutent sous la forme d’un service, le développeur place son application entre les mains de fonctions individuelles qui s’exécutent dans un runtime particulier. Il s’agit là d’un niveau  très élevé d’abstraction. Avec cette approche, le développeur bénéficie de ressources disponibles dans le Cloud, tous fournisseurs inclus.  Le résultat final est un back-end hautement distribué, pouvant être dimensionné à l’infini et hautement disponible.

 

Pour approfondir sur Applications et services