L’architecture d’une application cloud « évolutive » est fréquemment fondée sur une architecture multi-tiers avec un middle-tiers applicatif sans état, afin de permettre aux différents tiers d’évoluer indépendamment. Ce type de découpage permet d’optimiser l'utilisation des ressources.

Dans ce modèle, le tiers applicatif est supposé pouvoir évoluer sans limite : puisqu’il ne gère pas d’état, il suffit théoriquement d’ajouter des machines pour pouvoir soutenir la charge. Dans les faits, ce tiers doit interroger la base, ce qui suppose des appels réseaux à un serveur ou à un service de données qui lui exécutera très certainement des requêtes de lecture/écriture sur un disque. La base de données devient alors le goulot d'étranglement, limitation que l’on peut tenter de réduire par la mise en œuvre d’un service de cache dont il faudra choisir la proximité (locale à la machine, ou accessible en réseau).

Ce type d’approche conduit alors à se poser d’autres questions telles que les critères d’évolutivité applicables au tiers applicatif (délais liés à l’ajout de nouvelles instances, sur la base de quelles métriques, constatées sur quelle durée…). En outre, les composants hébergés au sein d’un même tiers applicatif ne sont pas nécessairement sollicités avec la même charge. Idéalement, il faudrait donc pouvoir mettre à l’échelle ces composants selon leur charge respective.

Les réflexions portant sur la proximité de l’état du middle-tiers et sur la mise à l’échelle indépendante des différents composants qui y sont hébergés peuvent alors conduire à revoir le modèle du tiers applicatif en le considérant non pas comme un tout, mais comme la combinaison d’entités individuelles. C’est la démarche que nos collègues de « 343 Industries » ont appliquée pour construire les services Cloud Azure déployés pour le jeu Halo 4. Pour ce faire, ils se sont appuyés sur un framework développé par Microsoft Research : Project Orleans.

Project Orleans propose un langage de conception fondé sur le modèle « Actor ». En soi, le modèle « Actor » n’est pas nouveau. Il emploie une définition d’unités de calcul baptisées « Actors ». Un « Actor » encapsule les comportements et les états, et communique avec d'autres « Actors » avec des messages. Il dispose donc d’un état local et peut évoluer indépendamment des autres « Actors ». Les librairies Project Orleans, permettent de concevoir et implémenter un middle-tiers comme un ensemble de « Grains » (= les « Actors » dans le vocabulaire Project Orleans). Elles gèrent les accès concurrentiels des services Cloud, la persistance de leur état et leur cycle de vie (activation et invocation à la demande) tout en rendant la conception de ces services beaucoup plus simple.

La présentation “Using Orleans to Build Halo 4’s Distributed Cloud Services in Azure" décrit en détail comment la technologie Project Orleans a été employée pour construire les services cloud déployés pour le jeu Halo 4. 

Oleans-Halo4

Le récent épisode de Cloud Cover Show  « Simplification du développement de services cloud scalables avec Microsoft Research Project Orleans » explique également en quoi consiste ce framework et le démontre rapidement avec un exemple d’utilisation pour gérer des devices…. Project Orleans est donc un framework qui peut avoir un rôle à jouer dans l’implémentation de services Cloud pour les projets IOT.