Le produit peut rester le même

Une application peut commencer sur un PaaS ou un BaaS parce que ces plateformes prennent en charge une partie de l’infrastructure. Le produit avance ; les choix de réseau, de machines, de stockage et d’exploitation restent en arrière-plan.

Passer à son propre compte IaaS ne devrait pas obliger à réécrire l’application. Le travail consiste à rendre visibles les ressources qui la font tourner, puis à les décrire et à les déployer dans le compte cloud choisi.

Ce qui doit devenir explicite

Il faut pouvoir distinguer l’application, ses bases, ses fichiers, les machines qui exécutent les services et les règles qui les relient. Le réseau compte aussi : l’application peut être exposée, tandis que les services de données restent privés.

La configuration doit pouvoir être relue. Les coûts doivent être estimés avant le déploiement, avec leurs hypothèses. Les identifiants cloud restent sous le contrôle de l’équipe.

Le rôle de bige-ops

bige-ops est une application desktop gratuite qui aide à composer une stack, comparer des scénarios, générer la configuration d’infrastructure et lancer les opérations prises en charge depuis l’app. Elle vise à rendre le parcours praticable sans demander à l’équipe de monter d’abord une chaîne DevOps complète.

L’application s’utilise sans IA. Les fonctions d’IA restent optionnelles et utilisent les clés configurées par l’équipe.

Un changement d’infrastructure à examiner

Une migration se prépare à partir de l’application réelle, de ses dépendances, des données à conserver et des contraintes du cloud cible. Une estimation n’est pas une facture, et un plan généré doit être relu avant son application.

La bonne première étape est souvent de simuler une stack représentative, puis de vérifier ce que bige-ops prend effectivement en charge pour le fournisseur et les ressources visés.

Voir les simulations et les architectures →

À lire aussi