Le calcul de TCO d’une base de données

L’un des partenaires de LeMarson a eu la bonne idée de nous soumettre l’idée du calcul de TCO pour une base de données. Sachant que le problème s’est fortement complexifié, avec l’arrivée du Cloud, les modes hybrides de fonctionnement, les bases NoSQL et l’extension du mode relationnel. Tout est devenu plus compliqué et il est très difficile de définir une stratégie unique, tout au plus, pouvons-nous donner quelques bonnes pistes issues de l’expérience acquise, applicables aux bases relationnelles les plus répandues.

Définir le calcul de possession d’une base de données est devenu très complexe dans la mesure où les architectures se sont diversifiées, qu’il faut désormais tenir compte des clusters, de la répartition éventuelle du mode hybride entre un mode « On-Premise » et Cloud et où il n’y a pas deux stratégies de tarification qui se ressemblent.

Ce TCO est un véritable maquis, un labyrinthe d’où l’on a du mal à faire ressortir des valeurs communes sur lesquelles s’appuyer. C’est pourtant ce que nous allons tenter de faire en nous limitant à quelques bases importantes : MySQL, Oracle DB, Maria DB, SQL Server, Azure SQL Database et une base NoSQL à titre d’exemple.

La trame que nous vous proposons est issue des commentaires et expériences de nos contributeurs et ne prétend pas à la « vérité. Il s’agit seulement d’une suggestion, dont nous avons pu vérifier qu’elle n’était pas dénuée de sens.

 

Les architectures d’usage des databases

Trois cas distincts à envisager, selon que :

  • les installations sont locales sur les ressources des utilisateurs, ceux-ci assurant la gestion courante et l'administration technique
  • ·        les databases sont hébergées dans un datacenter, le prestataire pouvant assurer pour le client des services de production et d’administration   
  •      les databases sont hébergées dans le Cloud et là encore, il y aura trois cas de mise en œuvre, qui auront des répercussions sur le calcul du TCO :

o   mode IaaS dédié, c’est-à-dire que le client réserve une machine virtuelle (MV), dans laquelle il installe sa base de données, qu’en général il exploite lui-même et dont il assure la maintenance (ce n’est pas forcément le cas), ce qui revient à transférer la database de ses installations dans le Cloud, autrement dit de faire de l’impartition, comme disent nos amis québecois (hébergement).

o   mode IaaS « compatible », dans lequel c’est le prestataire de Cloud qui crée une instance de base de données dans une MV et garantit la stricte compatibilité avec les versions des bases de données clientes. En particulier pour le langage de requête SQL des bases relationnelles et leur équivalent NoSQL. Dans ce contexte, le prestataire « fait le travail » d’installation, le client pouvant prendre à sa charge la production courante.

o mode IaaS natif, dans lequel le prestataire propose un service de base de données mutualisé, qui n’est pas le même que celui des bases habituelles. Dans ce cas, une infrastructure de base est partagée entre les utilisateurs, qui chacun dispose cependant de sa propre instance. Mais c’est le prestataire qui assure toutes les fonctions techniques.

Tout va dépendre ensuite du nombre d’instances dont le client dispose, car une partie des coûts est mutualisable (partageable), essentiellement la production, l’administration et la formation.

Pour calculer le TCO, il faudra donc envisager éventuellement plusieurs cas de figures :

  • ·         1 instance, 10, 100 pour Maria DB et MySQL
  • ·         1 instance ou 10 pour Oracle DB, Postgré et SQL Server
  • 1 à 5 pour une base NoSQL, type MongoDB (base document) ou Azure Database (applications moins nombreuses)

Le coefficient de mutualisation non plus n’est pas le même, selon les cas de figures. Selon que l’on a affaire à une « petite » base type MySQL ou Maria DB ou à une base plus lourde, comme Oracle DB et SQL Server.

Un autre critère est à prendre en compte, celui de la sensibilité des données et donc de leur sécurité.

Les bases de données ne sont pas égales de ce point de vue et selon les cas, il faut prévoir des mécanismes sécuritaires, plus ou moins faciles à mettre en place.

Avec Oracle DB et SQL Server, le SGBD dispose en « interne » des moyens adéquats pour sécuriser les données (confidentialité et intégrité), alors que pour d’autres, il faut utiliser des addons (produits externes), voire développer du code spécifique.

Pour une base NoSQL, c’est encore plus difficile, dans la mesure où le principe ACID (Atomicité, Cohérence, Isolation, Durabilité) n’est plus assuré. Pour calculer le TCO, il faudrait donc prévoir deux scénarios distincts, pour chaque database, selon qu’elles hébergent ou non des données à sécuriser. Et chiffrer les efforts d’intégration d’outils sécuritaires et de développement.

C’est aussi dans ce chapitre que l’on situera les problèmes de réplication. Cette fois, il s’agit de garantir la continuité de service et donc de répliquer les données (toutes ou partiellement).

Là encore les bases ne sont pas égales. Certaines sont très efficaces, notamment Oracle DB, SQL Server, Azure Database et Maria DB, mais d’autres le sont moins.

Dans le calcul de TCO, il faudra envisager sur ce point plusieurs scénarios :

  • ·         disponibilité temps réel des données (infrastructure dédiée et synchrone à mettre en place, pour la reprise)
  • ·         disponibilité décalée (1 h, 24 h) avec réplication asynchrone des données

La difficulté dans un calcul de TCO est d’établir un certain nombre de règles de base, qui puissent être applicables à différents contextes, de manière à les comparer. Manifestement, les éditeurs prennent un « malin plaisir » à brouiller les cartes et cette opération se traduit souvent par un exercice de haute voltige, à l’origine de nombreuses contestations.

Les cinq chapitres du calcul de TCO

Cela établi, le calcul de TCO proprement dit, se fera dans cinq chapitres : licences, formation, intégration, production et administration courante, assistance applicative.

Les licences d’usage

Il y a plusieurs cas de figures à prendre en compte et il faudra traiter par le détail chacun des modes de « licensing » proposé par les éditeurs. Les cas d’Oracle et de Microsoft étant particulièrement ardus, qui constituent des spécialités, voire des métiers.

Il y aura des modes de facturation différents selon la durée : 1 an, 3 ans, 5 ans. Les coûts ne seront pas les mêmes en local et dans le Cloud.

Ces coûts pourront être établis par processeurs et il faudra statuer sur le mode de mise à jour, automatique ou non.

C’est l’aspect le plus difficile du TCO, car les modes de licensing n’étant pas les mêmes, il est très difficile de faire des comparaisons.

Il faudra de notre point de vue, se limiter à un scénario unique :

  •  durée d'un an
  • ·         1 ou 4 processeurs (on ne peut pas envisager toutes les configurations)
  • ·         Mises à jour incluses (en mode « pull », à l’initiative des utilisateurs)
  • ·         Local ou Cloud (quand cette option est disponible)
  • ·         1 ou 10 instances

Et on raisonnera en dollars américains, pour faciliter les comparaisons.

 

Formation

Il faut évaluer les formations techniques, en distinguant celles qui sont assurées par l’éditeur de celles proposées par des indépendants externes :

  • Formation SQL pour les bases de données relationnelles (en $/jour)
  • ·         Formation sur le langage de requête associé à la base NoSQL ($/jour)
  • ·         Formation sur l’administration technique des bases de données (dont l’intégration initiale) ($/jour)

On évaluera les coûts pour 1 ou 2 administrateurs internes et on privilégiera les formations certifiantes, celles qui aboutissent à une certification professionnelle. Qui rassurent les employés…

 

Intégration

On déterminera ici les coûts de première mise en œuvre, y compris de la chaîne de tests.

Avec deux cas possibles : fonction assurée en interne par le client lui-même (après la formation) ou par un intégrateur externe.

Dans le premier cas, on tentera de définir un coût de refacturation interne et dans le second, les coûts en nombre de jours assurés par l’intégrateur.

On se basera sur des durées d’intervention standards, car la complexité d’intégration n’est pas la même entre Oracle et MySQL, par exemple.

Nous proposons la grille suivante (qui pourra bien sûr être modifiée) :

  •  ·       Oracle DB : 10 jours d’intégration
  • ·         SQL Server : 5 jours
  • ·         Postgré : 5 jours
  • ·         MySQL : 3 jours
  • ·         Maria DB : 5 jours
  • ·         Base NoSQL : 8 jours (l’intégration applicative est plus spécifique)
  • ·         Azure Database : 10 jours

Mais on peut faire varier ces critères.

Le problème ici est que les coûts d’intégration ne sont pas comptablement de même nature que les autres. C’est un coût d’investissement (« one shot »), alors que la location, par exemple, est un coût de fonctionnement.

 

Administration et production

Les bases de données nécessitent la surveillance technique d’un administrateur système.

Chez Oracle, c’est un temps plein pour une personne, jusqu’à 10 instances (portant des applications différentes). Même chose pour PostGré et SQL Server.

Pour MySQL et Maria DB on peut diviser par deux cette charge, un mi-temps pour 10 instances.

Pour les bases NoSQL le problème est beaucoup plus délicat et on pourra donc reprendre le même ratio qu’avec Oracle : un temps plein pour 10 instances. Problème qui va s’aggraver avec la diversité des modèles : clés-valeurs, colonnes, graphes et documents.

Pour ce qui est de la production, on distinguera l’exploitation locale de l’hébergement Cloud.

Dans le cas du local, il faut traduire la charge de production, celle spécifiquement liée aux bases de données en jours/hommes, charge qui concerne les interventions ponctuelles, l’optimisation, les opérations liées à la sécurité, les reprises sur incidents, les sauvegardes, etc.

Il est évidemment très difficile de quantifier cette charge spécifique des bases de données. On peut reprendre cependant le ratio de charge applicative concernant les données dans une application globale, qui est en moyenne de 20 %. Ce qui veut dire que quand on développe une application, 20 % du code en moyenne concerne les données, le reste étant du traitement algorithmique.

Si on reprend ce critère, qui peut être affiné, il faudra reprendre la charge globale de production, tous traitements confondus et affecter 20 % de cette charge à la production des bases de données.

On inclut dans ce calcul les traitements spécifiques liés à la qualité des données par exemple, les extractions pour alimenter les entrepôts (datawarehouses), etc.

C’est encore dans ce chapitre qu’il faudra placer les coûts d’infrastructures, celui des serveurs dédiés et du stockage.

Contrairement aux autres coûts, ceux-ci sont plus faciles à déterminer car il suffit de se reporter sur la facturation des infrastructures et de reprendre ceux liés aux bases de données.

Les besoins en termes d’infrastructures ne sont toutefois pas les mêmes et dépendent du nombre d’instances installées, ainsi que de la volumétrie des données.

Il n’y a pas d’autre méthode que de répartir les coûts opérationnels de stockage entre Oracle et les autres, ce qui passe par un travail d’introspection délicat à effectuer.

 

Assistance applicative

Le cinquième chapitre qui intervient dans le calcul de TCO est souvent négligé, bien qu’il soit très important. C’est celui de l’assistance à apporter dans les phases de développement aux chargés de projets, qui incluent des problématiques d’accès et de traitement de données embarquées dans les databases.

Il s’agira :

  • ·         d’assistance système auprès des développeurs, pour les aider à écrire leur code
  • ·         d’assistance pour la migration éventuelle des données

Pour déterminer le poids de ce critère, qui ne s’applique qu’aux usagers qui développent du code ou ont à traiter des problématiques de migration, on pourra estimer la charge à un tiers-temps pour un administrateur, sans faire de distinction entre les bases.

 

Calcul du TCO

Il est impossible de tenir compte de tous les cas possibles et il faudra se limiter à un scénario représentatif :

Nous proposons le suivant :

Un exemple d’évaluation et une suggestion de paramètres, qu’il conviendra de modifier en fonction des cas réels d’utilisation. L’important n’étant pas les valeurs retenues mais les critères que l’on adoptera.

A titre d’exemple, on calculera le TCO Oracle en se basant sur une instance, portée par un serveur quadri-processeur, qui nécessitera 10 jours d’intégration initiale et 10 jours de formation SQL et sur les techniques d’administration système.

Les autres coûts sont à calculer conformément à ce qui a été indiqué précédemment : licence, assistance applicative, charge de production, charge d’infrastructure de stockage.

On rappellera que ce scénario ne concerne qu’une seule instance.

On refera le même calcul avec un hébergement en Cloud, le prestataire prenant cette fois en charge l’administration technique, l’intégration et la production. Restera à la charge du client, outre les licences, les formations et l’assistance applicative. Il faudra ici faire un vrai travail d’introspection, car les prestataires n’appliquent pas les mêmes méthodes de facturation.

Une fois ce travail effectué, on obtiendra pour chacune des databases, un TCO théorique, pour lequel on prendra soin de distinguer les coûts de fonctionnement, des investissements.

Evidemment ce TCO va dépendre largement des choix effectués et du paramétrage retenu. Nous en avons proposé un, mais chacun pourra parfaitement substituer le sien. Et surtout ne pas entrer dans la polémique, sous prétexte que le cadre proposé n’est pas exactement celui qu’un usager pourrait imaginer.

Il reste que notre approche est concrète et correspond à ce qui se passe sur le terrain. Nous nous sommes efforcés de n’oublier aucun coût constitutif du TCO et garantissons qu’il suffira d’un tableur Excel et de quelques formules de base, pour disposer d’un indicateur, fiable à 10 %.

Ce n’est pas parfait, mais rien n’empêche de l’améliorer…