carloscastilla - Fotolia
Plongée dans SAP HANA
Véritable « plateforme » qui va du Data Warehouse au serveur applicatif, en passant par le NoSQL et l'intégration de données, la base in-memory de SAP a beaucoup de visages. Certains sont plus que séduisants, d'autres un peu moins.
Près d'une décennie a passé depuis la première présentation de SAP HANA. A présent que le tapage marketing est retombé et que le produit s'est stabilisé, comment se place la base (et la plateforme) par rapport à la concurrence dans les environnements IT ?
Parce que HANA est plus qu'une seule chose, la réponse à cette question dépend fortement du cas d'utilisation, de la maturité des fonctionnalités et des caractéristiques scrutées, et de l'environnement concurrentiel.
Voici quelques pistes pour commencer à réfléchir clairement (et avec du recul) à la manière dont HANA peut se positionner dans votre organisation aujourd'hui.
Ce qu'est HANA aujourd'hui
La première question qui se pose est : qu'est exactement HANA ? Aux débuts de HANA, SAP a d'abord communiqué sur une stratégie simple. L'idée était de descendre de la couche applicative vers la base de données pour fusionner plus ou moins les deux.
HANA a bien changé depuis. Et SAP y a quasiment mis toute son offre. HANA comprend maintenant une douzaine de fonctions qui se répartissent en trois grandes catégories :
1 - Traitement et stockage des données. Ces capacités reposent sur le moteur original, in memory et en colonnes, de HANA. S'y ajoutent ses fonctions de gestion de base de données (SGBD), de base de données orientées graph, de données géospatiales, de base orientée document et le Machine Learning.
Si l'architecture du moteur de HANA porte de nombreux noms, « hybride en colonne et in-memory » reste le moyen le plus clair de la décrire. L'expression souligne bien les avantages des deux approches qui évite les inconvénients des architectures entièrement en colonnes ou entièrement en mémoire.
2 - Plate-forme d'application. Les capacités applicatives étaient à l'origine basées sur le serveur d'application JavaScript « XS ». Mais depuis la sortie de HANA 2.0, les applications s'exécutent désormais sur SAP HANA Extended Application Services (alias « XS advanced »), une plate-forme plus flexible, à base de conteneurs, et qui repose sur Cloud Foundry.
« XS advanced » supporte Java et JavaScript, ainsi que Python, PHP et d'autres langages - avec l'utilisation de build-packs personnalisés.
3 - Intégration de données. Ces fonctions d'intégration permettent à HANA d'interagir avec d'autres plates-formes et d'autres sources de données. Elles donnent les moyens de créer un modèle de données fédéré unique.
Smart Data Access et Smart Data Integration permettent un accès fédéré ou répliqué à des degrés divers aux données externes qu'elles soient dans des bases de données traditionnelles, dans Spark, dans des systèmes de fichiers distribués Hadoop ou dans d'autres plateformes. Ces fonctionnalités sont également à la base de certaines des options de tiering des données de HANA, que les administrateurs peuvent utiliser pour stocker les informations sur des plates-formes moins coûteuses.
Forces, faiblesses et cas d'usage
Parmi les fonctionnalités de SAP HANA, ses capacités traditionnelles de traitement SQL et de stockage des données sont les plus avancées, les plus utilisées et les plus stables.
Les clients semblent en effet utiliser moins souvent la plate-forme d'application, les fonctions NoSQL ou sa partie d'intégration de données, car ces possibilités sont un peu moins avancées en terme de stabilité.
En raison des maturités différentes pour les différents atouts de SAP HANA, la question du positionnement de HANA dans une organisation s'évaluera en fonction des cas d'usages.
Voici quelques cas pour lesquels HANA est un bon candidat :
S/4HANA ou BW/4HANA. Dans ce cas, il n'y a pas beaucoup de choix. HANA brille en exécutant ces applications spécialement conçues pour elle et qui utilisent ses fonctionnalités les plus puissantes (le moteur hybride en mémoire et en colonnes).
Système de gestion de base de données généraliste (SGBD). Les cas d'usages des bases de données varient considérablement en termes de workloads. Pour beaucoup d'entre eux, HANA est le meilleur de sa catégorie en ce qui concerne les critères de performance et d'évolutivité. Le point fort de HANA reste les workloads qui requièrent à la fois des caractéristiques transactionnelles et analytiques.
Plate-forme d'application. Les clients SAP considèrent souvent HANA comme une plate-forme généralistes pour les applications métier qui s'intègrent (mais pas toujours) à S/4HANA.
Entrepôt de données. HANA fournit des fonctions de modélisation de data warehouse. Sa force en tant que base de données SQL robuste en fait un concurrent majeur dans ce domaine.
Plate-forme Machine Learning et de Data Science. HANA dispose de fonctions intégrées d'apprentissage statistique et d'analyse textuelle.
Comment faire son choix ?
Pour décider si HANA convient à un cas d'utilisation donné, il est préférable d'examiner le niveau de maturité des capacités de la plateforme pour ce cas précis, par rapport aux autres options envisageables.
Vous devez également tenir compte du coût, de l'engagement de SAP à l'égard de la fonctionnalité en question et de la disponibilité de personnes possédant les compétences nécessaires pour que les capacités d'HANA soient mises concrètement en oeuvre.
Pour des utilisations comme S/4HANA, le choix est clair. Il n'y a pas d'autres options. SAP est très attaché à l'application et, par conséquent, aux fonctionnalités de HANA qui la supportent. Mais pour les autres cas, le choix n'est jamais aussi clair.
Les clients décideront même souvent que HANA n'est pas la meilleure option. Il est en effet souvent difficile de trouver les compétences nécessaires pour utiliser HANA en tant que plate-forme d'application ou plate-forme de Data Science généraliste. D'autres bénéficient de communautés plus grandes voire de fonctionnalités plus matures. Bien sûr, l'évaluation dépendra des préférences particulières ; il y aura toujours des cas où HANA aura du sens pour le développement ou le Machine Learning, particulièrement pour les organisations fortement engagées dans la technologie SAP.
A l'inverse, utiliser HANA comme un entrepôt de données est probablement son usage le plus fort. Les utilisateurs potentiels devront certes analyser leurs propres workloads, mais HANA surclassera souvent largement les autres options, notamment sur les charges mixtes (transactionnelles et analytiques) pour lesquelles la base a été spécialement conçue. Mais elle tiendra également souvent la comparaison pour de nombreux cas purement transactionnels ou purement analytiques.
En termes de compétences disponibles, de maintenance de HANA et de création d'applications qui reposent sur elle (en tant que base de données), HANA n'est pas très différente des autres bases du marché. Et SAP s'engage clairement en faveur de cette facette SGBD de sa plateforme.
Conclusion
Comme toujours, les entreprises qui cherchent à investir massivement dans une base de données ou dans toute autre plate-forme devront faire preuve de la plus grande prudence.
Ceci étant, maintenant que le battage médiatique autour de HANA est passé et que la stratégie de SAP autour du cloud, de la gestion des données et des applications s'est précisée, le choix est un peu plus facile. A condition d'aborder le problème avec suffisamment de lucidité et de recul, sur ce que HANA sait faire mieux (ou pas) que ses concurrents dans chacun de ces trois domaines.
