Choisir l'infrastructure de son application : les questions à se poser

Quand on commence un projet informatique, il est important de savoir où l'on se dirige. En effet, la réussite d'un projet vient avant tout de la bonne identification des besoins pour y répondre au mieux.

Il est donc essentiel d'identifier les fonctionnalités principales à la réussite du projet.

Mais ce n'est pas tout ! Le fait d'avoir une vision sur la façon d'héberger son application et l'infrastructure autour, permet de faciliter la livraison finale et plus généralement de choisir entre plusieurs solutions techniques.

Et même si pour ce point, on peut se dire: "J'ai déjà une application équivalente, je n'aurais qu'à faire pareil", ce n'est pas toujours la meilleure solution.

Chaque application a sa façon de fonctionner, ses contraintes et il est toujours bon de faire évoluer son infrastructure, ainsi que ses applications, pour ne pas accumuler une dette technique qui pourrait compliquer voire empêcher le maintien de l'application dans le temps.

Alors, quelles sont les bonnes questions à se poser et comment y répondre ?

Les questions à se poser

Quel type d'hébergement pour mon application ?

L'une des premières questions qu'on peut être amené à avoir est le type d'hébergement, et par la même occasion l'hébergeur à choisir.

Plusieurs solutions s'offrent à vous : on peut très bien choisir d'héberger son application sur des serveurs physiques, ou dans le cloud (chez AWSLe Cloud AWS (Amazon WebServices) est une plateforme de services cloud développée par le géant américain Amazon., AzureAzure est la plateforme de Cloud de Microsoft., Google CloudLe Cloud consiste à accéder à des ressources informatiques, à partir d'internet, via un fournisseur. Platform, ...).

La première, dite traditionnelle, tend à disparaitre au profit du cloud car gérer l'ajout de serveurs, l'ajout de disques, la sauvegarde des données, etc... est assez fastidieux et demande un bon monitoring pour ne pas avoir de problème sur le fonctionnement de l'application.

De leur côté, les services de cloud sont beaucoup plus flexibles.

Pour savoir quoi choisir, il faut déjà regarder ce que l'on avait jusqu'à présent, si l'on utilise déjà le cloud, et si tel est le cas, le nom du fournisseur de services... Est-on prêt à changer ?

Ensuite, il faut regarder les contraintes de notre application. Par exemple, le fait que ce soit un projet client/serveur, voire même des contraintes juridiques avec les applications traitant des données de santé par exemple.

Comment va être utilisée mon application ?

Quand on réfléchit à l'infrastructure autour de notre application, n'oublions pas à qui est destinée l'application.

Pour de l'interne ou pour une petite entreprise, on n'aura pas forcément besoin des mêmes services que pour une entreprise internationale qui chercherait à réaliser son site vitrine.

La première n'aura pas besoin d'avoir une application qui répond dans la milliseconde, là où l'autre pourrait vouloir un site s'affichant rapidement peu importe où l'on se trouve sur la planète. Et enfin si l'on garde le même exemple, l'application interne aura peut être des gros traitements métiers et de ce fait aura besoin d'une grosse puissance de calcul là ou pour un site vitrine avec juste des fichiers plats, cela n'en nécessitera que peu (voire pas du tout).

Quel monitoring pour mon application ?

Ensuite vient la réflexion de l'observabilité de l'application :

• En a-t-on besoin ?
• Que voulons-nous surveiller (base de données, temps de réponse, trafic, ressource utilisée, ...) ?

Ces choix sont importants, car toutes les solutions ne permettent pas aussi facilement de monitorer tout de la même façon. Certains monitorings nécessitent des développements spécifiques là où d'autres ne demandent qu'une configuration ou la souscription à un service. Certains monitorings peuvent même obliger à des configurations spécifiques que certains services ne pourraient pas fournir.

Par exemple, les services de cloud, généralement fournissent leur propre service de monitoring pour leur produit, mais dès que vous souhaiterez utiliser des services de monitoring externes, la configuration ne sera pas forcément aisée voire impossible, à vous de bien vous renseigner en amont si c'est le cas.

Quel prix pour l'hébergement de mon application ?

Enfin, nous allons aborder la problématique de prix. Sur des serveurs traditionnels, on paye un coût pour une machine, le tarif est donc assez facile à estimer. Côté cloud, c'est bien différent, car chaque service a son mode de facturation différente, même en fonction du niveau de service voulu, la tarification peut différer.

Si nous prenons, un cas très simple, le stockage de fichier, sur un serveur traditionnel, c'est juste un disque, donc en général, en fonction de la capacité souhaitée, on obtient un tarif mensuel.

Mais dans le cas du cloud, ce n'est pas aussi simple, déjà on a en général plusieurs services pour stocker des fichiers (chacun étant spécialisé dans un type de stockage : plus ou moins rapide, stockage partagé ou pas,...). Ensuite au sein même de ces services, on a plusieurs tarifications, qui sont en général liées aux vitesses de lecture/écriture souhaitées et en fonction de ça, on peut être amené à payer au nombre de transactions (nombre d'écriture et de lecture) et/ou à la capacité de stockage.

C'est certainement l'un des points qui posent le plus de problèmes pour l'hébergement cloud. C'est l'un des plus compliqués à estimer avant que l'application ne soit utilisée, car cela revient à avoir une idée du trafic de l'application. Cependant, la majorité des hébergeurs cloud fournissent un calculateur (plus ou moins compliqué à utiliser) pour estimer au mieux son besoin.

Dans la pratique, ça donne quoi ?

Nous partirons du principe que l'application interne que nous voulons réaliser est une application client/serveur (un site web en JavaScriptLangage de scripting orienté objet, une APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données. sur un serveur web, une base de données et un besoin de stockage de fichier).

Hébergement d'application : exemple

Dans notre cas, on partira sur un hébergement cloud car c'est une application assez simple qui fonctionnera dans son coin, on n'a pas envie de gérer l'infrastructure et les problèmes de disponibilités de l'application.

Pour le bien de notre exemple, nous prendrons donc Azure pour héberger la solution.

Utilisation de l'application : exemple

Comme il y a un client et un serveur, pour le client il s'agit juste des fichiers statiques donc il n'aura pas forcément besoin de serveur. Là où en revanche pour l'API, il nous faudra réaliser des traitements et donc on ne pourra pas se passer de serveur. Pour la base de données et le stockage de fichier, on partira sur une solution clé en main fournie par le fournisseur cloud.

Pour les fichiers statiques, dans le cas d'Azure, et d'une application interne (sans réel besoin de géo redondance, et de réponse très rapide), un Storage Account avec un Azure CDNRéseau de diffusion de contenu (ou "content delivery network") devant suffirait.

Pour la base de données, on partirait sur une Azure Database et pour le stockage de fichier un File Share ou un Disk

Enfin pour l'API, à ce stade, on hésite encore entre un App Service et une Azure Container Instance, car ces deux services offrent la containerisation qui permettra au besoin de déplacer l'application ailleurs sans pour autant devoir tout reconfigurer.

On aurait pu choisir une VM et des disques, mais on aurait perdu l'intérêt du cloud.

Enfin si le but était de regrouper son infrastructure dans le cloud, on aurait choisi une solution comme Azure Kubernetes Service.

Monitoring d'application : exemple

Dans notre cas, pour le monitoring, on souhaite juste suivre le trafic de l'application et avoir la remontée d'erreur. On a donc fait le choix d'utiliser Azure Monitor et parmi les services fournit, notamment Application Insight.

Coût d'hébergement d'application : exemple

Pour la base de données, chez Azure, il est possible de choisir entre plusieurs systèmes, MySQLMoteur de gestion de base de données. PostgreSQLMoteur de gestion de base de données libre de droit., Cosmos DB, ... Par contre, là où pour les deux premiers, on paie juste à la capacité maximale de la base de données, le dernier fait aussi payer les transactions. Dans notre cas, de toute façon, nous souhaitons partir sur un SGBD classique, pour des raisons de performance et étant donné que le tarif est le même, nous choisirons PostgreSQL.

Pour l'API, comme l'application est une application interne et que le trafic n'y sera pas gigantesque, nous n'avons pas besoin d'énormément de ressources. Il nous faut donc choisir entre un App Service et une ACI, premièrement, au niveau tarification, les deux services font payer à la ressource allouée, c'est-à-dire une quantité de coeur et de RAM utilisée sur un temps donné (1G de RAM sur 10h = 10G de RAM sur 1h). Mais l'ACI permet une plus grande liberté sur la gestion des ressources à allouer.

Entre ces deux solutions, en fonction du besoin l'un peut être moins cher que l'autre. Si on choisit uniquement le service basique d'un App Service, celui-ci sera moins cher qu'un ACI cependant si on choisit un service Standard, on sera plus cher.

Par contre, un ACI, ne permet que d'exécuter un groupe de conteneurs, là où un App Service lui peut offrir un nom de domaine, la mise à l'échelle automatique et plusieurs autres services en plus en fonction du plan choisi.

Dans notre cas, comme l'on souhaite gérer le moins de choses possible, nous ferons le choix d'un App Service.

Pour conclure sur le choix de l'infrastructure d'une application

Choisir son infrastructure finale est évidemment très compliqué au démarrage du projet tant il existe de nombreuses solutions techniques répondant chacune à une ou des problématiques diverses.

De plus, comme la solution finale est intimement liée aux choix techniques et technologiques du projet, si celui-ci évolue, l'infrastructure peut aussi évoluer par la même occasion.

Notre conseil : il est toujours mieux d'avoir une idée de cet aspect même si ce n'est que ce qu'on ne veut pas comme infrastructure car cela peut avoir des conséquences sur des choix au cours du développement.

Il est évident que nous n'avons pas abordé tous les aspects et problématiques possibles qui peuvent impacter le choix d'une solution plutôt qu'une autre, mais ces quelques problématiques peuvent déjà permettre de dégrossir le sujet.

N'hésitez pas à nous contacter pour étudier le meilleur choix pour votre application !