Le cloud se veut une réponse agile et souple à nos besoins en services informatiques. Mais il se révèle aussi comme un élément structurant qui influence l'architecture des applications informatiques.
Prenons trois exemples:
Deux applications identiques
Les applications A et B sont identiques en terme de fonctionnalité, du nombre d’utilisateur etc.
Pourtant chaque mois la facture du fournisseur du cloud sera pour l'application 'B' trois ou quatre fois plus chère que pour l'application 'A' : pourquoi ?.
L'utilisation du cloud n'est pas gratuite, le coût dépend de l'usage. La réponse est simple: dans l'application 'A' la grande partie des traitements est réalisée sur le poste client. La partie cloud ne sert qu'a délivrer une application complète qui ne fera appel au cloud que pour la récupération des données.
C'est l'utilisateur qui supporte une plus grande partie des coûts en utilisant la puissance de calcul de son poste.
Ce raisonnement est amplifié dans le cadre d'une entreprise qui utilise un cloud privé ou public: elle supporte un double coût: La partie cloud et la partie poste de travail. Cette dernière étant obligatoire: chaque employé est doté d'un poste de travail.
2eme exemple la scalabilité.
Le cloud est avant tout élastique. La puissance mise à la disposition doit pouvoir s'adapter (dans les deux sens) en fonction de la demande. Vous n’êtes pas face à un cloud s'il faut deux jours de délais pour obtenir une machine virtuelle supplémentaire. Au contraire , ces ajustements doivent pouvoir être administrés par des commandes à votre disposition.
Mais toutes les applications ne sont pas 'scalable' de la même manière. Si votre application utilise un serveur de session (en base par exemple) l'ajout de serveur applicatif va se heurter à des problèmes de disponibilité des informations de session. Aussi, il est préférable que la session soit portée par le client afin de libérer la partie serveur d'une tache complexe et coûteuse. Ce déport concerne les traitements , le stockage coté client. Il est favorisé par l'utilisation d'architecture de type REST.
Sans état: Chaque requête d'un client vers un serveur doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre d'un contexte conservé sur le serveur. Cela libère de nombreuses interactions entre le client et le serveur.
https://fr.wikipedia.org/wiki/Representational_State_Transfer
3eme exemple: Les nouveaux terminaux: smartphone-tablette
Un des critères de qualité important pour une application pour les terminaux mobiles est la consommation électrique. Aussi , une application qui est obligée d'échanger en continu avec le serveur va vider les batteries du terminal. Les applications voraces sont vite abandonnées par les utilisateurs. D'où l’émergence d'un type d'application qui embarque les traitements et une partie des données. L'application travaille de manière autonome et se synchronise de temps en temps avec votre cloud.
Ces application sont de type
single-page application alias SPA en anglais
http://fr.wikipedia.org/wiki/Application_Web_Monopage
En conclusion: toutes les applications ne sont pas taillées pour aller sur un cloud. Le choix d'une architecture applicative doit se conformer aux contraintes du cloud y compris dans sa logique de tarification: partager les coûts avec l'utilisateur en mutualisant la CPU et la mémoire.
Prochain épisode: dessine moi un cloud.
