Application web en (micro)services / automatisation de tâches (cron) / répartition des rôles

Bonjour,

Je participe actuellement au développement d'une solution logicielle en C# qui est constituée de plusieurs applications web utilisant une seule et unique base de données.

Il y a actuellement
- une application web pour le Front-Office,
- une application web pour le Back-End,
- une application webservice qui s'occupe de l'édition de documents,
- une application webservice qui effectue des calculs
- une application web pour le paramétrage

Je développe pour ma part une application web supplémentaire dédiée aux emails :
- réception par les autres applications d'emails à envoyer,
- récupération des emails d'une boite imap et stockage en BDD

Toutes ces applications utilisent des classes (objets métier) qui sont centralisées et communiquent entre elles par webservice.

J'ai besoin d'automatiser un certain nombre de tâches :
- envoyer les emails qui sont dans ma file d'attente,
- chercher régulièrement les emails non-lus de la boite imap pour les importer dans la solution

Mais nous aurons également à terme besoin de générer des reportings de manière quotidienne et tout autre tâche nécessitant d'être exécutée de manière récurrente.

Avant de participer à ce projet, je développais des applications indépendantes qui embarquaient leurs propres bases de données et qui communiquaient entre elles en webservice. J'avais développé un système de planification de tâches (un genre de "Cron" maison) avec un certain nombre de tables pour gérer la périodicité, l'activation ou non d'une tâche etc. Chaque application avait donc une copie d'un jeu de méthodes et de tables pour pouvoir automatiser ses actions.

Avec cette nouvelle architecture se pose la question de savoir comment intégrer l'automatisation de tâches.

Je vois actuellement plusieurs possibilités :

Chacun pour soi / Planificateur de tâches embarqué
Chaque application devant effectuer des traitements embarque d'une manière ou d'une autre ce système de planification de tâches (soit développement interne soit utilisation d'une solution clé en main type Quartz.net). Vestige de mon ancien monde mais au moins la base de données est commune dans cette architecture.
Avantages
- Possibilité d'adapter finement chaque système à l'application : la logique métier peut effectivement modifier la périodicité d’une tâche.

Inconvénients
- Duplication du système de planification sur chaque application
- Besoin de se connecter à chaque application pour gérer les tâches

Chacun pour soi / Planificateur de tâches Windows
Même principe que précédemment mais c'est le planificateur de tâches Windows qui lance des traitements sur l'application
Avantages
- Inutile de réinventer la roue, Windows sait exécuter des tâches à intervalles réguliers
- Simplicité de mise en œuvre.

Inconvénients
- Impossible à paramétrer depuis une interface web, il faut se connecter à la machine pour lister/modifier la programmation des tâches

Une application dédiée commandant les autres
Développement d'une application qui ne fait que ça : gérer la planification (date et heure d’exécution) et qui ordonne aux autres applications d'effectuer un traitement spécifique. Communication par webservice ou message type AMQP.
Avantages
- La gestion des tâches n'est effectuée qu'à un seul endroit
- La philosophie micro service est respectée : cette application se contente de gérer un planning et de commander l’exécution de tâches aux autres.

Inconvénients
- Nécessité de développer une interface pour que les applications distantes réagissent aux demandes du planificateur de tâches
- Dans le cas de traitements lourds (reportings avec post-traitement), c'est l'application distante qui travaille et ça n'apporte aucune plus-value.

Une application dédiée faisant les traitements des autres
Développement d'une application qui gère la planification des actions à effectuer comme précédemment mais dont le traitement est effectué en local
Avantages
- La gestion des tâches n'est effectuée qu'à un seul endroit
- Le traitement ne nécessite pas de ressources de l'application distante

Inconvénients
- La philosophie micro service ne semble plus vraiment respectée : les méthodes spécifiques d'une application distante devront être copiées/réadaptées avec l'import des librairies/plugin requis


Voyez-vous d'autres solutions et/ou d'autres avantages/inconvénients à chaque possibilité ?

Avez-vous dans vos systèmes des besoins similaires et comment les gérer-vous ?

Merci