Hana triomphe, MaxDB vit toujours

Que signifient les nouveaux plans de SAP pour les utilisateurs qui ont toujours misé sur les bases de données SAP ? Comment doivent-ils aligner leur propre stratégie informatique sur celle de SAP ?

De plus en plus de voix s'élèvent pour convaincre les utilisateurs que MaxDB est un modèle obsolète. Lorsqu'il est conseillé de changer de base de données, il n'est curieusement pas question de Hana, mais plutôt d'ASE, qui semble être la destination la plus évidente pour la migration.

Mais le fait est qu'ASE n'est pas une véritable alternative à MaxDB, et que MaxDB représente encore pour des années un SGBD fiable et utilisable à bon escient.

La fin des années 80 : SQL laisse SAP aux autres

Au moment de la création de R/3, à la fin des années 1980, la stratégie de SAP en matière de bases de données était encore claire et simple. À l'époque, SAP n'était expressément pas un fabricant de bases de données, mais misait, en tant que fournisseur ERP, sur les systèmes de gestion de bases de données SQL bien établis.

Au début, il s'agissait uniquement d'Oracle et d'Informix, puis d'IBM DB2 et de Microsoft SQL Server.

Le fait qu'Oracle soit arrivé sur le marché avec Financials dès la fin des années 1980, concurrençant ainsi SAP dans le domaine des applications, a d'abord été rejeté comme une "cooptation" habituelle sur le marché.

Au fil des années, SAP est toutefois devenu le plus grand revendeur à valeur ajoutée d'Oracle - et transférait chaque année un montant considérable de millions à son concurrent. Un dilemme qui a poussé SAP à changer sa stratégie d'abstinence de base de données.

Les années 90 : DB propre à SAP

Avec ADABAS D de Software AG, SAP s'est doté d'une autre base de données au début de l'année 1992. Après la certification de R/3 en 1994, elle a d'abord été positionnée comme une alternative économique à Oracle & Co.

En 1997, après avoir racheté les droits sur les produits et une grande partie de l'équipe de développement de Software AG, SAP a cessé d'être un simple revendeur de systèmes de gestion de bases de données étrangers.

Le premier SGBD propre à SAP fut dès lors proposé sous le nom de SAP DB.

L'objectif évident de SAP était de stimuler la concurrence dans le domaine des bases de données et de briser la domination d'Oracle sur la base de clients SAP grâce à son propre produit.

Les ventes n'augmentant pas sensiblement, SAP a publié en 2000 la version 7.3 de SAP DB sous une licence open source.

2003 : Renaissance de l'open source

En 2003, un accord de distribution a été conclu avec MySQL AB. Dans le cadre de cette coopération, le SGBD a été proposé - à partir de la version 7.5 - sous le nom de "MaxDB by MySQL". Le support et le développement sont cependant restés chez SAP.

Cette coopération s'est achevée sans bruit en 2007 et, à partir de la version 7.6, SAP MaxDB n'a plus été proposé en version open source. Toutefois, SAP a décidé à l'époque de proposer une alternative pour que MaxDB puisse continuer à être utilisé en dehors des applications SAP : une "Community Edition" gratuite sous une Community License.

Jusqu'à aujourd'hui, MaxDB est disponible sous la forme de cette Community Edition gratuite - et peut donc également être utilisée en dehors du monde SAP.

Comme SAP n'a longtemps pas voulu être perçu comme un fabricant de bases de données, MaxDB a vécu dans l'ombre. Mais cela n'a pas empêché son succès.

Malgré l'absence d'impulsion de la part du marketing et des ventes de SAP, la base de données s'est bien répandue. MaxDB jouit d'une acceptation élevée et ininterrompue, en particulier dans les PME germanophones.

Les raisons importantes sont le coût total de possession (TCO) avantageux et un fonctionnement silencieux et fiable. Les clients SAP utilisent au moins 27 000 serveurs MaxDB.

Ce chiffre est d'ailleurs plusieurs fois supérieur à celui des installations de SAP ASE dans la base de clients. MaxDB s'est également largement répandu en interne chez SAP, avec plus de 2 500 installations. Selon des informations internes, environ la moitié des systèmes de production internes de SAP sont basés sur ce SGBD.

Nouveaux développements SAP sur MaxDB

SAP a également procédé à de nouveaux développements technologiques sur la base du noyau MaxDB. Ainsi, à la fin des années 1990, SAP liveCache a été créé en tant qu'extension basée sur des objets du noyau MaxDB pour la gestion en mémoire d'objets complexes (c'est-à-dire des arbres et des réseaux) - dédié à la solution logistique SAP SCM/APO.

Actuellement, il existe encore plus de 5.000 installations de SAP liveCache dans le contexte de la gestion de la chaîne d'approvisionnement et de la planification et de l'optimisation avancées.

MaxDB continue également à jouer un rôle particulier dans le contexte de SAP Content Server : sans MaxDB, pas d'externalisation de contenu non formaté dans une base de données.

Il n'existe pas de chiffres officiels sur ce scénario d'utilisation, mais on peut s'attendre à quelques milliers, voire plus de dix mille installations. SAP MaxDB n'a peut-être pas une existence sous les feux de la rampe, mais l'adhésion des utilisateurs n'en a pas souffert.

Ces dernières années, la base installée de SAP MaxDB a même connu une croissance significative : plus de 50 % rien que depuis début 2013. L'une des raisons de ce succès se reflète également dans la récente étude "Relational OLTP-Midmarket DBMS" réalisée par les analystes de "Research in Action" : MaxDB jouit d'une satisfaction élevée et continue de la part des clients.

Sybase apporte ASE et IQ

A la fin de la première décennie de l'an 2000, SAP a entrepris une acquisition stratégique de plusieurs milliards de dollars : le 30 juillet 2010, le fabricant californien de bases de données Sybase a été racheté.

L'objectif déclaré de SAP était d'atteindre ainsi "des milliards d'utilisateurs".

Bien que les solutions de mobilité et l'accès aux clients de téléphonie mobile aient constitué le principal motif de l'acquisition, SAP a également intégré les produits de base de données originaux de Sybase dans le cadre de cette opération.

Il s'agissait notamment du SGBD OLTP Sybase Adaptive Server Enterprise (ASE) et de la base de données d'entrepôt de données Sybase IQ, qui se distinguait par ses performances OLAP élevées en raison de son organisation de stockage en colonnes.

Mais l'acquisition de la technologie SGBD était plutôt une "prise accessoire" et ne constituait pas un élément de la stratégie - qui n'avait pas encore été annoncée officiellement à l'époque - visant à occuper une place de premier plan sur le marché des bases de données.

On ne sait toujours pas exactement ce que SAP avait l'intention de faire avec les produits DBMS acquis. En tout cas, il n'a jamais été question de remplacer MaxDB par Sybase ASE.

SAP se présente à nouveau comme fabricant de DB

Dès le milieu de la première décennie du nouveau millénaire, Hasso Plattner avait réussi à trouver un accord pour réaliser sa vision d'une base de données en mémoire hautement performante et orientée vers les colonnes.

En conséquence, SAP avait déjà secrètement acheté en 2005 le fabricant de logiciels californien Transact in Memory et donc la base de données OLTP en mémoire P*TIME.

En 2009, SAP s'est attelé à la création d'une nouvelle base de données SAP. Il s'agissait d'un mélange technologique du SGBD Row-Store P*Time, du moteur de recherche TREX basé sur Column-Store, développé des années auparavant, et de MaxDB comme couche de persistance.

Au début, cette nouvelle base de données SAP s'appelait New Database ou New DB. Lors de sa première livraison en novembre 2010, elle portait temporairement le nom de High Performance Analytical Appliance.

Par la suite, elle n'a été désignée que par la forme abrégée de ce nom : SAP Hana 1.0.

L'avenir appartient à Hana

Depuis la présentation de Hana, c'est clair : SAP se montre offensif en tant que fabricant de bases de données et a déclaré la guerre à Oracle, son principal concurrent dans ce domaine.

L'objectif déclaré est de libérer les applications SAP des SGBDR traditionnels, qu'il s'agisse des siens ou de ceux des concurrents. C'est pourquoi SAP investit principalement dans la plateforme moderne Hana et très peu dans le développement de ses bases de données relationnelles classiques.

La conséquence de cette stratégie Hana sans équivoque est claire : à long terme, il n'y a de perspective pour aucune des bases de données SAP vieillissantes, que ce soit MaxDB ou les héritages Sybase ASE et IQ.

L'avenir des bases de données de SAP s'appelle Hana. Si vous voulez continuer à vous procurer vos applications de gestion d'entreprise auprès de SAP, vous ne pouvez pas passer à côté de Hana.

Avec l'annonce de S/4 Hana, la Business Suite de la prochaine génération, SAP SE a souligné une fois de plus sa volonté d'imposer sur son turf la souveraineté en matière de bases de données.

MaxDB : durée de conservation minimale 2025

Reste la question de savoir quelle pression d'action l'orientation de SAP vers Hana provoque maintenant pour les entreprises qui utilisent actuellement MaxDB. Actuellement, rien de particulier.

Ce n'est qu'au début de l'année 2015 que SAP a prolongé la "Mainstream Maintenance" de cinq ans jusqu'à fin 2025 - garantissant ainsi la maintenance pour au moins dix ans supplémentaires.

Il est plus fréquent d'entendre dire que le développement de MaxDB a été arrêté.

C'est manifestement faux. Par exemple, Database Studio, l'outil de gestion autonome pour MaxDB, a récemment été complété par SAP par un outil d'analyse graphique.

Les disques SSD à base de mémoire flash constituent un autre moyen simple de booster les performances d'une instance MaxDB.

Le passage du HDD au SSD n'est bien sûr pas une évolution du SGBD à proprement parler, mais il est désormais possible car SAP a récemment certifié le matériel correspondant.

ASE sans avantage de coût

On entend souvent dire qu'une migration de MaxDB vers ASE serait judicieuse. Après tout, chaque "Hana Runtime Edition for Applications and SAP BW (REAB)" contient déjà une licence pour MaxDB et une pour ASE - la migration serait donc possible sans frais de licence, tout comme l'exploitation parallèle des deux SGBD.

Toutefois, compte tenu de l'accent clairement mis par SAP sur Hana, une telle migration ne constitue pas une mesure de prolongation de la vie : Le cycle de vie d'ASE devrait s'achever en même temps que celui de MaxDB.

Les partisans de l'ASE invoquent généralement la compression des données comme principal argument en faveur d'une migration. Mais le proverbe américain s'applique toujours : "There's no such thing as a free lunch".

L'économie d'espace disque est chèrement payée, car ASE nécessite une puissance de calcul nettement supérieure. L'avantage de compression d'ASE se paie en fin de compte par des investissements en puissance CPU.

Le problème de sauvegarde d'ASE

Du point de vue d'un partisan de MaxDB, le concept de sauvegarde d'ASE est l'un de ses principaux points faibles.

ASE ne peut pas vider le journal pendant une sauvegarde complète. Cela signifie que si la sauvegarde dure trop longtemps, les logs débordent et le système s'arrête.

En revanche, la configuration de sauvegarde en ligne de MaxDB ne connaît pas de telles restrictions. La recommandation d'effectuer les sauvegardes ASE pendant les périodes de faible charge semble tout simplement naïve et ne tient pas compte des réalités de l'entreprise.

Si migration il y a, c'est sur Hana

Il apparaît donc qu'ASE est souvent surestimé, tandis que les capacités de MaxDB restent notoirement sous-estimées.

Un gain de fonctionnalité ne peut être obtenu lors d'une migration de MaxDB vers ASE que dans quelques cas exceptionnels et exposés - par exemple lorsque la compression plus élevée est un facteur décisif.

En revanche, les coûts de licence et de maintenance sont plus élevés (sauf si la licence est achetée dans le cadre d'une Hana Runtime Edition sans incidence sur les coûts), la formation nécessaire et les risques considérables.

Les utilisateurs qui utilisent MaxDB non seulement avec ERP, mais aussi sous la forme de liveCache ou dans le cadre de Content Server, ne pourraient de toute façon pas migrer complètement vers ASE.

Tant que SAP ne migrera pas à grande échelle ses systèmes internes basés sur MaxDB vers Hana, les utilisateurs de MaxDB pourront dormir sur leurs deux oreilles. Ceux qui utilisent MaxDB aujourd'hui devraient le rester jusqu'à ce que la migration vers Hana leur semble s'imposer.

Une double migration serait cependant totalement absurde. Faire un détour par ASE pour atteindre Hana reste un non-sens.