D’abord, un petit coup d’œil dans le rétro …
Depuis plus de 20 ans, l’offre DataStage a bénéficié de nombreuses évolutions.
De la version 1 à la version 5.0 (en 2001), c’est la version DataStage Server, basée sur la technologie VMark Universe™ qui a contribué à l’explosion de la conception de flux ETL en mode graphique.
Parmi les grands avantages, on retrouvait la simplicité (drag&drop, connecteurs aux données « graphiques », composants graphiques de transformation, calcul, …), les fichiers Hash qui ont fait les belles heures de la solution par leur efficacité, la performance (déjà à l’époque) et la capacité à enrichir le produit par de nouvelles fonctions (grâce au langage Basic Universe).
Toutefois, la capacité à gérer la croissance exponentielle des volumes restait limitée.
A partir de 2002 est apparue la version DataStage Enterprise Edition (dite PX), avec une architecture différente basée sur C/C++ issue du rachat de Torrent Systems™ par Ascential Software™.
Elle introduit le moteur de parallélisation (PX pour Parallel eXtender) garantissant une scalabilité et des performances à grande échelle. Celui-ci exploite au mieux l’augmentation de puissance des machines physiques (nombre de cpus/cœurs, nombre de machines, …) et la diversification des architectures (mono server, multi-server, grid , hadoop, containers, …).
Cette évolution était indispensable pour accompagner les besoins grandissant d’évolutivité et de performance liés à l’explosion des données traitées.
En termes de modélisation, le principe de Design Graphique « low code » de la version historique est conservée, les utilisateurs restant dans un monde « connu ». Bien sûr, un niveau supplémentaire est indispensable en conception (on parle de partitionnement de la donnée, de pipe-lining …) afin que les flux exploitent au mieux l’infrastructure dynamique (avec l’astucieux concept de « fichier de configuration » décrivant les ressources).
Depuis 18 ans, deux « mondes » cohabitent : jobs Server et jobs PX (ou parallèles).
Certains clients n’ont jamais utilisé la version PX parce qu’ils n’avaient pas de besoins particuliers de performance ou qu’ils étaient freinés par des contraintes budgétaires. D’autres ont commencé en « Server » puis ont développé les nouveaux flux en « PX » tout en conservant l’existant. D’autres enfin ont adopté l’offre IBM après 2005 en incluant le développement en « full PX » comme une règle de bonnes pratiques.
Certains ont donc encore plusieurs milliers de jobs Server actifs.
Cette situation « hybride » sur DataStage a un coût :
- En terme humain car il faut maintenir une double compétence Server/PX pour les projets,
- En terme technique car seuls les jobs PX bénéficient d’une évolution de l’architecture et sont « scalable »,
- Pour l’éditeur car le maintien de deux technologies peut limiter certaines évolutions et complexifie le travail pour la R&D et le support.
Puis vers l’horizon …
Afin de maintenir une stratégie cohérente en termes d’évolution, de besoin client, de simplification, de maintenabilité, d’effort en R&D, IBM ajoute régulièrement de nouvelles capacités à DataStage (l’offre « IBM Information Server »), comme l’arrivée récente de jobs Spark par exemple.
Pour les mêmes raisons, IBM met parfois fin à certaines fonctionnalités ou composants.
C’est le cas des jobs « Mainframe » générant des programmes Cobol (ancien DataStage MVS Edition), la fin des connecteurs historiques (depuis la v11) spécialisés par technologie : les « plugins » (OraOCI, Oracle Enterprise, DB2 Enterprise, …) pour les basculer sur une architecture unifiée : les « Connectors »
Cela se fait de manière progressive : les composants sont tout d’abord dépréciés pendant quelques versions, puis finissent par disparaître tôt ou tard.
L’obsolescence programmée des jobs Server …
En reprenant le sujet des architectures Server et PX, la « release note » de la dernière version 11.7.1 présente un point important (https://www.ibm.com/support/pages/node/878853#DEPRECATED) :
In an effort to improve our offerings for the future, we are deprecating the following features:
- DataStage Server Canvas
- (…)
We will continue to support these features, but will not accept enhancements requests. In addition, some of these features may be removed from a future release.
Cela signifie que la création de jobs DataStage Server est une fonctionnalité dépréciée à partir de la 11.7.1.
Fort heureusement, cela ne constitue toutefois pas une disparition.
En lisant entre les lignes, on comprend que la technologie Server bride un peu les évolutions, mais que les jobs Server continueront de fonctionner au moins tant que la 11.7 subsistera (probablement 5 ans, qui est la durée de vie usuelle d’une version).
IBM indiquait depuis des années qu’il était préférable de développer en jobs PX, mais cela restait une préconisation. Ce n’est maintenant plus une échéance vague, c’est inscrit dans le plan produit.
C’est donc un sujet à prendre en compte pour votre patrimoine DataStage afin d’anticiper cette échéance.
En conclusion,
De manière pragmatique, les utilisateurs des deux modes, Server et PX, doivent imposer dans leurs normes de ne développer que des traitements parallèles, ce sont les seuls qui sont certains de subsister dans le futur et qui permettront de tirer parti au mieux de la nouvelle offre Cloud Pak for Data.
Quant aux jobs Server, deux stratégies sont applicables :
- Les laisser subsister tels quels, et, uniquement quand une modification sera nécessaire, les réécrire en version PX,
- Lancer un projet de bascule/réécriture, ce qui constitue un projet « technique » difficile à financer.
La question se pose différemment pour tous les clients DataStage qui n’ont pas de licence Enterprise et donc ne peuvent pas développer de jobs PX.
S’ils pourront continuer avec leur existant, la mauvaise nouvelle est qu’il n’y aura plus d’évolutions et donc quid de la prise en compte des nouveaux besoins, des nouvelles versions d’OS, de SGBD … Et qu’adviendra-t-il du coût de maintenance ?
Il appartiendra à ces clients de se rapprocher d’IBM pour définir la meilleure stratégie commerciale pour adapter leurs licences.
Cette situation est moins bloquante pour un projet « mature et stable » que pour des flux opérationnels qui évoluent. Dans tous les cas, les clients doivent mener une réflexion à moyen terme sur leur plateforme d’intégration.
Forts de notre rare expertise de pointe sur DataStage (nos experts ont travaillé chez l’éditeur), nous avons mené plusieurs dizaines de projets majeurs de migration (milliers de jobs, changements d’OS, changement d’ETL, etc.)
Par notre maîtrise de cette technologie et notre savoir-faire, Intrabases vous proposera les stratégies et les méthodes palliatives les plus adaptées pour anticiper l’obsolescence programmée des jobs Server.
Les évolutions actuelles de l’offre « IBM Information Server » : Big Integrate, Cloud Pak for Data basé sur RedHat Openshift, dockerisation, PaaS, … amènent toutes une simplification dans l’utilisation, l’administration et le déploiement de la solution qui se positionne comme brique majeure de la gouvernance et l’intégration de données.
Contacter nous pour aller plus loin et pérenniser votre plateforme d’intégration de données ou, plus simplement, pour bénéficier de nos conseils et de notre expertise. Nous serons ravis de vous renseigner.
