Toutefois, vous retomberez sur plusieurs problématiques : le surcoût de la solution, le fait que ces technologies fonctionnent généralement sur la base d’un couplage fort avec les instances qu’elles gèrent (le couplage fort des composants étant antinomique avec la notion même du Cloud Computing) et tous les problèmes que vous pourriez rencontrer sur le fait d’exécuter du code d’un tiers sur votre application ou l’aptitude de la solution à perdurer dans le temps avec votre application.

En résumé

Les architectures de type Cloud Computing diffèrent des architectures traditionnelles. La facturation à la consommation des services et l’aspect élastique des solutions font que la conservation des journaux de transactions, soit pour des raisons de contrôle, soit pour des raisons de conformité, doit faire l’objet d’une étude économique.

Ainsi, il est important tout d’abord de comprendre la valeur financière d’un journal des transactions : Quelle charge de travail et de stockage pour quel intérêt business ? Enregistrer des centaines de transactions par seconde n’a pas de réelle utilité si ce n’est pas pour les exploiter ultérieurement, soit au titre de la preuve, soit au titre de l’analyse post-traitement.

C’est la valorisation des journaux de transactions qui permettra de déterminer l’architecture la plus adéquate (d’un service simple et à faible coût supplémentaire à un service hautement disponible, fiable et flexible, et géo-redondant). Une application pouvant très bien faire appel à plusieurs architectures selon la nature de la transaction : Un journal d’opérations techniques par rapport à un journal des commandes passées par des clients n’aura sans doute pas droit à la même attention.

Une fois votre architecture construite, il ne vous restera plus qu’à appliquer le coût du service de journalisation comme une quote-part du coût global du service à vos clients, et voilà…