Flower Runtime Comparison

Les applications Flower peuvent être exécutées avec les deux simulation ou deployment runtimes. Passer de l’un à l’autre ne nécessite qu’une simple spécification du type de federation lors de l’exécution de la commande flwr run via le Flower CLI.

Même si les applications Flower peuvent être exécutées à la fois en simulation et en déploiement sans modifier leur code, il existe des différences dans la façon dont elles sont exécutées en fonction du runtime. La table suivante résume les caractéristiques clés qui diffèrent lors de l’exécution d’une application Flower dans une fédération Flower avec le Simulation Runtime par rapport à un autre utilisant le Deployment Runtime.

Dimension	Simulation Runtime	Deployment Runtime
Étape de Cycle de Vie	Idéal pour la prototypage rapide, la validation d’algorithmes, la recherche, le débogage et l’expérimentation.	Déployez des cas d’utilisation validés en production, des applications réelles du monde réel avec protection de la vie privée.
Environment	Local ou distant, un seul nœud ou plusieurs nœuds, contrôlé.	Distribué, distant.
Data	Partitions de données simulées, jeux de données publics ou privés ou générés artificiellement - un excellent cas d’utilisation pour Flower Datasets.	Données client réelles, résidant dans des bases de données locales ou des systèmes de fichiers.
Backend	Plusieurs processus Python coordonnés à l’aide de Ray.	Plusieurs processus indépendants ou sous-processus exécutés en coordination avec SuperLink et SuperNodes.
Mode d’exécution	Exécution par multiprocessing où chaque processus simule un client distinct.	Mode d’exécution parallèle sur un réseau de machines physiques/ordinateurs ou environnement de calcul.
Communication	Communication en mémoire.	gRPC avec chiffrement TLS.
Infrastructure côté serveur	Dans le flux de travail CLI standard local, flwr run soumet l’exécution à un SuperLink géré local, qui coordonne ensuite le Simulation Runtime et les workers agissant comme des SuperNodes simulés. Le Simulation Runtime lui-même peut toujours être démarré avec ou sans `SuperLink.	Le SuperLink attend que les SuperNodes se connectent. Interface utilisateur avec SuperLink à l’aide de Flower CLI.
Exécution d’application côté serveur	Un processus ServerApp est initialisé à l’intérieur d’un environnement contrôlé et communique en mémoire avec des travailleurs.	ServerApp process or subprocess s’exécute indépendamment du SuperLink et communique avec lui par le biais de gRPC via la classe ServerAppIO API.
Infrastructure côté client	Aucune infrastructure côté client gérée par l’utilisateur n’est requise. Dans les flux de travail CLI locaux, le SuperLink et le Simulation Runtime restent auto-contenus.	Les SuperNodes se connectent au SuperLink via gRPC avec chiffrement TLS à l’aide de l’API Fleet. L’authentification des nœuds peut être activée.
Exécution d’application côté client	Chaque processus exécute un ClientApp à la demande. Ils peuvent exécuter plusieurs instances de la même ClientApp pour simuler des quantités importantes de clients. Les ClientApps sont sans état.	Initialisé comme un ClientApp process or subprocess, il s’exécute indépendamment du SuperNode et communique avec lui par le biais de gRPC via la classe ClientAppIo API. Les ClientApps sont sans état.