Ingénierie cloud et DevOps, de la migration au FinOps

Une application isolée, à l'architecture propre, peut bouger en quelques semaines. Un parc complet est un programme qui se compte en trimestres, et la réponse honnête dépend du nombre de charges de travail, de la part du code qui présuppose l'environnement actuel, et de ce qui peut migrer tel quel plutôt que d'être repris. Nous commençons par un état des lieux qui classe chaque charge de travail et vous remet un plan séquencé, avec un modèle de coûts.

Dans cet ordre : rendre la dépense visible et attribuée, supprimer ce que rien n'utilise, redimensionner ce qui est surdimensionné, puis vous engager sur de la capacité réservée ou un plan d'économies pour la base stable. Les changements d'architecture — hiérarchisation du stockage, mise à l'échelle automatique, bascule des traitements par lots sur de la capacité spot — viennent en dernier, parce qu'ils portent le plus de risque pour le gain obtenu. La plupart des parcs trouvent des économies à deux chiffres avant d'arriver à cette étape.

Souvent non. Si vous exploitez une poignée de services, une plateforme de conteneurs managée ou du serverless coûtera moins cher à exploiter et demandera bien moins d'expertise pour tourner sans risque. Kubernetes devient rentable quand de nombreuses équipes déploient de nombreux services et qu'il faut une plateforme cohérente en dessous. Nous vous dirons de quel côté de cette ligne vous vous situez, y compris quand la réponse nous coûte du travail.

En général celui que votre équipe connaît déjà, sauf si une exigence précise l'emporte : résidence des données dans une juridiction donnée, un service managé sans équivalent ailleurs, ou des accords d'entreprise existants. Le multicloud par défaut coûte cher et justifie rarement sa complexité ; le multicloud pour une raison énoncée, c'est très bien.