Console FinOps MultiCloud: Difference between revisions
No edit summary |
No edit summary |
||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
=Titre du projet: Console FinOps MultiCloud= |
|||
⚫ | |||
Polytech Grenoble INFO5 Proposition Projet S10 2023-2024 |
|||
⚫ | |||
Porteurs : Chems-Eddine Hadiby chemsseddine.hadiby gmail.com https://www.linkedin.com/in/chemss-eddine-hadiby, Didier Donsez |
|||
⚫ | |||
==Description du contexte (10 lignes minimum)== |
|||
Face à l’essor du cloud natif, de plus en plus d’entreprises optent pour des solutions/stratégies multicloud. Une stratégie multicloud est l’utilisation d’au moins deux services Cloud Computing d’un nombre quelconque de fournisseurs Cloud. Cela permet aux entreprises d’éviter la dépendance vis-à-vis d’un seul fournisseur (Vendor Lock-in). Elles y voient un moyen d’augmenter leur flexibilité, leur résilience et leur efficacité budgétaire. Toutefois, cette multiplicité de plateformes complique la mesure des indicateurs financiers, surtout pour les profils non techniques, tels que les chefs de projet, les product owners ou les directeurs financiers. |
|||
Ces parties prenantes ont besoin de comprendre l’utilisation des ressources pour prendre des décisions éclairées sur les investissements et les coûts. Cependant, la gouvernance des rôles et des accès dans un environnement multicloud peut être complexe et difficile à gérer. |
|||
Cela peut entraîner des problèmes de sécurité, de conformité et d’efficacité opérationnelle. |
|||
Par conséquent, il faut mettre en place des outils et des processus robustes pour gérer efficacement les environnements multicloud, tout en permettant une visualisation claire et compréhensible des métriques financières pour toutes les parties prenantes. C’est le défi que ce projet vise à relever. |
|||
==Objectif(s) du projet== |
|||
Le but de ce projet est de concevoir une console [[FinOps]] destinée à un utilisateur ou une organisation (chef de projet, propriétaire de produit, directeur financier) qui utilise diverses solutions Cloud, qu’elles soient publiques ou privées. |
|||
⚫ | |||
La console FinOps offrira aux utilisateurs des prévisions de coûts (mensuels/annuels) avec des agrégations au niveau du projet, du département et de l’organisation. |
|||
==Travail attendu (5 lignes minimum)== |
|||
Le travail attendu consistera à développer un produit minimum viable (MVP) qui inclura les éléments suivants : |
|||
* L’exploitation d’au moins 2 fournisseurs cloud, comme Azure, en lien avec votre expérience précédente lors du projet Ecom. D’autres candidats sont Google CP, AWS, le français OVH |
|||
* Une API REST qui permet de récupérer les données et les métriques FinOps. |
|||
* Une interface de type BI (Business Intelligence) de votre choix, par exemple, un JHipster généré, Grafana, Tableau, PowerBI.. etc. |
|||
* Le service doit être multi-tenant (un tenant est une entreprise/une business unit d’une entreprise) et multi-projet (plusieurs projets finops par tenant). Les utilisateurs dans un tenant sont soit des administrateurs, soit des visualisateurs (qui ne peuvent modifier ou ajouter un projet finops) |
|||
Une importance particulière doit être accordée à la documentation de votre travail, cela comprend la documentation du code, l’explication des choix de conception, les diagrammes d’architecture pour votre mécanisme, les instructions d’installation et d’utilisation, et toute autre information qui pourrait faciliter la compréhension et l’extension de votre projet par d’autres équipes. |
|||
Au-delà des exigences de base, il existe plusieurs façons d’améliorer votre projet. Considérez les améliorations suivantes : |
|||
* Intégrer un provider cloud supplémentaire à l’API. |
|||
* Développer une interface utilisateur ergonomique, adaptée aux utilisateurs non-IT. |
|||
* Automatiser l’infrastructure de ce projet (Infrastructure as Code) en utilisant Terraform. |
|||
* Renforcer la sécurité du processus de récupération des données, par exemple la sécurisation de l’API ou en utilisant la Workload Identity Federation ou un autre mécanisme similaire. |
|||
Ces améliorations ne sont pas obligatoires, mais elles seront considérées comme des bonus pour votre travail. |
|||
Une architecture de haut niveau possible du projet : |
|||
==Techniques, outils, technologies, langages et canevas à mettre en œuvre.== |
|||
* Vous pouvez choisir parmi plusieurs plateformes cloud, telles que AWS, GCP, Azure, OVH, Oracle, CloudFlare, Digital Ocean, Heroku, AliBaba, etc. |
|||
* Pour la console (front), vous pouvez utiliser JHipster, Grafana ou Tableau (en utilisant la licence de l’UGA), ou tout autre outil de votre choix. |
|||
* Pour les API, le choix du langage et des technologies est libre. Cependant, l’API devra être documenté avec le formalisme OpenAPI v3 (qui est déjà utilisé pour exposer l’API REST des backends générés avec JHipster). Il est préférable d’opter pour des outils évolutifs, viables et bien documentés, tels que FastApi, Flask, Express.js, Spring Boot, Django, Ruby on Rails, etc. |
|||
==Déplacement à prévoir (en dehors de l’école)== |
|||
Non |
|||
[[Image:Architecture_service_finops.jpg]] |
Latest revision as of 14:57, 25 December 2023
Titre du projet: Console FinOps MultiCloud
Polytech Grenoble INFO5 Proposition Projet S10 2023-2024
Porteurs : Chems-Eddine Hadiby chemsseddine.hadiby gmail.com https://www.linkedin.com/in/chemss-eddine-hadiby, Didier Donsez
L'objectif du projet est de développer un console FinOps pour un utilisateur/une organisation (chef de projet, product owner, directeur financier) utilisant plusieurs solutions Cloud (publics ou privés).
Description du contexte (10 lignes minimum)
Face à l’essor du cloud natif, de plus en plus d’entreprises optent pour des solutions/stratégies multicloud. Une stratégie multicloud est l’utilisation d’au moins deux services Cloud Computing d’un nombre quelconque de fournisseurs Cloud. Cela permet aux entreprises d’éviter la dépendance vis-à-vis d’un seul fournisseur (Vendor Lock-in). Elles y voient un moyen d’augmenter leur flexibilité, leur résilience et leur efficacité budgétaire. Toutefois, cette multiplicité de plateformes complique la mesure des indicateurs financiers, surtout pour les profils non techniques, tels que les chefs de projet, les product owners ou les directeurs financiers.
Ces parties prenantes ont besoin de comprendre l’utilisation des ressources pour prendre des décisions éclairées sur les investissements et les coûts. Cependant, la gouvernance des rôles et des accès dans un environnement multicloud peut être complexe et difficile à gérer.
Cela peut entraîner des problèmes de sécurité, de conformité et d’efficacité opérationnelle.
Par conséquent, il faut mettre en place des outils et des processus robustes pour gérer efficacement les environnements multicloud, tout en permettant une visualisation claire et compréhensible des métriques financières pour toutes les parties prenantes. C’est le défi que ce projet vise à relever.
Objectif(s) du projet
Le but de ce projet est de concevoir une console FinOps destinée à un utilisateur ou une organisation (chef de projet, propriétaire de produit, directeur financier) qui utilise diverses solutions Cloud, qu’elles soient publiques ou privées.
Cette console FinOps repose sur une base de données temporelle qui enregistre les consommations réelles des ressources utilisées par plusieurs fournisseurs cloud, tels que AWS, GCP, Azure, OVH, etc. Ces consommations sont récupérées via les API REST des fournisseurs cloud.
La console FinOps offrira aux utilisateurs des prévisions de coûts (mensuels/annuels) avec des agrégations au niveau du projet, du département et de l’organisation.
Travail attendu (5 lignes minimum)
Le travail attendu consistera à développer un produit minimum viable (MVP) qui inclura les éléments suivants :
- L’exploitation d’au moins 2 fournisseurs cloud, comme Azure, en lien avec votre expérience précédente lors du projet Ecom. D’autres candidats sont Google CP, AWS, le français OVH
- Une API REST qui permet de récupérer les données et les métriques FinOps.
- Une interface de type BI (Business Intelligence) de votre choix, par exemple, un JHipster généré, Grafana, Tableau, PowerBI.. etc.
- Le service doit être multi-tenant (un tenant est une entreprise/une business unit d’une entreprise) et multi-projet (plusieurs projets finops par tenant). Les utilisateurs dans un tenant sont soit des administrateurs, soit des visualisateurs (qui ne peuvent modifier ou ajouter un projet finops)
Une importance particulière doit être accordée à la documentation de votre travail, cela comprend la documentation du code, l’explication des choix de conception, les diagrammes d’architecture pour votre mécanisme, les instructions d’installation et d’utilisation, et toute autre information qui pourrait faciliter la compréhension et l’extension de votre projet par d’autres équipes.
Au-delà des exigences de base, il existe plusieurs façons d’améliorer votre projet. Considérez les améliorations suivantes :
- Intégrer un provider cloud supplémentaire à l’API.
- Développer une interface utilisateur ergonomique, adaptée aux utilisateurs non-IT.
- Automatiser l’infrastructure de ce projet (Infrastructure as Code) en utilisant Terraform.
- Renforcer la sécurité du processus de récupération des données, par exemple la sécurisation de l’API ou en utilisant la Workload Identity Federation ou un autre mécanisme similaire.
Ces améliorations ne sont pas obligatoires, mais elles seront considérées comme des bonus pour votre travail.
Une architecture de haut niveau possible du projet :
Techniques, outils, technologies, langages et canevas à mettre en œuvre.
- Vous pouvez choisir parmi plusieurs plateformes cloud, telles que AWS, GCP, Azure, OVH, Oracle, CloudFlare, Digital Ocean, Heroku, AliBaba, etc.
- Pour la console (front), vous pouvez utiliser JHipster, Grafana ou Tableau (en utilisant la licence de l’UGA), ou tout autre outil de votre choix.
- Pour les API, le choix du langage et des technologies est libre. Cependant, l’API devra être documenté avec le formalisme OpenAPI v3 (qui est déjà utilisé pour exposer l’API REST des backends générés avec JHipster). Il est préférable d’opter pour des outils évolutifs, viables et bien documentés, tels que FastApi, Flask, Express.js, Spring Boot, Django, Ruby on Rails, etc.
Déplacement à prévoir (en dehors de l’école)
Non