jeudi, juillet 16, 2015

Mainframe / Cobol market and Eranea's solution : updated briefing

Update on the briefing around our solution (technology, methodology) with figures regarding current context (obsolescence, HR depletion) and the size (25+ billions dollars, 220 billions lines of Cobol, 10'000 machines) of the mainframe market.

Introduction to our cornerstones : full automation and strict iso-functionality allowing incremental and fully safe transformation toward the new x86 private cloud.





Pointers to all our other reference documents :
  1. why Eranea's solution : http://goo.gl/mzawC4 (text)
  2. legacy transformation for agile innovation : http://goo.gl/bmmQ1x (text & slides)
  3. technology and methodology : http://goo.gl/4cQ1Yn (text)
  4. technology and methodology : http://goo.gl/M3H054 (slides)
email for more : contact@eranea.com

Source: blog Media and Tech (par didier durand)

lundi, juillet 13, 2015

Présentation : la transformation digitale incrémentale des applications métier pour une innovation rapide et efficace


Toutes les grandes sociétés traditionnelles tentent actuellement de booster leur transformation digitale afin d'être prêtes à riposter au plus vite quand le Uber de leur secteur industriel va émerger.

La technologie de transcodage 100% automatique et strictement iso-fonctionnelle d'Eranea apporte des éléments à cette transformation digitale rapide:

  • elle permet d'innover très vite, dès le début du projet de migration vers x86 / Java / web , alors même que la migration des utilisateurs et processus en place n'a pas encore débuté. Pas de “tunnel” sans fin, mais des services innovants rapidement visibles.
  • elle permet d'innover “au-dessus” de l'existant : le nouveau service s'appuie sur tout le logiciel applicatif transcodé vers Java pour fonctionner. Il n'a pas à “ré-inventer la poudre” mais juste à développer sa propre valeur ajoutée en s'appuyant sur un patrimoine applicatif abondamment éprouvé par des années de fonctionnement sans faille. L'agilité est donc au rendez-vous!
  • elle permet d'innover à l'échelle complète de la société : le nouveau service s'appuie sur la nouvelle architecture de migration destinée à servir – à travers la flexibilité et la scalabilité du cloud computing - la totalité de l'entreprise à un niveau de service équivalent (disponibilité, performances, etc.) à celui du mainframe en cours de décommissionnement. Cette architecture est apte à servir les (dizaines de) milliers d'utilisateurs de l'organisation donc y ajouter la charge supplémentaire nouvelle induite par ces nouveaux services n'est pas un problème ! Donc, plus de micro-prototype séduisant initialement mais passant péniblement à l'échelle par défaut d'une architecture solide : ici, l'innovation se fait directement dans les conditions de fiabilité des systèmes de production.  L'iinovation est directement 100% efficace !




Les différents exemples de notre nouvelle présentation démontrent comment :
  1. doter une application “historique” (= mainframe) d'une interface web (html + ajax) conforme à l'état de l'art.
  2. l'ouvrir ensuite sur Internet pour servir de nouveaux besoins: des employés équipés de terminaux mobiles (téléphones, tablettes), des clients externes, etc.
  3. interfacer le système (en cours de migration) critique pour le métier avec un package logiciel tiers interne ou une plate-forme de branche externe sur Internet grâce aux services web (soap ou rest)
  4. tirer le meilleur parti des facultés de parallélisation automatique grâce à Hadoop capable d'exécuter facilement les programmes en batch transcodés vers du Java, langage de base de cette plate-forme Big Data

La présentation ci-dessus a donc été créé pour démontrer que la frugalité (= 90% d'économies sur les coûts mainframes initiaux → des millions d'euros annuels récurrents) n'est pas l'unique livrable d'Eranea : l'agilité pour une innovation rapide et l'efficacité pour une innovation globale sont aussi au menu, au choix en entrée ou en dessert !

Le plat principal de la transformation globale est bien sûr lui toujours consommé en parallèle !

[Pour tous les détails : à partir de la page 28 de la présentation ci-dessus, des notes complémentaires accompagnent les slides. Sinon, écrire à contact@eranea.com pour obtenir des réponses à vos questions]

Pour les détails techniques de la solution, notre présentation de la technologie, des outils et de la méthodologie de transformation incrémentale est toujours plus complète : 40 slides ont été ajoutés pour présenter en profondeur l'interface et les services de NeaControlCenter. Voir ci-dessous à partir du slide 35.

 

Eranea's solution and technology for mainframe migration / transformation : detailled presentation from Eranea

Un texte descriptif détaillé présentatnt la technologie et comparant aussi replatforming and transformation applicative structurelle est disponible aussi :




Source: blog Media and Tech (par didier durand)

mardi, juin 16, 2015

Transformation digitale des « majors » : catalysée par l'hémorragie des compétences mainframe ?

Article repris de mes publications sur ZDNet.fr :  Article repris de mes publications sur ZDNet.fr : 
  
Transformation digitale des « majors » : catalysée par l'hémorragie des compétences mainframe ?

Une hémorragie de compétences est prévisible à 3 ans pour le monde des mainframes alors que ces machines représentent toujours l'épine dorsale numérique des plus grandes entreprises. La transformation technologique incrémentale ne doit-elle pas être la première étape de la transformation numérique de ces entreprises pour mettre leur propriété intellectuelle compétitive en sécurité ?

Deux chiffres s'opposent dans une récente étude de la société américaine Compuware qui édite des logiciels pour mainframes : 89 % des répondants reconnaissent que la propriété intellectuelle intégrée dans le code source des applications fonctionnant sur ces machines est un atout / un capital à protéger alors que 70 à 80 % des effectifs mainframes vont partir en retraite dans les 3 ans. L'étape de « transcodage technologique » des transformations digitales en route au sein de certaines entreprises majeures serait-elle la bonne résolution de ce paradoxe ?

En effet, les mainframes ont fait les beaux jours d'IBM en étant, il y a 2 ou 3 décennies, les systèmes informatiques critiques, “l'épine dorsale numérique”, de toutes les grandes entreprises de l'industrie ou du tertiaire.

Ils sont encore incontournables dans toutes ces organisations publiques ou privées majeures, en particulier dans le monde financier: l'étude Compuware qui vient de sortir fait ressortir que 88% des CIOs / DSIs des 350 entreprises mondiales de 10'000 employés et plus interrogés disent que le mainframe restera un élément vital de leur informatique dans la décennie à venir. Ce chiffre corrobore des données récentes d'IBM : 30 milliards de transactions concernant des achats boursiers, des transferts de fonds, de la gestion de production industrielle sont exécutés quotidiennement sur les mainframes situés dans les 96 des 100 premières banques mondiales, les 23 des 25 premiers distributeurs US, les 9 des 10 premières assurances mondiales, etc.

Et très paradoxalement, ces CIOs déclarent aussi à Compuware que 70 à 80% de leurs effectifs liés au mainframe vont partir à la retraite dans les 3 prochaines années et qu'une bonne partie d'entre eux pourraient de toute façon déjà y être ! 39 % de ces responsables admettent enfin ne pas avoir de plan de remplacement effectivement prêt pour traiter cet état de fait.

C'est d'autant plus embarrassant que les étudiants en informatique sortant des universités ne se bousculent pas pour occuper ces futurs postes vacants : le monde du cloud computing et celui des archictectures distribuées sont beaucoup plus attractifs actuellement car ce sont les seules architectures utilisées par les “gorilles” du web (Google, Facebook, Amazon, etc.), icônes de l'industrie informatique actuelle. Les gros monolithes des ères informatiques antérieures n'attirent donc (plus) personne ! L'équation est simple : il ne se vend que quelques milliers de mainframes chaque année alors que plus de 10 millions de serveurs x86 sont acquis et installés dans le même laps de temps.

Que faire ? Attendre en espérant une recrudescence (improbable...) de vocations autour de ces systèmes conçus pour une autre ère de l'information où le buzz ne se faisait par autour de mots comme Hadoop, Docker, micro-services, Big Data, DevOps, etc. ? Ou prendre le taureau par les cornes pour tenter de quitter l'impasse.

Ce n'est d'ailleurs pas une impasse mais plutôt une tour d'ivoire dans laquelle ces mainframes sont enfermés depuis trop longtemps : il faut casser les murs de cette tour pour en intégrer son otage avec les autres serveurs du système afin de pouvoir préparer un transfert progressif de ses activités vers les nouvelles générations de matériel.

Et là, la politique de la “terre brûlée” est la plus mauvaise idée : il faut définir des plans de transition très incrémentaux donc sans risque dans lesquels le fonctionnel n'est pas impacté mais simplement “transcodé” en mode iso-fonctionnel dans des technologies adaptées aux nouvelles générations technologiques afin de préserver la propriété intellectuelle et l'avantage qu'il représente (cf les 89 % introductifs).

Cette propriété intellectuelle “métier” de l'entreprise est ainsi mise en sécurité de manière pérenne sur une plate-forme à l'avenir garanti que ce soit sur le plan technologique comme sur le plan des ressources humaines.

La première étape de la transformation digitale que toutes les entreprises traditionnelles majeures cherchent actuellement à s'imposer devrait donc être celle d'une pérennisation par transposition de leur propriété intellectuelle compétitive, “gravée” dans les algorithmes mainframe par la génération qui part à la retraite. Ensuite, la course à l'innovation destinée à contrer tous les nouveaux acteurs du web qui dévorent tous les marchés : l'agilité des processus et la fluidité inter-canaux gagnées par la transposition technique peut être mise à profit pour reprendre des parts de marché

Notre expérience est que la transformation technologique n'est peut-être pas l'étape la plus excitante sur l'agenda de tous les CDOs (Chief Digital Officer) actuellement nommés à tour de bras par les grandes entreprises. Elle est cependant un pré-requis à la transformation organisationnelle / opérationnelle / commerciale induite par l'adjonction de l' « Internet (mobile) à toutes les étages » des processus qui est le Graal actuellement quêté par tous ces CDOs.

Source: blog Media and Tech (par didier durand)

mercredi, mars 11, 2015

Bank of America : 1,5 milliard d'économies grâce à un cloud OpenCompute de Facebook

Article repris de mes publications sur ZDNet.fr : 

Bank of America : 1,5 milliards d'économies grâce à un cloud OpenCompute de Facebook

Cloud Computing : Le projet de serveurs x86 Open Source initié par Facebook devra permettre à Bank Of America d'économiser 50% de ces coûts d'exploitation informatiques à l'horizon 2018 en migrant 80% de ces applications sur son nouveau cloud privé en forme de “Software Defined Data Center”.

Bank of America est la 12ème banque mondiale avec 2.1 trillions de dollars d'avoirs sous gestion. C'est donc du lourd! Pour gérer les actifs de ces clients, elle effectue plus de 3 milliards de dollars de dépenses informatiques annuelles en 2014.

Eh bien, cette facture va diminuer : David Reilly, CTO responsable des infrastructures, se donne 3 ans jusqu'à 2018 pour passer 80% de ses applications sur une nouvelle infrastructure de cloud privé basée sur le projet OpenCompute (serveurs x86 dont le design est  “open source”) initié par Facebook. A travers, ce projet, la banque va créer un cloud privé à base de serveurs en marque blanche au design optimisé pour les nouveaux datacenters “hyperconvergés” où toutes les ressources (cpu, stockage, réseau, etc.) sont “as a Service”, provisionnées par API.

C'est donc un modèle canonique de “Software Defined Data Center” (SDDC) que Bank Of America prépare par cet ambitieux projet. Deux pistes sont retenues à ce moment pour garder toutes les options ouvertes : un cloud privé sur base OpenStack et une technologie interne.

Mais, ce n'est pas de l'art pour l'art : l'objectif officiellement affiché est une réduction des coûts d'exploitation informatiques de 50%! Les jours glorieux des grands fournisseurs de serveurs x86 qui trouvent une manne au sein du secteur financiers semblent comptés car le succès de ce projet fera nécessairement tâche d'huile.

Cet objectif de 50% est réaliste : Facebook a annoncé avoir économisé 1.2 milliards de dollars l'an dernier grâce aux serveurs construits sur base OpenCompute. Bien sûr sur le coût de ces serveurs mais aussi sur leur efficacité électrique : l'équivalent de l'énergie de 40'000 maisons individuelles et celui de l'empreinte carbone de 50'000 voitures ont ainsi été “sauvés” selon les récents propos de Mark Zuckerberg, le ceo de Facebook.

Pour Bank of America, l'atteinte de cet objectif permettra donc de réaliser 1.5 milliards de dollars.

Bien sûr, c'est déjà un but en soi ! Mais, ce gain pécuniaire reste très tactique. L'objectif beaucoup plus stratégique de la démarche est celui qui va servir le métier : la virtualisation complète offerte par un tel SDDC va offrir une flexibilité, une scalabilité et une agilité sans commune mesure avec l'architecture “physique” actuelle de la banque.

La réactivité du métier en sera ainsi maximisée. A une époque où le métier bancaire subit une évolution  permanente de sa réglementation et où la demande des clients se sophistique en permanence (mobilité, dématérialisation, etc.), les systèmes informatiques des grandes banques doivent se doter de moyens de suivre le rythme !
Source: blog Media and Tech (par didier durand)

vendredi, mars 06, 2015

CDO et transformation numérique : carnet des meilleures recettes (pratiques!)

Article repris de mes publications sur ZDNet.fr :

CDO et transformation numérique : carnet des meilleures recettes (pratiques!)

Cloud Computing : Inquiètes par l'arrivée des nouveaux entrants « Internet first » qui chamboulent la répartition des rôles sur le marché secteur après secteur, toutes les plus grandes sociétés nomment actuellement leur Chief Digital Officer qui doit apporter certes une vision stratégique mais aussi les bonnes recettes tactiques pour contrer cette déferlante. De bons principes techniques concrets existent, à chacun de les décliner dans son contexte.
GDF Suez, L'Oréal, Danone, ERDF ont récemment nommé leur Chief Digital Officer (CDO) comme 40% des sociétés du CAC40 et la plupart des grandes sociétés au monde. Ce nouveaux CxO est supposé être le catalyseur de la transformation vers le numérique en même temps que le rempart contre les nouveaux entrants qui font place nette sur leur passage.

En effet, les grands leaders des différents secteurs industriels ont vu leurs homologues d''autres domaines se faire “tondre” par des nouveaux entrants. Ces derniers ont pour première priorité d'exposer leur processus de vente, de production, de livraison via l'Internet au sens le plus large (PCs, tablettes, mobiles, etc.). Ils veulent ainsi être les plus efficaces et les plus transparents possibles pour attirer la plus large fraction de la demande potentiellement infinie générée par Internet.

On peut ici citer Amazon pour la vente par correspondance, Paypal pour les services financiers et plus récemment Uber pour les services de taxi. Ajoutez ensuite qui vous voulez selon votre secteur de prédilection.

Donc, las de voir leurs homologues décimés par la jeune génération et voulant éviter de subir le même sort, les grandes sociétés nomment leur messie pour éviter de passer à la trappe grâce aux bonnes méthodes de cet(te) homme / femme providentielle.

Au-delà d'une vision à long terme très éthérée, on attend du CDO des recettes tactiques concrètes qui font progresser efficacement le sujet de la transformation chez son employeur. 

La participation récurrente aux projets lancés lors de ces transformations numériques fait émerger, selon mon expérience, quelques meilleures pratiques techniques et méthodologiques que je veux détailler ci-après.

La fixation des bons objectifs est essentielle : le plus important est certainement le désenclavement. En effet, ces grandes sociétés ont toutes des systèmes historiques qui “font tourner la maison” au quotidien en gérant les processus de commande, fabrication, livraison. Ces systèmes sont le plus sont propriétaires (mainframes, etc.) donc peu flexibles et péniblement interconnectés avec les autres serveurs de la maison et l'Internet. Il est impératif de fixer un objectif ambitieux de transformation du système principal vers des technologies modernes et ouvertes qui lui permettront de participer ensuite directement et efficacement à l'ensemble des processus du métier qui seront exposés sur Internet.

Dans la même veine, la fluidité et la continuité de ces processus sont critiques. Il serait vain voire létal de donner une impression de grande fluidité des processus internes par une “vitrine” (le site Internet ou les applications mobiles) trop attirante et procurant un faux semblant de transparence et d'efficacité si l'interconnexion entre la vitrine et l'arrière-boutique (= le système de gestion) est ensuite essentiellement manuelle sous la responsabilité de “petites mains” qui ne peuvent qu'introduire erreurs et délais en copiant les informations entre les divers systèmes.

Après les objectifs (= le QUOI), vient le chemin pour les atteindre (= le COMMENT). A nouveau, de multiples projets nous ont procuré les expériences suivantes.

L'absence de risque est vitale : les systèmes à transformer sont massifs. Pour la seule utilisation interne, ils servent déjà des milliers d'utilisateurs. Il est impensable pour tout CDO digne de ce nom de proposer une approche “Big Bang” où l'héritage informatique est remplacé du jour au lendemain par un nouveau système. Nous voyons donc (et recommandons vivement !) régulièrement des transformations incrémentales où la charge de travail mainframe historique est mutée sur une période longue de plusieurs mois vers le nouveau système (cloud privé x86, etc.) : d'abord quelques utilisateurs pionniers puis une première vague plus consistante avant que le gros des troupes ne débarque sur le nouveau système qui aura ainsi été purgé de ses problèmes de jeunesse en gênant la productivité au minimum.

La fluidité et l'homogénéité vont de pair avec la sécurité : les processus doivent rester efficaces tant pour les éclaireurs pionniers que pour les autres collaborateurs avec lesquels ils échangent dans le pilotage des processus dont ils sont responsables. En clair, le nouveau système et l'ancien ne peuvent être disjoints : ils doivent partager leurs données en temps réel autant en lecture qu'en écriture et si possible à travers une seule et même base de données (pour éviter les « machines infernales » de synchronisation bidirectionnelle...). C'est la condition sine qua non d'une transformation sans heurts nu perte de contrôle.

L'efficacité doit continuer à primer : la transformation numérique emmène la société davantage vers le monde de l'Internet où les marges financières et les délais de réaction sont toujours plus étroits. Donc, la vie en parallèle de l'ancien et nouveau système pendant la longue période de transition nécessaire à la sécurité (voir plus haut) ne doit pas nécessiter la maintenance à double des 2 systèmes (anciens et nouveau): l'un doit dériver automatiquement de l'autre. C'est en général le nouveau système qui est construit automatiquement à partir du système historique. En particulier, durant la transition, les changements apportés au système historique doivent pouvoir être automatiquement reportés sur la nouvelle plates-formes. C'est le chemin en général le plus naturel.

La cible doit être soignée : la plate-forme technologique du nouveau système doit offrir tous les gages d'un système moderne en termes d'agilité, de flexibilité, de scalabilité. Notre expérience est qu'il souvent ici souvent favorable de se mettre dans le sillage des gorilles de l'Internet (Google, Facebook, Amazon, etc.) en copiant leurs meilleures pratiques voire en utilisant les technologies qu'ils publient en Open Source sur Internet. Ces sociétés n'ont pas eu à faire de transformation numérique : elles sont néés avec l'Internet et en représente certainement les formes canoniques, voire l'ADN. Elles ont donc forcément vu juste  dans l'élaboration de leur système informatique car il est le composant essentiel de leur structure interne.

L'architecture doit être ambitieuse : quand on les expose sur Internet, le volume de traitement des systèmes de gestion peut exploser brutalement car la demande (au moins en informations) peut brutalement devenir colossale. Il faut donc travailler ici aussi à la mode des gorilles du Net : un composant de base (serveur x86) de taille modeste mais “empilable” à volonté et par tout petit incrément afin de ne pas avoir en entrer dans des « branle-bas de combat décisionnels » interminables à chaque besoin d'augmentation de capacité. Empiler de nouveaux serveurs coûtant quelques milliers d'euros est très simple à mettre en oeuvre, beaucoup plus que l'achat d'une seule machine coûtant plusieurs millions ! C'est un mode de développement “biologique”  tout à fait conforme à la vision d'évolution organique de l'Internet. Quand on veut basculer vers un nouveau paradigme autant aligner son mode de fonctionnement sur celui de l'étalon !

Ce livre de recettes peut sûrement être encore étoffé mais son application garantit déjà une transformation numérique très réussie. Il est bien sûr nécessaire de trouver à ces ingrédients génériques leur déclinaison pertinente dans un contexte particulier : la petite épice supplémentaire qui laisse un souvenir impérissable à tous ceux qui y goûtent ...
Source: blog Media and Tech (par didier durand)

Etude Ubuntu - Le cloud pour les applications critiques d'entreprise: avec prudence et tout en douceur !

Article repris de mes publications sur ZDNet.fr :

 Etude Ubuntu - Le cloud pour les applications critiques d'entreprise: avec prudence et tout en douceur !



Analyse : Canonical publie la 6ème édition de son enquête annuelle sur le cloud computing. En synthèse, les entreprises basculent vers cette « énergie informatique unifiée» mais à leur rythme, donc sans précipitation ni risques.
Canonical, l'éditeur d'Ubuntu vient de publier les résultats de sa 6ème enquête annuelle sur le Cloud et les serveurs. Elle met en avant des résultats logiques et sans surprise, basés les réponses de 3'100 sociétés utilisatrices. Ils sont sans surprise pour moi car très cohérents avec les dires des nombreux CIOs que je rencontre quand ils cherchent un chemin de transformation incrémental, donc dénué de tout risque, vers le cloud pour les applications critiques à leur métier sur mainframe.

En effet, l'étude Ubuntu démontrer un fort progrès de la pénétration des technologies de cloud computing mais avec un avantage net pour le cloud privé : le cloud privé est le segment dominant actuel avec 35.5% des installations et représente plus de 51% des projets prévus à 12 mois. Le cloud hybride représente 40% des nouveaux projets. Au total, 55% des répondants s'attendent à une forte hausse de l'usage du cloud dans leur société, toutes formes confondues.

L'addition des projets privés et hybrides démontre clairement qu'il existe une partie de leurs applications que les utilisateurs de cloud ne souhaitent à ce moment pas exposer sur des clouds publics. L'analyse Canonical donne une partie de la réponse : la sécurité et la protection des données avec 35% représentent le premier obstacle à une adoption plus massive.

Mais, selon les visions des CIOs que je rencontre, il y a une autre raison : l'application de l'adage jamais démenti “déléguer sans contrôler, c'est abdiquer”. Ils sont donc nombreux à vouloir maîtriser et dominer la technologie cloud par une prise de compétences interne avant de transférer la gestion de leur “énergie informatique” à un prestataire afin de pouvoir garder le système sous contrôle malgré tout quand ils ne le piloteront plus directement.

Il est donc logique de débuter le voyage vers le cloud par le transfert de ses applications par une mise en place interne. De plus, à travailler “derrière le rideau”, on peut faire plus discrètement donc avec moins de visibilité toutes les petites bourdes inhérentes à un tel apprentissage lorsque l'on transfère ses serveurs vers son cloud interne.

De plus, dans les situations de transformation massive d'applications critiques, par exemple mainframe vers x86, situations qui m'occupent le plus souvent, le passage par un cloud privé est la première étape obligée : elle permet, par une méthodologie et des processus de transformation idoine, une migration extrêmement incrémentale donc une transition fluide et sans risque vers les technologies cloud.

Quand son cloud privé est rôdé, le client peut ensuite envisager sereinement une seconde étape plus simple : celle du cloud hybride souvent mis en œuvre pour gérer les besoins en débordement de capacité ou l'accueil des applications naturellement affines avec le cloud public, comme les sites web, les serveurs de messagerie, etc. Pour ce cloud privé, OpenStack, lancée conjointement en 2010 par RackSpace et la Nasa,  a le vent en poupe : il est leader avec un quart des installations. 65 % des répondants juge cette pile logicielle comme apte à l'hébergement et à l'exploitation des applications critiques à leur métier.

Ce sont la jeunesse de la technologie, ces barrières sécuritaires actuelles et les étapes préliminaires (création de l'infrastructure interne « solide ») qui explique en partie la répartition actuelle des utilisations du cloud selon Canonical:
 2015-01-30-cloud-survey
Il est encore finalement fort peu utilisé pour les applications critiques même si les répondants le jugent apte : ils doivent encore apprendre à s'en servir correctement au quotidien pour assurer le bon niveau de disponibilité et de performances.

Enfin, Canonical donne un autre résultat sans surprise : Amazon AWS et Google Cloud se taillent la part du lion dans le marché du cloud public à ce avec 21 + 30 = 51 % des utilisations. Microsoft Azure, HP Cloud et IBM SmartCloud suivent loin derrière avec un total d'environ 10 % pour eux trois réunis ! Mais, toutes les cartes ne sont pas jouées dans ce marché ! Au contraire, les entreprises ont encore les atouts-maîtres (= les applications critiques) dans leur jeu : elles les joueront en toute sécurité après la prise de compétences interne préalable nécessaire.

Les fournisseurs traditionnels de l'entreprise que sont HP, IBM et Microsoft peuvent alors espérer combler leur retard grâce à ce créneau du « haut de gamme » certainement le plus susceptible de produire les meilleures marges. Mais, il ne faut pas mollir car les « gorilles du web » apprennent vite à travailler avec les grandes sociétés : ils adaptent leur offre à vitesse grand V (solutions privatives, infrastructures spécifiques, contrats particuliers, etc.) pour transformer leurs services cloud de leur forme initiale de commodité vers le haut de gamme qui sied aux applications essentielles à l'entreprise...
Source: blog Media and Tech (par didier durand)

Mainframe IBM z13 : puissance intrinsèque maximale ou myriade ?

Article repris de mes publications sur ZDNet.fr :

Mainframe IBM z13 : puissance intrinsèque maximale ou myriade ?

Business : Le nouvel IBM z13 cible très clairement les forts besoins de puissance de ses plus grands clients, créés par une croissance exponentielle des transactions depuis les mobiles. Il relance ainsi le débat architectural créé par les « gorilles » du web et le Cloud Computing : architecture de myriade ou puissance intrinsèque unitaire maximale ?
IBM a annoncé son nouveau mainframe, le z13. Il bénéficie naturellement des progrès de la loi de Moore comme toute gamme de matériel par rapport à ses générations précédentes: plus rapide et plus puissant ! Jusqu'à 10 TB de mémoire centrale, 320 canaux d'entrées/sorties parallèles, 141 coeurs de traitement distincts, etc. Le prix de cette bête de course n'a pas été divulgué.

Il est bienvenu pour les plus grands clients d'IBM :
  • Un mainframe unique est toujours plus simple et efficace que plusieurs machines couplées à travers la technologie Sysplex d'IBM très sophistiquée, toujours délicate à mettre en oeuvre à très grande échelle. Il résout donc ce problème pour les clients qui commençaient à épuiser leur machine de la version précédente.
  • Cette annonce représente un signe fort de Big Blue dans sa volonté de continuité sur la plate-forme mainframe. Ainsi est réduite l'inquiétude que le transfert de la production des processeurs mainframe (en tant que membre de la gamme Power qui sert aussi les AS/400, les machines AIX, etc.) vers Global Foundries avait généré chez les clients historiques qui pouvaient se sentir “lâchés” pour certain. Ils sont aujourd'hui rassurer : IBM poursuit ses engagements avec les Systèmes z. Les esprits chagrins diront bien sûr que cette annonce est le fruit d'un travail bien antérieur à la décision Global Foundries et que la pérennité reste donc encore à prouver.
Il est également bienvenu pour IBM :
  • A l'occasion de cette annonce, les consultants Bernstein Research estiment que IBM tirent plus de 25 % de son chiffre d'affaires, soit environ 25 milliards de dollars annuels, et 35 % de ses bénéfices opérationnels de ce marché. C'est donc un segment vital pour le constructeur : sa pérennité passe nécessairement par le renouvellement de la gamme pour générer de nouvelles ventes et répondre aux besoins de clients. L'annonce arrive à point nommé : IBM avait annoncé une chute des ventes de 35 % sur le matériel du créneau mainframe au 3ème trimestre 2014.
  • Une telle « machine » (le créneau mainframe) à générer du chiffre d'affaires et du bénéfice est stratégique pour permettre à Big Blue de réaliser / financer en souplesse la transition vers le Cloud Computing et les services qui sont clairement les 2 axes stratégiques du constructeur qui veut se désengager progressivement de ses domaines historiques. C'est pour cela qu'IBM a investi plus d'un milliard de dollars dans le développement du z13 en y injectant aussi beaucoup de matière grise (500 brevets appliqués à cette machine).
  • Le z13 apporte une solution aux clients fidèles en quête de puissance additionnelle et de services matériels spécifiques (encryption en temps réel, traçabilité intégrale de chaque transaction, etc.) pour servir les nouveaux besoins de capacité exponentiellement croissants sur le secteur mobile.
La sortie de cette machine va clairement relancer le débat dans les grandes sociétés traditionnelles : doivent-elles poursuivre leur croissance informatique au niveau de leurs applications métier critiques par l'emploi de « boîtes » en nombre réduit mais toujours unitairement plus puissantes ou doivent être adopter la stratégie de la « myriade informatique » ?

Cette stratégie de la myriade est clairement validée par les plus grandes stars de l'Internet : Google, Amazon, Facebook, Twitter…

Ces « gorilles » de l'Internet n'envisagent leurs systèmes que composés de centaines de milliers de petites machines x86 très standards. Leur couplage permet de délivrer la puissance nécessaire jusqu'à des niveaux qui dépassent de loin la puissance fournie par les plus gros mainframes de la planète ! L'architecture intelligente ce couplage permet d'atteindre ensuite une disponibilité sans faille (ou presque…) et de croître avec une granularité infinitésimale donc très souplement.

Certaines très grandes sociétés ont déjà entamée leur transformation vers ces myriades de machines servant de base matérielle redondante à un système cloud privé (CloudStack, OpenStack, etc.) permettant de traiter très efficacement la problématique de la gestion opérationnelle efficace d'une multitude de machines. Elles y migrent progressivement leurs grandes applications métier critiques selon des méthodologies idoines permettant une transformation incrémentale et fluide. Elles espèrent ainsi obtenir les mêmes bénéfices que les « gorilles » : efficacité économique maximale, rendement énergétique optimal, croissance extrêmement fluide. Elle veulent aussi tirer le meilleur parti du « bouillonnement innovatif » tant matériel que logiciel généré par ces nouvelles architectures.

Cette annonce du z13 d'IBM, clairement ciblée vers les applications mobiles qui sont à la fois la joie (nouvelles opportunités de services) et la plaie (croissance explosive souvent délicate à gérer) offre une alternative au Cloud Computing standard sur base x86 et va donc entretenir le débat sur la meilleure architecture pour servir ces nouveaux besoins.

Les gagnants ultimes, les clients bien sûr ! A eux de choisir entre la myriade et son opposé, voire de les marier. En fonction de leur contexte spécifique.


Source: blog Media and Tech (par didier durand)

vendredi, novembre 28, 2014

eCobertura : installation du code coverage sur les dernières versions d'Eclipse (Luna)

Chez Eranea, nous patriquons massivement la capture de scénarios de tests qui sont ensuite régulièrement rejoués pour valider la non-régression de nos transcodages récurrents de Cobol.

Notre outil spécifique de capture / replay dual (capture 3270 + replay web) de ces tests est détaillé ici :




Un des points-clefs autour de ces scénarios est la qualification de leur pertinence.

Pour ce faire, nous utilisons dans Jenkins, Eclipse, etc. des outils de code coverage : ils nous permettent de voir quelles lignes du Java produit par transcodage du Cobol sont exécutées ou non lors du replay des tests.

Ainsi, la pertinence des tests et donc leur qualité n'est plus subjective mais quantifiée : "l'exécution de l'ensemble des tests couvre 85% du code applicatif".

C'est d'ailleurs abondamment utilisé par nos clients qui définissent ainsi leur stratégie de test: "nous allons capturer des tests jusqu'à un taux de couverture applicative de 90%". 90% est d'ailleurs souvent le seuil retenu car le 100% est quasi-toujours inatteignable : il correspond à des conditions très particulières d'exécution qu'il n'est pas forcément aisé de reproduire lors de tests.

Et d'ailleurs, ce n'est pas notre but lors de projets de migration : il s'agit "seulement" de valider le transcodage iso-fonctionnel vers Java du Cobol. Ce serait donc bien le diable si des syntaxes Cobol très pointues n'étaient utilisées que dans un fragment minuscule et très rarement exécuté de l'application. On travaille habituellement sur des millions de lignes de code donc par effet statistique, toutes les constructions syntaxiques à valider se trouvent de toute façon aussi dans la zone couverte par les tests.

En particulier, pour le code coverage, nous utilisons Cobertura.

 Je viens de basculer mon laptop (Ubuntu Trusty Tahr 14.04) à la dernière version d'Eclipse, nom de code Luna.

Au moment de réinstaller le plugin ECobertura pour avoir accès aux rapports de taux de couverture de code, Eclipse refuse de l'installer avec le message :

"Cannot complete the install because one or more required items could not be found. Software being installed: eCobertura 0.9.8.201007202152 (ecobertura.feature.group 0.9.8.201007202152)

Missing requirement: eCobertura 0.9.8.201007202152 (ecobertura.feature.group 0.9.8.201007202152) requires 'org.junit4 0.0.0' but it could not be found"

La solution à ce problème est donnée sur Stackoverflow :

  1. stopper Eclipse
  2. trouver via Google et descendre le jar manquant de JUnit org.junit4_4.8.1.v20120523-1257.jar (il est partout...)
  3. le placer dans la directory /plugins d'Eclipse
  4. redémarrer Eclipse
  5. relancer l'installation d'eCobertura qui doit maintenant aller au bout.
Maintenant à vous les mesures de qualité sur vos tests unitaires !


Source: blog Media and Tech (par didier durand)

mardi, octobre 21, 2014

Connexion JDBC MS-SQL Server bloquée = bug dans Java JRE 1.6 révision 29

On peut passer parfois beaucoup de temps à tenter de comprendre un programme Java qui est supposé juste mais qui ne fonctionne pas sans symptôme explicite (exception, code erreur, ...)

Je viens de passer un petit moment sur une connexion Java  / JDBC depuis mon Linux vers une instance Amazon RDS qui "coinçait" sans donner aucun détail. Juste un blocage avec "trou noir"-

Eh bien, ça venait de mon runtime Java : le JRE 1.6 révision 29 de Sun était le coupable. Un upgrade à la révision 45 et ça repart !

J'espère que cela servira à d'autres pour ne pas perdre du temps.

C'est confirmé par ce billet sur StackOverflow : http://stackoverflow.com/questions/8986350/jdbc-connection-hangs-with-no-response-from-sql-server-2008-r2.

Pour moi, cela se passe aussi avec Sql Server 2011.

Source: blog Media and Tech (par didier durand)

vendredi, octobre 17, 2014

Ubuntu 14.04 : dysfonctionnement de galternatives - correction

J'avais écrit que mon update à Ubuntu 14.04 s'était bien passé et qu'il m'avait quand même beaucoup apporté

J'ai quand même découvert un souci aujourd'hui : un bug au niveau du programme 'galternatives' qui ne fonctionne pas après l'update. Je ne peux, par exemple,  pas changer ma version de Java par  défaut : galternatives reste bloqué sur la version antérieure et impossible de passer de java7 à java8 pour des tests sporadiques par exemple.

C'est un problème connu sur les 2 dernières versions d'Ubuntu : il est détaillé à
https://bugs.launchpad.net/ubuntu/+source/galternatives/+bug/1309709

La solution est simple : faire un lien symbolique vers le fichier manquant par la commande ci-après.

sudo ln -s /usr/bin/update-alternatives /usr/sbin/

et c'est reparti comme avant. J'aurais pu écrire "comme en 14"(.04) mais c'eût été trop facile ... ;-)

Source: blog Media and Tech (par didier durand)

mardi, septembre 09, 2014

Passage à Ubuntu 14.04 "Trusty Tahr" : sans douleur - plus de stabilité et de performances

Ma station de travail professionnelle est sous Ubuntu depuis 4 ans : chez Eranea on installe nos applications Cobol converties automatiquement à Java en très vaste majorité sur cet OS.

Donc, pour me mettre en "immersion totale" et augmenter mes connaissances de cet OS, je travaille en permanence sur cet environnement. Ubuntu était à l'époque la distribution la plus similaire à MS-Windows. Je l'ai donc choisie.

Sur mon dernier laptop Dell Précision M6600 (équipé de 16 GB de RAM et 512 GB de disques SDD), j'étais jusqu'à ce week-end en 12.04 LTS d'Ubuntu.

Au fil de la maintenance encore assurée (LTS = Long Term Support), ma machine est devenue instable en particulier l'affichage qui partait en vrille 1 à 2 fois par jour, nécessitant un reboot.

En parallèle, Ubuntu 14.04 est devenue "GA" (General Availability) après 4-5 mois de tests en grandeur nature depuis sa sortie. Elle s'appelle "Trusty Tahr" = "le Tahr de confiance". Un Tahr, c'est une sorte de chève sauvage. Je l'ai appris grâce à Ubuntu: j'adore leur choix de nom !

J'ai donc migré vers elles le week-end dernier : le processus s'est fait sans aucun souci ! Tous les drivers (écran haute résolution, disques SSDs, etc.) sont installés correctement et la machine fait son reboot final comme une fleur.

Ce processus est juste un peu long donc à prévoir en fin de semaine quand on a moins besoin de sa machine et qu'on peut la laisser bosser pour se mettre en jour en repassant de temps en temps devant pour répondre aux quelques questions de (re)configuration qui parsèment le processus.

Résultat atteint = résultat souhaité:
  • les Unity et autres modules d'affichage sont réalignés en terme d'âge sur le noyau. La stabilité de Linux qui n'est si chère est donc revenue ! Plus aucun reboot.
  • on ressent un vrai gain en performances / temps de réponse sur le laptop : sûrement dû à un noyau très récent
  • des applications au niveau le plus récent : un nouveau LibreOffice avec plein d'améliorations sympas et utiles
Donc, le jeu en vaut la chandelle ! Un backup de ses données avant de commencer reste impératif...

Sinon, j'ai une machine complètement nouvelle en termes de versions des paquets: 1.6 gigaoctets de logiciel nouveau à télécharger. Voici ce qu'Ubuntu m'a annoncé avant de démarrer :

"Some third party entries in your sources.list were disabled. You can
re-enable them after the upgrade with the 'software-properties' tool
or your package manager.

94 packages are going to be removed. 896 new packages are going to be
installed. 2436 packages are going to be upgraded.

You have to download a total of 1,623 M. This download will take
about 3 hours 26 minutes with a 1Mbit DSL connection and about 2 days
14 hours with a 56k modem.

Fetching and installing the upgrade can take several hours. Once the
download has finished, the process cannot be canceled". 


Dernier point : la mise à jour va désacitver les sources logicielles tierces autres que celles de Canonical qui distribuent le système de base. Il faut donc les réactiver après la mise à jour du système d'exploitation.

Source: blog Media and Tech (par didier durand)

vendredi, août 15, 2014

processeur Risc Sparc M7 : 10 milliards de transistors sur une puce !

Sun vient d'annoncer sa dernière génération de processeurs RISC Sparc : le Sparc M7 (livré en 2015).

La première chose à reconnaître, c'est que Larry Ellison tient parole : quand il avait dit au rachat de Sun par Oracle qu'il "avait vu la lumière" et qu'une des fortes motivations du rachat était la propriété intégrale du processeur Sparc pour assurer l'indépendance future d'Oracle, personne ne le croyait !

En particulier, il avait dit: "Nous n'entrons pas dans le business du matériel. Nous nous n'y attachons aucun intérêt. Nous avons par contre un  profond intérêt pour le domaine des systèmes intégrés". On pensait qu'il n'en voulait en fait qu'au logiciel de Sun, en particulier Java vu son adoption forte dans les entreprises. Eh bien, Larry a tenu largement parole: le M7 est la sixième génération de Sparc produite par Oracle depuis l'acquisition.

Cette nouvelle génération donnera bien davantage de puissance brute de calcul à la gamme des systèmes intégrés Exa (fonctionnant sur Sparc) livrés par Oracle depuis le rachat. Mais, surtout, elle permet aussi à Oracle grâce à  ce statut de "fondeur" de silicium acquis via Sun de mettre des fonctions spécifiques au traitement des requêtes de bases données ("query accelerator") ou à celui du langage Java ("garbage collection") directement au niveau du processeur pour optimiser le fonctionnement du logiciel.

Oracle estime que le boost de performances fourni par cette puce par rapport à son grand frère Sparc M6 est le suivant pour différents types de banchmarks :



Je trouve personnellement fascinant que la loi de Moore continue à rester valide presque 50 ans (grâce à la réduction permanente et rapide de la taille des transistors)  après sa proclamation : le M7 lui fait passer un jalon marquant avec 10 milliards de transistors sur un seul chip

Si je fais bien le calcul, on devrait dépasser les 100 milliards de transistor sur un chip à moins de 10 ans : Intel comme Oracle annoncent des processus de fabrication pour le 5 nanomètres alors que nous en sommes à 20 nanomètres pour l'instant. Donc un potentiel d'augmentation de (20/5) = 4 au carré (puisqu'on travaille sur une surface) soit un facteur 16 encore devant nous. Pas mal de chemin parcouru depuis le million de transistors du 80486 il y a 25 ans ou les 100 millions il y a moins de 10 ans !

La concurrence est dans le même ordre de grandeur : IBM à 4.2 milliards avec le Power8 récemment annoncé, Intel à 4.3 milliards de transistors par chip pour ses derniers Xeon E7 8890 v2.

Ce processeur M7 est donc une bête de course, et plutôt dans la catégorie Formule 1!  Il s'adresse cependant à un segment très restreint : le haut du panier des 155'000 serveurs Risc vendus chaque année, un marché sûrement juteux (fortes marges) mais bien petit comparé aux 10 millions de serveurs x86 vendus annuellement.

La tendance architecturale des dernières années est poursuivie sur le M7: la fréquence d'horloge n'augmente plus vraiment sinon la consommation électrique et les calories dissipées explosent de manière exponentielle! C'est le parallélisme qui augmente grâce aux transistors supplémentaires : le M7 offre 32 cores pouvant exécuter autant d'activités distinctes de manière simultanée, voire même beaucoup plus puisque 8 threads logiciels distincts peuvent être traités sur chaque core matériel qui leur partage ses ressources ("dynamic threading").


Chez Eranea, nous suivons l'évolution de ce marché des processeurs au plus près :
  • la beauté de Java (au coeur de notre technologie de migration) est d'être parfaitement agnostique au processeur (elle redéfinit ses propres instructions et son modèle mémoire : le fameux Java bytecode)  donc totalement portable : les applications Cobol /  mainframe que nous transcodons vers Java peuvent donc être exécutées - si leur taille ou la puissance de calcul nécessaire le justifient - sur le processeur le plus puissant du moment. Ce processeur peut évoluer dans le temps (RISC, x86) d'un fournisseur à l'autre sans que cela ne pose de questions / soucis particuliers : encodage des données, jeu d'instructions, opération de bas niveau.... Le "Write Once, Run Anywhere" (WORA) de Java est un atout précieux ! Nous l'expérimentons souvent sur des OS divers comme Linux, AIX, Windows, Solaris, etc.
  • de très grandes sociétés avec des systèmes transactionnels de très grande taille (plus de 1'000 transactions par seconde) analysent des migrations par transcodage vers Java de leurs applications métier critiques. Il est rassurant pour elles de savoir que la course à la puissance brute se poursuit chez les constructeurs même si les architectures par scalabilité horizontale (basées sur plus de serveurs moins puissants ) que nous prônons permettent d'aller elles aussi très très loin. Avoir des alternatives est toujours rassurant et sain !
Le fun ultime, c'est de se dire que cette puissance de calcul monstrueuse va bien finir par se retrouver dans notre poche (d'ici des années quand même...) sur notre téléphone mobile.

Gageons que les développeurs d'applications mobiles auront d'ici là trouvé les bons moyens, selon la prédiction de Carver Mead,  de "gaspiller ces innombrables transistors"  de manière "intelligente" afin que cet oxymore n'en soit finalement pas un  !

Source: blog Media and Tech (par didier durand)