Une infrastructure prépackagée livrée clé en main

Dans une infrastructure convergente, les différents composants (serveurs, stockage, réseau, sécurité) sont considérés comme des ressources interopérables gérées par une plate-forme commune : un moteur de services partagés. Ces infrastructures donnent la possibilité d’assembler ou de désassembler un pool de ressources à la demande pour ajuster au mieux le dimensionnement de l’ensemble du socle technique aux besoins réels d’une application. L’infrastructure est alors facilement scalable en cas d’augmentation de la charge.

Avec ce type de solutions, plutôt que d’assembler des composants individuellement, le client peut maintenant acheter un « bloc » de composants dans une offre prépackagée et préconfigurée par le fabricant. Ces offres sont généralement déclinées en plusieurs niveaux différents ayant chacun un dimensionnement spécifique et contenant plus ou moins de modules. Selon le besoin, le client peut ainsi choisir une offre « standard » (des serveurs d’application avec prise en charge du stockage et mise en réseau par exemple), ou opter pour une offre « haut de gamme » donnant accès en plus à des mécanismes intégrés de redondance.

Par ailleurs, à la différence des mécanismes de virtualisation serveurs, les infrastructures convergentes permettent une virtualisation de bout-en-bout d’une architecture en couvrant plusieurs types de composants, du matériel au logiciel.

Les infrastructures convergentes, un gain en efficacité et en productivité

Les systèmes d’information de nos clients sont souvent constitués de plusieurs outils  hétérogènes complexifiant le déploiement de nouvelles infrastructures. Avant même de commencer l’installation des composants applicatifs, un temps non négligeable est consacré aux phases amont d’évaluation des ressources, d’installation du matériel, d’intégration des serveurs et des périphériques. Cette étape amont est à la fois gourmande en temps et en ressources, pour une valeur ajoutée métier faible. En proposant la construction d’une infrastructure opérationnelle à partir d’une pile d’éléments pré-intégrée et pré-testée, les infrastructures convergentes réduisent considérablement la durée de cette phase.

Outre le gain de temps, les solutions d’infrastructures convergentes permettent un suivi centralisé et outillé des composants du SI. En effet, elles consolident plusieurs outils de supervision en une seule console assurant la gestion intégrale de l’environnement du datacenter. Les administrateurs sont alors capables d’avoir une vision globale du SI, d’orchestrer les différentes briques de manière optimale en éliminant les tâches manuelles, à la fois fastidieuses et génératrices d’erreurs.

La convergence au détriment de la souplesse du SI

Si les solutions d’infrastructures convergentes semblent séduisantes, elles exigent néanmoins un pilotage et une organisation sans faille des ressources, ce qui est possible lorsque l’ensemble de la pile est non seulement convergent, mais également administré à partir d’un cadre unique englobant à la fois les infrastructures physiques et virtuelles.

De plus, pour conserver un catalogue de services diversifié, les DSI ne souhaitent pas « s’enfermer » dans un modèle mono-fabricant sur tout ou partie des couches de leur infrastructure.

Par conséquent, un des enjeux des fabricants de solutions d’infrastructures convergentes reste à gérer la combinaison de différentes solutions (physiques ou virtuelles) de plusieurs fabricants pour mieux répondre aux attentes réelles des hébergeurs et des entreprises disposant de salles hétérogènes.

Accélérer les déploiements mais à quel prix ?

En gestion des infrastructures, la convergence n’est plus seulement une possibilité technologique mais devient un véritable facteur de productivité. Le but ultime des solutions d’infrastructures convergentes est d’aboutir à un système unifié et géré depuis un point central ; une sorte d’ « appliance d’infrastructure » qui serait à la fois scalable et interchangeable. À terme, cette rationalisation permettra de répondre à des besoins de performance économique et de réactivité des outils informatiques.

Néanmoins, telle qu’elle est envisagée actuellement par les grands fabricants, la rapidité opérationnelle de ces infrastructures se fait au détriment de l’ouverture du SI et de son agilité. Sur le long terme, les limitations de ce type de solutions pourraient impacter l’évolutivité du SI et son adaptabilité à des besoins futurs.

Par ailleurs, les retours d’expériences montrent des difficultés dans la définition du partage de responsabilité entre les équipes des silos techniques traditionnels. Ces solutions demandant donc à revoir les organisations pour les aligner aux fonctionnalités fournies.

Pour conclure, la transition vers la convergence de l’infrastructure implique d’avoir des besoins très homogènes en technologie sans pour autant vouloir recourir aux offres cloud. De plus, une migration vers une infrastructure convergente doit être réalisée avec précaution en s’assurant de la réversibilité de la migration d’une part et de l’évolutivité de la solution d’autre part pour éviter les écueils des systèmes « fermés » (mainframes par exemple).

Cet article Infrastructures convergentes : stratégie du futur ou retour vers le passé ? est apparu en premier sur RiskInsight.

Qu’implique le déploiement automatisé ?

Un des avantages attendu est l’uniformisation des habitudes de travail de toutes les équipes ; cela implique inévitablement de changer ces au préalable les dites habitudes. Tous les acteurs des projets concernés sont affectés : MOE, MOA bien sûr, mais aussi les gestionnaires de services, les exploitants ou infogérants, et même les utilisateurs finaux qui participent aux tests. Ce changement d’habitude peut se faire progressivement, au fur et à mesure de l’implication pratique des équipes : d’abord la MOE et la MOA, et ensuite les autres équipes jusqu’à la production.

Pour que les habitudes deviennent uniformes, il faut aussi que la plate-forme de déploiement soit disponible en amont, prête avant que chaque équipe en ait besoin, et surtout qu’elle gère les fonctionnalités dont chaque équipe aura besoin.

Il peut aussi y avoir des aspects contractuels à traiter, notamment avec l’exploitant. Un exploitant qui facture à l’acte ne sera pas forcément enclin à coopérer à la mise en place d’un outil destiné à réduire drastiquement le nombre d’actes impliqués dans une installation !

Tout ceci implique qu’il faille un pilotage par le haut, et qu’il faut donc convaincre la direction du bien-fondé d’un projet de déploiement automatisé avant sa finalisation. Surtout dans un grand SI, il arrivera toujours un moment où la persuasion ne suffit pas, et il faudra imposer certaines façons de faire : ce n’est pas possible sans l’appui de la direction.

Le jeu en vaut-il la chandelle ?

Nous avons vu en première partie les gains qualitatifs et organisationnels qu’on peut attendre d’un déploiement automatisé : principalement une certaine indépendance vis-à-vis du réalisateur, une qualité technique maîtrisée, des déploiements rapides et sans risque, des habitudes communes à toutes les équipes. On aboutit ainsi à la possibilité de mettre en place des cycles rapides, avec peu de friction technique dans les allers-retours entre l’expression d’un besoin et sa mise en œuvre effective.

On reconnaît ici un aspect facilitateur d’un des principes de l’agilité : l’acceptation du changement. S’il est simple de mettre en œuvre des modifications (ce qui ne préjuge pas de la complexité de réalisation des modifications), si la distance entre un projet tel qu’il est sur le poste d’un développeur et le même projet livré de façon à être utilisable par les équipes de recette, c’est un élément de friction en moins pour des itérations rapides dans le processus de développement. La maîtrise de la qualité, notamment par des tests automatisés, réduit de plus les risques liés aux changements, et accroît d’autant l’agilité du projet.

On reconnaît également des aspects d’une autre méthodologie : le mouvement devops. Traditionnellement les objectifs de stabilité du SI s’opposent aux besoins de changement ; le mouvement devops encourage la coopération entre équipes dans le but de réduire cette opposition. Le déploiement automatisé s’inscrit tout à fait dans cette démarche : avec le partage des habitudes, les changements apportés au SI tiennent compte des exigences d’exploitation dès le début, et la stabilité ne vient plus de l’absence de changement mais de la maîtrise de ses impacts.

Qui n’a pas rêvé d’un SI adaptable, où toutes les équipes travaillent ensemble pour le bien de l’entreprise ? Le déploiement automatisé ne répond pas à toutes les problématiques derrière ce rêve, mais il constitue un bon premier pas : même s’il s’agit d’un projet à forte teneur technique, ses avantages sont tangibles à la fois pour la direction SI et pour les métiers. Il ne reste plus qu’à trouver les bons acteurs !

Cet article Le déploiement automatisé : au delà des gains, quels en sont les enjeux ? est apparu en premier sur RiskInsight.

Le déploiement automatisé : une évolution naturelle

Le déploiement automatisé, c’est l’utilisation d’une infrastructure  permettant de déployer un livrable sur un environnement cible sans intervention humaine autre que le geste initiant le déploiement. Cela implique l’automatisation de tous les gestes techniques : préparation des plates-formes, mise en place ou mise à niveau de l’environnement de base, installation des composants de support des livrables, installation des livrables eux-mêmes. D’autres aspects doivent également être pris en compte : les migrations de données et la gestion de la disponibilité notamment.

Il s’agit typiquement d’une extension de plate-forme d’intégration continue (PIC) : une fois qu’on a un SI capable de produire des livrables de façon automatique, il semble logique de vouloir les installer de façon automatique. Au-delà de la production de livrables, une PIC permet également d’exécuter des tests automatiques ; avec des tests automatisés suffisamment poussés, on pourrait  même envisager de pousser le raisonnement encore plus loin, jusqu’au déploiement en continu… Mais nous n’en sommes pas là, revenons plutôt à notre déploiement automatisé !

La plate-forme d’intégration continue, source de nombreux bénéfices

Commençons par quelques-uns des avantages d’une PIC, puisque le déploiement automatisé repose généralement dessus.

La maîtrise des sources. L’intégration d’un projet dans une PIC nécessite ses codes sources. Le fait de passer par un outil que vous hébergez pour produire les livrables vous garantit de disposer des sources correspondant aux livrables installés, et de modifier les sources et produire de nouveaux livrables, même sans le support de la MOE à l’origine du projet.

La maîtrise de la qualité. Puisque vous disposez des sources, il est possible de les auditer, et généralement une PIC propose un certain nombre d’outils appropriés. Ceci permet de mesurer la qualité du projet, si ce n’est de la maîtriser, avec notamment des tests automatisés et des métriques paramétrées selon vos normes.

L’indépendance. Cette double maîtrise du processus de construction et du code du projet permet une réversibilité plus simple, et donc une certaine liberté vis-à-vis du réalisateur.

6 bonnes raisons d’adopter le déploiement  automatisé

Il est vrai que  le déploiement automatisé apporte ses propres avantages.

1 – Des déploiements sans risque. Un déploiement automatisé est reproductible, sans intervention manuelle. Le risque d’erreur d’inattention ou d’imprécision dans les procédures d’installation et leur mise en œuvre s’en trouve fortement réduit.

2 – Des déploiements rapides. Sans intervention manuelle, on évite les temps d’attente : vérifications d’informations, saisies, procédures de contrôle manuel… On peut en outre paralléliser un grand nombre d’opérations, entre plusieurs serveurs et au sein d’un même serveur. Les temps d’installation sont réduits, et par conséquent les indisponibilités des applications lors des mises à niveau.

3 – Des habitudes communes. L’utilisation d’une seule procédure de livraison pour toutes les plates-formes permet d’imposer des habitudes de travail communes à toutes les équipes, du développement à la production. Ceci réduit les risques au passage d’un environnement à l’autre et permet aux différents intervenants de partager un vocabulaire commun.

4 – Des cycles rapides. Avec des déploiements rapides et peu risqués on peut envisager des mises  à jour fréquentes  des applications installées. Le gain dès les phases de développement et de recette est conséquent : d’une part les cycles développement-recette-intégration ont un coût d’installation plus faible à amortir, et peuvent dès lors être raccourcis ; et d’autre part les corrections en recette peuvent être vérifiées immédiatement, ce qui réduit aussi les cycles détection-correction-vérification des défauts.

5 – Des installations déléguées. Si l’outil de déploiement est accessible à tous, ce qui ne représente pas nécessairement un risque puisque les droits sur les environnements cibles peuvent être cloisonnés, la gestion des déploiements peut être déléguée. Ainsi,  en phase de recette la MOA peut provoquer des installations, sans impliquer les équipes de développement, d’intégration ou d’exploitation.

6 -Plus de sauvegardes ! Une fois qu’un déploiement se fait sur un serveur vierge en quelques minutes, il n’est plus nécessaire de prévoir de le sauvegarder ! Tout serveur qui ne contient pas de données irremplaçables peut simplement être réinstallé en cas de désastre. L’installation d’un serveur complémentaire peut aussi être une réponse aux questions de tenue à la charge…

Si les gains sont considérables, les enjeux sont à étudier avec attention : cela fera l’objet d’un prochain article.

Cet article Le déploiement automatisé : optez pour des mises en production sereines ! est apparu en premier sur RiskInsight.

Le concept de virtualisation existe depuis plus de 40 ans (avec les mainframe et systèmes IBM), mais s’est véritablement démocratisé dans les années 2000 lorsqu’il est devenu possible d’exécuter simultanément plusieurs systèmes d’exploitation sur un même poste de travail. C’est essentiellement grâce à la virtualisation système (Microsoft, VMware) qu’il est aujourd’hui connu et son succès a atteint des sommets avec le développement du « cloud computing » (Amazon, Google Apps…).

La virtualisation consiste à faire fonctionner sur une machine physique unique plusieurs systèmes comme s’ils fonctionnaient sur des machines physiques distinctes. Ceci repose sur un concept simple : des instances virtuelles sont orchestrées par un hyperviseur, garant de l’accès, la répartition des ressources et l’isolation entre les instances.

La virtualisation doit avant tout son utilisation aux gains financiers qu’elle apporte en favorisant la consolidation des infrastructures et l’optimisation des ressources utilisées. Elle engendre en même temps des bénéfices opérationnels importants en permettant la mise en place rapide de solutions en haute disponibilité : le passage au « tout logique » apporte une facilité de déploiement et une souplesse de provisionning non offerts dans le monde physique.

En 40 ans, au vu de ces bénéfices, les technologies de virtualisation se sont orientées vers des utilisations diverses, s’étendant à d’autres composants du SI que les systèmes d’exploitation d’origine : postes de travail (sessions virtuelles, VDI…), réseaux (VDC, VRF…), équipements de sécurité (Firewalls, IDS-IPS…).

Des risques technologiques … à relativiser !

Les premières craintes des entreprises vis-à-vis de la virtualisation sont liées à la fiabilité des nouveautés technologiques impliquées : les nouveaux composants introduits, en particulier l’hyperviseur, me garantissent-ils l’étanchéité des systèmes supportés par une même machine physique ?

Il existe effectivement un certain nombre de vulnérabilités exploitables sur ces technologies… mais les risques associés sont finalement peu rencontrés : les technologies phares du marché sont des technologies éprouvées et ces risques peuvent être traités, comme pour tout système, par des mesures de gestion opérationnelles de la sécurité qui sont déjà en place dans les entreprises (patch management, durcissement…). Attention cependant ces processus doivent fonctionner avec efficacité vu l’impact en cas d’incident sur les infrastructures de virtualisation.

Des risques humains … à ne pas négliger !

Si les risques les plus courants de la virtualisation ne proviennent pas de la technique elle-même, ils se situent plutôt dans la gestion de ces nouvelles technologies. La virtualisation introduit dans le SI de nouveaux composants (hyperviseur, consoles…), de nouvelles notions d’infrastructure (réseau virtuel…) et les principaux risques de la virtualisation sont le plus souvent issus d’un défaut d’encadrement liés à ces nouveautés :

• Mauvais usage des consoles d’administration, avec des impacts immédiats « effet boule de neige » en cas de mauvaise configuration : arrêt multiple d’instances, activation de fonctions de décloisonnement…
• Mauvaises pratiques de gestion de la plate-forme de virtualisation, notamment sur les aspects de gestion des inventaires et de capacity planning qui doivent être redéfinis.
• Défaut de séparation des tâches entre les équipes système et réseau, avec tous les risques d’erreur, voire de malveillance, dus à la concentration de ces responsabilités.

Les risques « humains » (erreur, malveillance, absence de séparation des responsabilités) prédominent donc sur des risques « technologiques » relativement moins probables et pouvant être limités grâce à des recommandations classiques.

Un projet de sécurisation de la virtualisation, c’est donc bien entendu un projet d’intégration des nouvelles technologies dans la gouvernance opérationnelle de la sécurité pour traiter les risques techniques liés à son utilisation… Mais aussi et avant tout un projet de réflexion sur les rôles, les responsabilités et les compétences de ses administrateurs, afin de traiter les principaux risques de la virtualisation, à savoir les risques humains ! 

Cet article La virtualisation ne virtualise pas les risques humains ! est apparu en premier sur RiskInsight.

LGA (Lise Gasnier) : Le Big Data a une dimension “métier” évidente : pour les entreprises, le défi est d’identifier les opportunités de business offertes par leurs gisements de données. Déjà, des “business cases” montrent la faisabilité et l’intérêt d’exploiter des données jusqu’alors “non valorisées”. Il devient possible d’en extraire une information utile pour mieux connaître sa clientèle, optimiser son marketing, détecter et prévenir des fraudes, analyser son image sur les réseaux sociaux et la valoriser, optimiser ses processus…

En s’inspirant des initiatives innovantes de leurs secteurs, les entreprises pourraient initier la réflexion “Big Data” autour de 2 questions basiques :

• De quelles informations avons-nous besoin pour accroître notre efficacité et innover ?
• Quelles sont les données sous ou inexploitées à notre disposition?

Le Big data invite les métiers à plus de liberté, plus d’audace dans leurs réponses.

Dans ce domaine comme dans les autres, répondre à la première question et exprimer des besoins précis prend du temps. C’est, de plus, une question à poser en continu. D’évidence, les objectifs métiers exigeront de produire sans cesse de nouvelles analyses, sur des données déjà traitées (donc les “ré-analyser”) ou non, avec des sources et formats inédits.

Pour répondre à la seconde question, les métiers doivent connaître les sources de données à leur disposition et savoir interpréter les données brutes, pour en saisir la pertinence et en extraire l’information utile. Sur ce terrain technique, il est évidemment souhaitable que la DSI les accompagne. Elle doit par conséquent démontrer sa maîtrise des données du SI, au-delà de la “zone de confiance” des données gérées dans les systèmes de base de données traditionnels de l’entreprise.

MMI (Mathieu Millet) : Pour la DSI, tout l’enjeu va donc être de pouvoir traiter la volumétrie et l’hétérogénéité des données pour ouvrir le champ des possibles aux métiers. Pour anticiper des besoins que les métiers ne savent pas exprimer aujourd’hui, elle doit se doter d’une architecture permettant d’emblée de collecter, stocker et analyser “plus” et “plus varié”. C’est bien d’une architecture agile que les métiers ont besoin.

Une approche initiale serait d’imaginer ce que serait son système Big Data en proposant quelques cas d’usage sur un « échantillon » représentatif de données, à la fois structurées (comme celle que l’on trouve dans les entrepôts de données) et semi-/non-structurées (logs d’applications, messages sur les réseaux sociaux, documents bureautiques, utilisation des données issues de l’Open Data…). Cette “promotion” du service permettrait ainsi à la DSI de présenter aux métiers la valeur ajoutée de ces données et d’anticiper un changement profond de son infrastructure. Nous l’avons vu : les technologies sous-jacentes sont innovantes et pointues. La DSI a tout intérêt à emprunter la pente douce de sa montée en compétence sur le “Big Data” ; surtout que les compétences sur le marché sont peu nombreuses et qu’aujourd’hui, une prise en main technologique est nécessaire.

L’autre axe de travail serait d’initier un dialogue avec les métiers pour mettre en commun leurs données, historiquement réparties et cloisonnées, dont la duplication entre différentes applications sera de facto très difficilement réalisable.

LGA : Quelle que soit l’hypothèse de travail, il sera évidemment nécessaire d’établir un dialogue constructif entre les métiers et la DSI afin d’assurer la réussite d’un tel projet d’envergure.

Lire aussi les articles :

Qu’est-ce que le Big Data

Quel est le paysage technologique du Big Data

Cet article Comment faire face à l’émergence du phénomène Big Data ? est apparu en premier sur RiskInsight.