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)