migration cloud : réussir son analyse de TCO

8 February 2019

On entend toujours dire que le cloud permet d'économiser 20 à 30% des coûts d'une infrastructure. Cette promesse d'économie est d'ailleurs souvent le point de départ d'une migration, et c'est pourquoi la première mesure à prendre, c'est d'effectuer une analyse de TCO en bonne et due forme pour valider la pertinence économique du projet. Bien-sûr, on peut utiliser les outils mis à disposition par les fournisseurs de service (je vous mets les liens en bas de page) et obtenir une première estimation des économies envisageables, mais même en ajustant les hypothèses de travail des calculateurs, l'estimation n'est pas très précise. Et avec la hauteur des coûts en Suisse, on se doute bien qu'il y a des économies à faire...mais lesquelles ? Voici donc quelques conseils pour réussir votre analyse de TCO en prenant en compte le contexte de votre entreprise, ses actifs IT, leur ancienneté, et ses besoins actuels et futurs.

Collectez vos coûts

Quels sont les coûts à prendre en compte ?

A l'évidence, il faut tenir compte de tous les coûts :
  • les coûts d'infrastructure, bien-sûr : serveurs, stockage (sans oublier les infrastructures de backup : lecteurs, robots, bandes...), réseau, auxquelles on ajoutera les équipements de sécurité et de résilience (load balancers),
  • la bande passante : l'accès Internet, les liens vers les sites distants, l'accès Internet des sites distants,
  • les coûts de licences qui seront à renouveler : OS et applications,
  • les coûts de maintenance : souvent autour des 20% des prix des équipements, donc à ne surtout pas négliger !
  • et bien-sûr les coûts des infrastructures data center :
    • les coûts de surface,
    • les coûts d'énergie, qui sont bien souvent le 1er poste de dépense d'un DC,
    • les coûts de refroidissement si votre hébergeur vous les facture à part (rare en Suisse, je ne l'ai jamais vu),
    • et les services additionnels qui peuvent être facturés dont vous n'aurez plus besoin dans le cloud : remote hands et service management typiquement,
  • et enfin, les coûts de main d'oeuvre IT : administrateurs systèmes, stockage et backups, réseau et sécurité. Pensez à inclure les coûts de main d'oeuvre externe (intégrateurs, SSII) si vous y faites appel de façon récurrente.

Créez des catégories pour ventiler vos coûts. Gardez-les peu nombreuses et restez simple : elles doivent permettre la comparaison avec les coûts dans le cloud. Le mieux est d'utiliser la dénomination des briques de base de l'infrastructure :

  • serveurs physiques,
  • stockage et backup,
  • réseau et sécurité,
  • travail IT,
  • frais généraux.
Les critères de ventilation des coûts vous appartiennent, mais faites preuve de constance et de rigueur, un mélange des genres pouvant conduire à la remise en cause des résultats de l'analyse. Par exemple, en ce qui me concerne, je divise encore le réseau en ToR(les équipements dans les racks auxquels les serveurs sont connectés) et en Core / agrégation. Les équipements ToR sont inclus dans les coûts serveurs ainsi que les racks et PDUs, et les switches de core et d'agrégation sont inclus dans les coûts du réseau. Votre répartition des équipements peut varier, ce n'est pas grave, mais il faut être rigoureux et consistant dans l'attribution des coûts.

Par soucis de simplification, ne vous encombrez pas des licences qui resteront à l'identique entre les environnements "on prem" (sur site) et l'environnement cloud. C'est un coût constant des deux côtés de l'équation, il n'aura donc pas d'influence. Même chose pour les coûts des administrateurs bases de données par exemple : il y a de grandes chances que ce coût continuera à exister avec une infrastructure dans le cloud.

Prenez garde aussi à bien définir le périmètre de la migration en identifiant :
  • les sites concernés : un ou plusieurs sites, un ou plusieurs data centers,
  • les infrastructures concernées : les infrastructures dont la migration n’est pas souhaitable pour des raisons techniques (migration impossible, susceptibilité à la latence, etc), légales (souveraineté des données, contraintes légales) ou organisationnelles (disponibilité de ressources spécialisées) sont identifiées et exclues du périmètre.
Le périmètre pourra varier par la suite, mais le définir même de façon provisoire permet de baliser le terrain à couvrir lors de cette première étude.

De quelles informations avez-vous besoin, et où les chercher ?

La question peut sembler inutile, mais lorsqu'il s'agit de collecter de l'information sur d'anciens équipements, les choses peuvent vite tourner à la quête archéologique ...Voici donc quelques pistes pour trouver les informations dont vous avez besoin.

Pour l'inventaire du matériel, si votre département IT suit les bonnes pratiques "ITIL", vous avez probablement une CMDB quelque part. C'est un bon point de départ, l'inventaire du matériel s'y trouvant certainement. Si vous avez encore plus de chance, votre IT disposera d'outils d'inventaire automatisés pour le matériel qui vous fourniront sans effort un inventaire à jour. Dans tous les cas, je recommande fortement une visite dans le data center, liste en main, pour vérifier l'inventaire et pointer chaque équipement. Cela évite les mauvaises surprises, les documentations n'étant pas toujours à jour...

Pour les contrats de maintenance et de support divers et variés, il faudra aller voir votre service des achats ou la comptabilité pour obtenir les factures. Profitez-en pour exhumer les factures des équipements inventoriés et collecter les dates et prix d'achat si ces informations ne figurent pas dans votre outil d'inventaire (pour les dates, l'année suffira !).

Et bien-sûr, pour les coûts du travail IT, il faudra vous tourner vers votre service des ressources humaines. Attention, les salaires à utiliser doivent être les salaires brut, incluant toutes les charges sociales et tous les avantages dont bénéficient les collaborateurs. Pour conserver la confidentialité des salaires, utilisez des moyennes salariales que pourront calculer pour vous les ressources humaines.

Ne négligez pas la collecte des données : sa qualité va déterminer la précision de l'estimation. Comme disent nos amis américains : garbage in, garbage out...

Comment traiter les équipements totalement dépréciés dans votre analyse de coûts ?

Lors de l’achat d’un équipement, le cash est converti en actif, puis l’actif est déprécié, de façon à répartir son coût sur sa durée de vie utile. Pour les équipements informatiques, la période de dépréciation est habituellement de 3 ans.

Ainsi, si un serveur vaut 100 à l’achat, avec une dépréciation linéaire de 30% par an, il faut compter une dépréciation de 33 par année sur 3 ans. La partie de la valeur qui est dépréciée constitue le coût.
Le corollaire de cette manoeuvre comptable est qu'un équipement âgé de plus de 3 ans voit son coût ramené à 0. Bien-sûr, il peut avoir d'autres coûts qui lui sont rattachés et qui eux ne sont pas à 0 : contrats de maintenance, administration, électricité...

Comment traiter les équipements à venir ?

Hé oui ! Notre analyse de coûts porte sur 3 ans: l'année en cours et les deux années suivantes. Inévitablement, des investissements sont à prévoir sur cette période : ajout, remplacement ou extension de matériel auront lieu à n'en pas douter. Mais comment en tenir compte ? C'est bien simple : un équipement qui n'est pas encore acheté a évidemment une valeur de 0. Lors de son achat, il va commencer à se déprécier et le montant de la dépréciation devra être porté dans le tableau de coût avec les autres équipements. Je vous ai préparé un exemple ci-dessous :

TCO_exemple

On voit ici :

  • un serveur acheté en 2016. Nous sommes en 2019, sa période de dépréciation est terminée et sa valeur est tombée à zéro,
  • un serveur acheté en 2017. Il lui reste une année de dépréciation avant que sa valeur ne tombe à 0. Sur notre période d'analyse, nous avons donc un coût en 2019 puis plus de coûts (valeur 0) en 2020 et 2021 (années N+1 et N+2),
  • idem pour le serveur acheté en 2018 qui aura encore 2 années de dépréciation,
  • puis un serveur acheté cette année (peut-être pas encore là, mais dans le courant de l'année) qui a 3 périodes de dépréciation en commençant dès cette année,
  • et les machines qui seront achetées en 2020 et 2021 avec respectivement deux et une dépréciation sur la période de notre étude sur 3 ans.

Estimez les coûts dans le cloud

Les coûts des machines virtuelles

Ca y est, nous avons une idée de ce que nous coûtent nos infrastructures en propre. Il est temps à présent d'estimer ce que coûteraient des infrastructures similaires dans le cloud (le mot similaire ici est important, j'aurai l'occasion d'y revenir par la suite).

Pour cela, nous avons besoin d'une liste des serveurs virtuels, cette fois-ci : vos serveurs physiques hébergent des serveurs virtuels et ce sont eux qui seront reproduits dans le cloud. Allez, hop ! Nouvel inventaire. Mais celui-là devrait être facile et rapide à obtenir : vos administrateurs systèmes doivent être capables de vous le fournir en quelques clics, avec la liste des machines et leurs caractéristiques techniques : nombre de processeurs (vCPU), capacité mémoire (vRAM) et espace disque dédié. Ajoutez-y les quelques machines "legacy" qui n'ont pas encore été virtualisées et vous aurez une idée assez précise de l'environnement à reproduire dans le cloud.

Groupez vos machines virtuelles selon leurs caractéristiques : vCPU, vRAM et faites-les correspondre aux instances proposées par votre fournisseur cloud préféré (il faut bien en choisir un pour l'analyse) ou mieux faites l'exercice avec plusieurs fournisseurs de façon à obtenir une analyse plus précise encore.
Chaque instance-type aura un coût associé, faites l'analyse sur 3 ans en prenant des instances réservées sur 3 ans.

Les coûts de stockage

De la même façon, il faut faire l'inventaire des besoins de stockage pour pouvoir les reproduire dans le cloud. Vous aurez besoin à minima d'un stockage dynamique, utilisé pour des fichiers qui changent rapidement (ce sont vos SAN actuels qui jouent ce rôle dans votre data center) et d'un stockage d'archivage, utilisé pour les fichiers peu dynamiques ou l'archivage longue durée. Dans un souci de simplification de la démarche d'estimation, la tentation peut être grande de mettre tout vos besoins de stockage dans la catégorie générale, celle du stockage dynamique, mais cependant il faut bien penser à tenir compte des différents tiers de stockage pour ne pas gonfler artificiellement les coûts : le stockage d'archivage est bien meilleur marché que le stockage à court terme ! Et vous aurez même des options intermédiaires qui vous permettront de diminuer encore davantage votre facture.

Et en dehors de ces 2 grandes catégories de stockage, il y a encore des variations dans le format du stockage (blob, bloc, fichiers...) dont il faudra tenir compte.

Enfin, il est à noter que dans le cloud, le provisionnement du stockage se fait un peu différemment que dans un data center, et certainement un peu plus facilement. En effet, vos ingénieurs doivent tenir compte de tout un ensemble de considérations qui disparaissent dans le cloud : capacité formatée, capacité dédiée à la redondance (mise en RAID pour les spécialistes), capacité corrigée par les mécanismes de déduplication, capacité supplémentaire pour les snapshots.... Au final, la capacité utilede vos systèmes de stockage est en gros un peu plus de la moitié de la capacité achetée. Donc, la logique va ainsi : si vous avez besoin de 100 de stockage, vous devez acheter près de 200. Ouch. Dans le cloud, les choses sont différentes : si ces éléments existent toujours (formatage, redondance, etc...), ils sont la charge du fournisseur de service et vous n'avez plus à vous en soucier ! Si vous avez besoin de 100 de stockage, vous achetez....100. Simple, non ?

Les coûts de réseau

Si la plupart des infrastructures réseau sont gratuites dans le cloud, certains services sont payants, à savoir :

  • les connexions privées entre vos locaux et le fournisseur de service : vous pouvez, si vous le souhaitez (ou si le besoin de performance l'impose) bénéficier d'une connexion directe et privée vers le cloud,
  • les transferts de données : certains flux de trafic engendrent une facturation qui peut, suivant les usages de vos services, ne pas être anodine et qu'il faut donc estimer.

Les calculateurs des fournisseurs de service sont votre seule option pour estimer ces coûts.

Les coûts de migration

Enfin, dernière grande catégorie de coûts : les coûts de migration. Ces coûts sont très difficiles à estimer, le mieux est donc de modéliser l'effort de migration en fonction des caractéristiques des machines et applications : complexité de l'installation actuelle, type d'OS, virtualisée ou pas, présence de dépendances (bases de données, notamment), présence de redondances, etc... L'effort de migration sera quantifié en heures-hommes et un taux horaire moyen, dérivé des moyennes salariales (cf ci-dessus) sera appliqué pour le calcul du coût de migration.

Les coûts de main d'oeuvre IT

Une large part des activités aujourd'hui menées par vos équipes IT sera prise en charge par le prestataire de service cloud : maintenance des systèmes, mises à jour, extension, remplacement des appareils en fin de vie, etc... On considère habituellement que ces activités représentent entre 30 et 40% du temps des équipes IT (le reste étant consommé par la correction des problèmes posés lors de ces maintenance et par la mise en place de nouveaux systèmes et applications, qui représente la valeur que vous attendez de votre IT pour ...moins de 30% de son temps !). Oui, des postes sont clairement menacés. A vous de voir si des ressources doivent disparaître ou si elles peuvent être réaffectées à des tâches plus productives. Sont concernés : les administrateurs systèmes, réseau et sécurité, et les techniciens de data center si vous en avez. Attention, il ne s'agit pas de se séparer de ces équipes : des compétences doivent rester, qui sinon s'occupera de vos infrastructures dans le cloud ? Mais leur nombre va certainement diminuer, et c'est peut-être l'occasion de renforcer certaines équipes avec ces compétences.

Naturellement, en période de migration, vous pourriez avoir à faire appel à des ressources externes : consultants, sociétés de services, chefs de projet, etc...dont il faut tenir compte.

Comment affiner son analyse de TCO ?

Vous l'aurez remarqué, cette analyse de TCO repose d'un côté sur une estimation assez précise des coûts existants, et de l'autre sur une estimation encore assez grossière des coûts dans le cloud. Cette apparente dissymétrie est tout à fait acceptable pour une prise de décision. Cependant, vous pourriez avoir besoin d'une estimation plus fine pour votre solidifier votre business case. Mais comment s'y prendre ? C'est ici que nous revenons sur le mot-clef que j'ai souligné dans la section précédente : nous avons estimé le coût d'infrastructures similairesà celles qui sont actuellement dans votre data center. Or, une migration dans le cloud ne sert pas à faire une infrastructure similaire, ce serait passer à côté des apports et des avantages du cloud et ce serait bien dommage.

Voyons donc rapidement ce que sont ces avantages :

  • l'optimisation : le cloud permet d'ajuster les ressources au plus près du besoin, et d'étendre les ressources à la demande. Ainsi, plus besoin de sur-dimensionner (et donc de sur-payer) les ressources,
  • la mise en redondance : dans un data center classique, mettre une ressource en redondance signifie doubler le matériel, idéalement sur 2 sites distants, ce qui augmente considérablement les coûts. Dans le cloud, les solutions pour assurer la résilience d'un service sont multiples et souvent très bon marché,
  • l'utilisation de services managés : les fournisseurs cloud mettent à disposition des services managés tels que les bases de données qui permettent de profiter à meilleur prix de fonctionnalités parfois coûteuses, souvent difficiles et complexes à mettre en oeuvre pour des prix tout à fait intéressants,
  • l'automatisation : la clef des opérations dans un monde cloud est l'automatisation des tâches qui permet de réduire encore les coûts,
  • l'adaptation des effectifs : les effectifs peuvent être ré-affectés à des tâches à plus forte valeur ajoutée et au développement de l'innovation au sein de l'entreprise.

Exploiter ces avantages exige souvent une ré-architecturation des services applicatifs et je recommande, sauf cas simple, de mener cette refonte dans un deuxième temps, lorsque les applications tournent dans le cloud et que les équipes sont rodées aux changements dans les modes opératoires, de façon à ne pas ajouter du changement au changement. Cependant, il est tout à fait évident que cette refonte a lieu dans la période de 3 ans de notre analyse de TCO. Ainsi, on doit voir les coûts diminuer d'une année sur l'autre.

Pour finir, un réservoir d'économie à ne pas négliger est la disparition de vos sites de DR (Disaster Recovery) qui n'auront plus lieu d'être lorsque les applications auront toutes été mises en résilience dans le cloud. Nous avons donc à la fois un phénomène de baisse de coûts et un phénomène d'augmentation de la disponibilité générale des applications. Coup double !

Conclusion

Avec l'analyse plus poussée, nous avons quitté le territoire stricte de l'analyse de TCO pour rentrer sur le territoire du ROI. Alors que le TCO compare les coûts à un temps t ou sur une période (ici, 3 ans), l'analyse de ROI se concentre sur :
  • le phasage des coûts selon les étapes de migration (y compris les coûts de migration et d'accompagnement),
  • l'optimisation des coûts d'infrastrucure (le recours à des services managés, à des instances réservées, l'ajustement de la capacité aux besoins, etc) et humains (réduction de l’équipe, affectation à d’autres tâches, gains de productivité),
  • l’optimisation des architectures (mise en résilience, mise en conformité)
pour déterminer le moment où l'effort payera et la hauteur des économies envisagées.

Cependant, ces analyses de TCO et de ROI, si fines soient-elles, ne tiennent pas compte des apports intangibles du cloud et de son extension, le mouvement devOps dont les bénéfices ne se mesurent pas (directement) en réduction de coûts. Je vous laisse avec les chiffres du livre Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations( Forsgren PhD, IT Revolution Press) qui vont peut-être vous donner envie de...vous passer de l'analyse de TCO !

Selon Accelerate, les entreprises qui ont mis en place les méthodes devOps et les mécanismes Cloud, en moyenne (toutes tailles, industries et géographies confondues ) :
  • déploient du code 46 fois plus fréquemment,
  • ont un temps entre le "commit" et le déploiement du code 440 fois plus court,
  • ont un temps de reprise après incident 170 fois plus rapide,
  • ont un taux d'échec des changements IT 5 fois plus faible,
que les autres entreprises.

Je vous rappelle que si vous avez besoin d'aide pour effectuer votre analyse de TCO ou pour migrer dans le cloud, je me tiens à votre entière disposition pour vous assister.

Les calculateurs de TCO des principaux fournisseurs de services cloud :