|
| 1 | +# Presentation de l'application |
| 2 | + |
| 3 | +Voici une succincte description de l’application, point de départ du projet DevOps. |
| 4 | + |
| 5 | +L'application est actuellement une implémentation de FastAPI, conçue pour une exécution dans un environnement Dockerisé. |
| 6 | + |
| 7 | +Elle utilise Traefik comme reverse proxy et gestionnaire de certificats SSL, ce qui renforce la sécurité des échanges de données. |
| 8 | + |
| 9 | +Les données utilisateur sont gérés à l'aide d'une base de données PostgreSQL assurant fiabilité et performance. |
| 10 | + |
| 11 | +Cette approche centralisée facilite la gestion et le déploiement sur une seule machine ou serveur. |
| 12 | + |
| 13 | + |
| 14 | +## Présentation des composants de l'application |
| 15 | + |
| 16 | +On peut décrire les différents composants comme suit: |
| 17 | + |
| 18 | +### FastAPI |
| 19 | + |
| 20 | +FastAPI est un framework web moderne et réputé, conçu pour la création d'APIs avec Python, qui offre des performances élevées et une écriture de code facile et intuitive. |
| 21 | + |
| 22 | +La validation des données et la sérialisation sont automatiquement gérées, réduisant ainsi le travail manuel et les risques d'erreur. |
| 23 | + |
| 24 | +FastAPI supporte la programmation asynchrone, permettant la gestion efficace de requêtes simultanées, ce qui est particulièrement utile pour les opérations d'entrée/sortie ou pour les services qui doivent gérer de nombreuses connexions simultanément. |
| 25 | + |
| 26 | + |
| 27 | +### Docker |
| 28 | + |
| 29 | +Docker, un outil qui permet de 'containeriser' l'application pour un déploiement et une gestion simplifiés. |
| 30 | + |
| 31 | +Le code est structuré et pensée pour un déploiement via Docker. |
| 32 | + |
| 33 | + |
| 34 | +### Traefik |
| 35 | + |
| 36 | +Traefik joue un double rôle. |
| 37 | + |
| 38 | +D'une part, il agit comme un reverse proxy gèrant le routage et redirigeant les requêtes vers les bons services de l'application. |
| 39 | + |
| 40 | +D'autre part, il sert de gestionnaire de certificats SSL, une fonctionnalité essentielle pour sécuriser les communications, les échanges de données sur Internet. |
| 41 | + |
| 42 | +Cette intégration montre un souci de sécurisation et d'optimisation du trafic réseau. |
| 43 | + |
| 44 | + |
| 45 | +### PostgreSQL |
| 46 | + |
| 47 | +PostgrèsSQL est chargé de gérer, stocker les données utilisateur. |
| 48 | +Il est reconnu pour sa robustesse, sa fiabilité, sa stabilité, sa performance et sa conformité aux standards SQL. |
| 49 | + |
| 50 | +L'ensemble du code montre une cohérence dans le choix des technologies qui s’intègrent parfaitement ensemble. |
| 51 | + |
| 52 | + |
| 53 | +## Description de l'architecture monolithique |
| 54 | + |
| 55 | +Dans son format d’origine, l’application est structurée en tant que système monolithique. |
| 56 | +Ceci signifie que toutes ses composantes fonctionnelles - base de données, traitement des données, interface utilisateur - sont intégrées dans une unique répertoire de code source. |
| 57 | +Cette architecture centralisée facilite la gestion et le déploiement. |
| 58 | + |
| 59 | + |
| 60 | +### Avantages |
| 61 | + |
| 62 | +Cette architecture offre des avantages initiaux tels que la simplicité de développement et de déploiement. |
| 63 | +En effet, en concentrant toutes les fonctions en un seul point, la coordination entre différents composants est intrinsèquement simplifiée, réduisant ainsi la complexité de communication entre divers modules. |
| 64 | + |
| 65 | + |
| 66 | +### Limites de l'architecture monolithique* |
| 67 | + |
| 68 | +Toutefois, cette architecture présente des limites, notamment en termes de scalabilité et de flexibilité. Avec l'évolution des besoins et des fonctionnalités, le système monolithique peut devenir lourd et difficile à maintenir. Chaque mise à jour ou modification nécessite le redéploiement de l'intégralité de l'application, ce qui augmente les risques d'erreurs et de temps d'arrêt. En outre, les performances peuvent être affectées par la taille croissante de l'application. Le système monolithique devient moins réactif et plus difficile à optimiser. La sécurité peut également devenir une préoccupation, car une faille dans un composant pourrait potentiellement compromettre l'ensemble du système. |
| 69 | + |
| 70 | + |
| 71 | +## L'évolution vers le cloud et l'architecture micro-services |
| 72 | + |
| 73 | +### Transition, réflexion sur l'Évolution vers le Cloud et l'architecture micro-services |
| 74 | + |
| 75 | +Face à ces défis, nous allons repenser l'architecture de l'application pour mieux répondre aux exigences modernes de scalabilité, de performance et de sécurité. |
| 76 | + |
| 77 | +C'est dans ce contexte que l'idée de la faire évoluer vers une architecture orientée micro-services, déployée dans un environnement cloud, que notre projet prendra forme. |
| 78 | + |
| 79 | + |
| 80 | +### Objectif |
| 81 | + |
| 82 | +Le projet s'orientera donc vers une migration de l'application vers le cloud, en utilisant les méthodes DevOps apprises en cours. |
| 83 | + |
| 84 | +Bien que la structure monolithique actuelle soit maintenue, l'objectif est d'optimiser son déploiement et sa gestion dans le cloud, en exploitant les avantages des technologies et pratiques DevOps, sans nécessairement procéder à une restructuration complète ou au développement de nouvelles fonctionnalités, compte tenu des contraintes de temps. |
0 commit comments