Acheter la convergence aujourd’hui pour respirer le futur

Par défaut

Par Emmanuel Forgues

Voir le profil d'Emmanuel sur LinkedIn

Acheter la convergence (VCE, VMware, EMC) ou l’Hyper-convergence (VCE, Nutanix, Simplivity, Atlantis) aujourd’hui pour respirer le futur

 

Délivrer l’IaaS comme fondation de l’ITaaS

it_myvmworldPour reprendre et donner une prolongation à l’article de Noham « Pourquoi conduire la transformation de l’IT est aujourd’hui un incontourable ? » : Il y a quelques temps les fournisseurs externes arrivaient à être plus précurseurs que les départements informatiques des entreprises, poussant les utilisateurs à expérimenter eux-mêmes les nouvelles options qui s’offraient à eux comme le Cloud Public. Avec un usage de plus en plus large des technologies et services externes à l’entreprise, les utilisateurs on fait apparaitre des risques considérables pour l’entreprise, créant par la même occasion un nouveau marché : le shadow IT (l’IT cachée). La convergence de ces nouvelles tendances et le sursaut des DSI pousse à voir apparaitre une nouvelle tendance : l’ITaaS (IT As A Service) ou l’ensemble des services de l’IT peuvent être proposés comme un service externe rétribué à l’usage et prenant en charge les besoins des utilisateurs ‘hors-control’ par le DSI. Dans cette course au besoin et aux réponses, les DSI peuvent prendre une longueur d’avance considérable et innovante.

Avant d’en arriver à choisir l’ITaaS (IT as a Service) il faut commencer par la base et choisir son infrastructure pour répondre aux besoins des développeurs (Dev) et de l’opérationnel (Ops). Les logiciels et le matériel doivent offrir :

  • la mise à disposition d’environnement rapidement en mode self-service
  • tous les mécanismes d’automatisations associés
  • l’identification des couts (refacturation transparente des coûts)
  • sécurisation : encryption, authentification, contrôle des accès
  • évolutivité possible (d’autres Hyperviseurs par exemple)

La partie logicielle a déjà été abordée dans l’article sur l’association de l’hyper-convergence et des entreprises pour répondre au besoin du DevOps, nous abordons dans celle-ci le choix de l’infrastructure et ses critères. Néanmoins, il ne faut pas perdre de vue que l’infrastructure se verra totalement masquée par tous les services additionnels pour faire bénéficier à l’entreprise l’expérience du SDDC. Par extrapolation, l’importance du type de matériel est très faible à partir du moment où il délivre le service demandé. Il saura se rappeler à votre mémoire lorsqu’il ne sera pas possible d’en augmenter les ressources, en cas de panne, pour des migrations impossibles ou compliquées et autres actions classiques sur une infrastructure.

silos_myvmworld

Choix du socle de l’infrastructure

Nous avons assisté il y a de cela quelques années à une grande phase d’optimisation des infrastructures avec la virtualisation. En virtualisant les serveurs physiques nous avons assistés à un gain conséquent de toutes les ressources dans les entreprises (humains, financiers, énergétiques, etc…). Dans un premier temps avec la virtualisation des services puis la virtualisation du stockage avant d’aborder la virtualisation des réseaux (dernière étape peu démocratisé).

serveur-tradi hyperviseur

Mais il fallait aller encore plus loin dans la densification des infrastructures. Les éditeurs faisaient échos aux besoins toujours aussi nombreux et de plus en plus complexe en apportant des réponses qui ne simplifiaient pas pour autant les infrastructures.

pay_infra_myvmworld

Nous en sommes à une nouvelle étape de simplification et d’optimisation des infrastructures en réduisant l’hétérogénéité : des éditeurs, des équipements et des contrats de maintenance. C’est à ce moment que sort du bois la technologie de convergence (Flexpod de Netapp, VCE, VMware,…) et l’Hyper-convergence HCI (Nutanix, VCE vXRail, Simplivity, Atlantis, …). Cette optimisation permet d’avoir dans un seul et unique boitier (Baie ou Appliance) aussi bien les serveurs, le stockage que les infrastructures réseaux nécessaires (IP ou stockage).

Construire son propre DataCenter sur des équipements traditionnels

architecture_hci_myvmworld

Source : http://www.lemagit.fr/definition/Hyperconvergence-ou-Infrastructure-Hyperconvergee

L’infrastructure classique continue de répondre aux besoins des entreprises et ça va continuer ainsi encore pendant un moment. Avec l’approche classique (Legacy) ou en convergé ou Hyper convergé l’édifice doit être construite sur de bonnes bases. Pour disposer de l’expérience du SDDC au service du DevOps, vient s’empiler des couches successives de services. Ce qui confère à l’infrastructure toute son importance dans l’édifice. L’approche Hyper-Convergée offre cette simplification technique recherchée.

 

Continuer sur son infrastructure classique ou basculer vers le convergé ou l’Hyper-convergé est une étape lourde et compliqué. Dans l’équation il ne faut pas oublier les aspects financiers : coûts d’acquisition mais aussi les couts indirects et cachés : prix de la maintenance, consommation électrique, refroidissement, etc …

criteres_hci_myvmworldLe choix de la technologie pour le socle de toute la solution doit se faire selon plusieurs critères :

 

Modélisons une situation financière dite idéale ou ; après un investissement initial faible, la courbe d’investissements des évolutions vient exactement se superposer à la courbe des besoins comme ci-dessous :

capex_myvmworld

capex02_myvmworldEn faisant figurer les investissements initiaux d’acquisition de matériel (incluant maintenant, etc) et la courbe des besoins dans une situation idéale nous avons le diagramme suivant. Les investissements suivent alors parfaitement les besoins. Ce cas de figure est possible aujourd’hui mais uniquement dans une approche en cloud ou il est possible de consommer en fonction des besoins et de payer à l’usage.

 

Appliquons la même méthode de modélisation pour comprendre les investissements dans une infrastructure traditionnelle.

Nous retrouvons l’investissement initial qui est incontournable et souvent relativement important. La croissance va pousser l’entreprise à continuer ses acquisitions en fonction des besoins et créer ainsi un impact relativement conséquent sur ses budgets. Par souci de simplification, je fais figurer les investissements matériels, le support, les renouvellements et les autres coûts adjacents comme un seul et même investissement.

capex_03_myvmworld

Pour donner une représentation concrète des couts liés à une infrastructure j’applique la méthode suivante :

  1. faire figurer la courbe des besoins (réguliers et constants pour simplifier)
  2. l’investissement initial
  3. L’ajout par couches successives des acquisitions qui accompagne les besoins.

Partant de cette représentation le coût en excèdent (ressource acheté et non utilisée) figure au-dessus de la courbe des besoins : I1 + S1+…S4+S4′

I1 = représente la surface des besoins non utilisés mais achetés.

S1+…S4+S4′ = représente le surinvestissement pour l’évolution de l’infrastructure.

S4′ = représente le surcoût lorsque la scalabilité de l’offre est arrivée à son extrême et que le coût de l’incrément est constant, incompressible et supérieur au besoin. Ce coût excédentaire est le plus notable car oblige l’entreprise à une acquisition excessive par rapport à un besoin pouvant être faible.

Les moments dans cette phase d’investissement successif qui sont les plus intéressants à observer sont :

– lorsque l’acquisition utile (sous la courbe) devient moins important ou égale que l’acquisition non-utilisée (au-dessus de la courbe)

– Pendant combien de temps le non-utilisé acheté est supérieur à l’utilisé acheté.

C’est à ce moment dans la vie de l’infrastructure qu’il faut financièrement anticiper la pertinence de la technologie sélectionnée. Une offre qui permet d’optimiser une infrastructure existante avec un impact minimum sur les budgets doit se trouver entre ces deux cas tout en restant le plus proche possible de la solution dite « idéale ». Dans le cas où le choix est de remplacer une infrastructure existante par une solution entièrement Hyper-convergée cela revient à racheter l’infrastructure initiale. Cette démarche sur un gros Datacenter risque donc d’être financièrement rédhibitoire.

La solution la plus réaliste modélisé dans l’exemple ci-dessous consiste à avoir un investissement initial faible (ou sinon plus faible qu’une infrastructure standard L1<I1) et ou l’augmentation des ressources se passe avec la granularité la plus fine en ajoutant ce qui est au plus proche de ce qui est nécessaire.

capex04_myvmworld

Le marché propose des solutions qui techniquement tienne vraiment la route mais ou l’investissement initial est aussi élevé que l’infrastructure traditionnelle. Si en plus la solution n’offre pas de modularité il devient compliqué de justifier l’acquisition d’un bloc complet pour répondre à un manque d’espace disque (par exemple).

Sans une « granularité fine » nous aurions le diagramme ci-dessous.

capex05_myvmworld

Au moindre besoin supplémentaire l’achat d’un serveur complet est nécessaire avec une surface d’investissement non utilisé très important. Même si c’est moins souvent que les autres solutions cela revient à racheter une maison quand j’ai besoin d’agrandir un peu ma cuisine.

Cet article vient à la suite des 2 articles suivant :

 

emmanuelforguesEmmanuel Forgues

Pour suivre Emmanuel et pour plus d’informations sur son parcours et ses compétences :

Voir mon profil LinkedIn Emmanuel Forgues Voir le profil de Emmanuel Forgues

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Transition entre les infrastructures traditionnelles et le Cloud natif avec l’hyper-convergence

Par défaut

Par Emmanuel Forgues 

Voir le profil d'Emmanuel sur LinkedIn

Transition entre les infrastructures traditionnelles et le cloud natif avec l’hyper-convergence (VCE, Nutanix, Simplivity)

Cet article est la suite de l’article sur la place de l’Hyper-convergence dans la problématique du DevOps : « L’hyper-convergence (Nutanix, Simplivity, VCE) et les entreprises ensemble face au paradigme du DevOps. »

Bien qu’incontournable, l’infrastructure représente un coût important (qu’il soit direct ou indirect) dans les budgets des sociétés. Dans le même temps, les technologies utilisées dans les infrastructures traditionnelles sont de plus en plus matures alors que le cloud ne l’est pas encore assez aux yeux des entreprises. Cette différence entre deux approches oblige les entreprises à reconsidérer et à optimiser leurs infrastructures et donc leurs investissements.

 En juin 2016 le Laboratoire National de l’Université de Berkeley a publié une excellente étude qui explique et annonce la réduction de 75% des serveurs dans les entreprises en 2020. Bien que cette évolution soit en marche, comment l’appréhender et l’anticiper ?

Les principaux arguments sont l’augmentation de la puissance des serveurs capables de faire tourner un nombre grandissant de services (virtualisation, containers, …) et des services de plus en plus grand dans les clouds.

Selon cette étude, depuis 2014, nous constatons (confère l’étude, diagramme ci-dessous) le changement d’orientation entre l’infrastructure traditionnelle (current Trends) et les environnements Clouds (Hyperscale Shift)

Si nous reprenons le diagramme et en regardant la courbe d’évolution du « Non-Hyperscale », en 2020 il faut s’attendre à une perte d’environ 75% de serveurs.

(hyperscale représente les Clouds des grandes entreprises : MSFT, AWS, Google,… quand les non-hyperscales sont DC ou les Clouds dits privés)

Dans le même temps, il faut s’attendre à une croissance d’environ 20% des environnements clouds.

Cette perte de 75% de serveurs ne va pas se retrouver dans les environnements cloud comme un simple transfert des serveurs d’un environnement vers un autre. Il y a l’optimisation qui consiste à mutualiser les services sur les serveurs mais aussi l’évolution technologique. Les environnements Hyperscales sont en acquisition de nouvelles technologies alors que les environnements « Non-Hyperscale » sont en décroissance, ce qui explique en partie cette différence.

Sans aborder la problématique énergétique mondiale causée par l’informatique et tous les moyens de communication, l’étude montre la part grandissante de consommation d’énergie pour l’infrastructure, le stockage et les serveurs. (Confère ci-dessous le diagramme extrait de la même étude).

Les problèmes énergétiques sont un des moteurs du changement dans le choix d’infrastructure pour les systèmes d’informations. La virtualisation a été la première étape à éviter une explosion peut-être exponentielle du nombre de serveurs. L’étape suivante consiste à regrouper l’ensemble de ces besoins énergétiques en une et une seule technologie. Les promesses de l’Hyper-convergence est à mi-chemin de la promesse du Cloud en ce sens.

Cette différence est visible en faisant le lien entre ces deux précédents diagrammes :

  • réduction des serveurs (75%) associée à la réduction possible d’énergie dans les infrastructures restantes dans les entreprises (non-Hyperscale)
  • Augmentation énergétique associée à la faible augmentation en infra des solutions Hyper-scale (+21%) par rapport à la récupération des serveurs des solutions non-Hyperscale (75%?).

Même si la tendance montre une nécessité de changement, pour justifier des acquisitions il faut continuer de pouvoir les justifier par rapport à un service générant des revenus pour l’entreprise. Toutes les entreprises ne font pas face aux problèmes de DevOps mais doivent répondre dans tous les cas à l’équation : Ajuster les ressources pour un service aux utilisateurs dans une logique de business d’entreprise en réponse à un marché à acquérir ou à consolider.

Lors de nouvelles acquisitions, les DSI cherchent :

    • de la flexibilité
    • la capacité de supporter des environnements hétérogènes
    • le contrôle des composants
    • une intégration dans un système hardware ou applicatif existant
    • une montée en charge non prévues
    • des mises à jour (patchs ou nouvelles fonctionnalités) continuellement
    • mise à disposition « self-service » d’environnements (un grand nombre de petits environnements de travail)
    • garantir la continuité des services dans l’ensemble
    • garantir l’interopérabilité des mêmes services
    • l’agilité de l’infrastructure
    • la performance correspondant au cahier des charges des services
    • un contrôle des couts

Pour le développeur utilisant ces infrastructures que son travail (code) ne doit pas avoir d’emprise sur l’environnement de travail et être transparent par rapport à la localisation de son travail. Ce qui est déjà en soit un changement considérable.

Les infrastructures traditionnelles offrent des évolutions toujours constantes pour proposer de la performance. Ces dernières souvent s’appuient sur de nouvelles technologies (nouveaux processeurs, nouveaux type de disque, nouveaux protocoles, …) mais doivent toujours permettent la continuité et interopérabilités des services entre eux. Même si le prix est un élément important venant des contraintes financières, ce dernier et la densité (impact prix aussi sur les couts indirects) viennent s’ajouter dans l’équation du processus de décision d’acquisition.

Tel un père au prétendant de sa fille quadragénaire, secrètement désireux de la voir quitter le domicile parental à l’approche de sa retraite, les nouvelles technologies arrivent toutes avec des promesses. Faire converger dans le moins de densité possible : le prix, la puissance de calcul (computing), le stockage, le réseau, la virtualisation pour les services et avec la simplicité d’intégration aux besoins actuels et futurs. S’il fallait représenter les tendances, nous pourrions représenter la courbe de la maturité des technologies traditionnelles (TT) et celle de la maturité du cloud.

Ces deux technologies avec deux courbes de maturités différentes vont se croiser à un moment notable dans l’histoire de l’infrastructure de l’entreprise. Nous appelons cela aussi un «virage technologique» à prendre ou à rater.

Dans notre cas, il faut tenir compte d’un réajustement de la courbe de maturité des technologies traditionnelles avec l’arrivée d’une nouvelle approche lui donnant un second souffle (une séquence à cycle de vie double).

En rouge : séquence à cycle de vie double de la courbe de l’infrastructure traditionnelle des entreprises

En vert : courbe de maturité de l’approche «Cloud»

Etape 1 : phase d’adoption et de maturité des infrastructures traditionnelles. Apparition d’une nouvelle approche «cloud».

Etape 2 : phase de renouvellement mais en optimisant (refonte possible de l’infrastructure)

Etape 3 : le rebond par l’optimisation sur des solutions innovantes (en rupture ou non)

Etape 4 : Adoption des environnements cloud représente par l’intersection des deux tendances

A : point de maturité des infrastructures traditionnelles

B : point de rupture avec un rebond en s’appuyant sur une nouvelle technologie (par exemple l’hyper-convergence)

C : prolongation ou rupture vers les environnements clouds

D : point d’interception des infrastructures traditionnelles avec le cloud sans le rebond de l’hyper-convergence

En considérant les technologies actuelles (sections 1 et 2) et en y ajoutant un composant supplémentaire (hardware ou software, point B) les technologies traditionnelles entrent dans une séquence à cycle de vie double (section 3). Le marché appelle ce second souffle la convergence ou l’hyper-convergence.

C’est la phase 3 qui m’intéresse le plus parce qu’il me semble que nous sommes en train de la vivre. Nous avons une infrastructure actuelle et des besoins qui s’orientent vers le cloud sans trop savoir comment le faire. Le point C est le résultat des promesses de ces nouvelles technologies. C’est en phase 3, qu’il faut se poser les bonnes questions au sujet des promesses des acteurs proposant de nouvelles technologies et au point C ou nous avons la réponse … ou la terrible sanction. 

… l’évolution c’est aussi de sauter dans le bon bocal :

Phase 3

La phase 3 va être clé pour celui qui est le premier à faire le pas ou à changer de bassin sans trop savoir ce qu’il va y trouver.

Pour ceux qui ne mènent pas cette démarche, il suffit d’attendre l’obligation de migrer vers le cloud mais en poursuivant ses investissements dans le traditionnelle. Cette solution est rassurante et permet de rester en contrôle de tous les composants techniques, financiers et humains. Elle a aussi l’avantage de ne pas essuyer les plâtres pour les autres. Elle a bien évidemment des avantages comme des désavantages.

La suivante consiste à se montrer précurseur et de participer aux solutions de demain tout en acquérant des compétences précieuses pour le futur. Pour l’instant l’adoption de cette approche reste timide soit à cause des limitations techniques, sécuritaires, ou pour des aspects financiers ou légaux. L’adoption inconditionnelle du tout cloud n’est pas pour aujourd’hui …

L’approche la plus probable est d’anticiper avec des technologies qui répondent aux problématiques actuelles et capables de s’inscrire dans la prochaine étape à moindre couts. Cette phase d’optimisation de l’infrastructure trouve écho aux promesses des solutions d’Hyper-convergences … à condition que les investissements soient pérennes et permettent d’aborder le virage sereinement.

emmanuelforguesEmmanuel Forgues est diplômé de l’EPITA (promo 97) en spécialité système et Réseaux et récemment diplômé de Sciences Politique Paris en stratégie Internationale et accompagnement du changement. Emmanuel possède une vue globale en s’appuyant sur plus de 20 années d’expérience dans les start-ups, grandes entreprises et les éditeurs. Ces années sur différents domaines (avant-vente, product manager, stockage, sécurité ou réseaux) lui confère de fortes connaissances techniques. Spécialisé aujourd’hui dans la création, l’accompagnement et la montée en puissance des réseaux de distribution en Europe du sud.

Pour suivre Emmanuel et pour plus d’informations sur son parcours et ses compétences :

Voir mon profil LinkedIn Emmanuel Forgues Voir le profil de Emmanuel Forgues

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Hyperconverged technologies and companies facing the DevOps paradigm

Par défaut

By Emmanuel Forgues 

Voir le profil d'Emmanuel sur LinkedIn

Hyperconverged technologies (Nutanix, Simplivity, VCE) and companies facing the DevOps paradigm

To survive today, a company faces a challenge: the balance between development time and market demand. It is not possible to wait 6 months to come up with an application. The release of a new OS (Android, IOS, Windows, …) requires immediate reactivity or the company might face a potentially heavy financial penalty or just miss a new market. However, we must not confuse speed with haste when marketing cannot wait, especially in an economic context crippling budgets. Just look at the sad example of the mobile application deployed urgently, at the request of the French authorities to inform on terrorist actions. This application (SAIP), developed in 2 months by a team of 15 engineers functioned for a few hours only after the attack in Nice.

The new convergence and hyper-convergence solutions provide companies with the  rationality of an infrastructure to face the challenges of DevOps. The major publishers have different approaches but should eventually be able to integrate a broader range of technologies into a single offer.

The non-named problems encountered in business:

Two technical entities participate in the development of all the companies relying on IT.

On one hand, the development team (DEV) which produces IT solutions both for internal or external use, and, on the other hand, the operation team (OPS) which provides DEV with the necessary tools and maintains them. We see that their goals are often contradictory within the same company, in fact their alignment is a strategic and economic challenge for IT departments.

For convenience we will speak of DEV for Development and OPS teams for Operational teams.

Where is the brake between market demands and technical services? Why is DEV not reactive enough? First answers: because they are hamstrung by overly rigid infrastructure, inadequate service catalog and physical or virtual infrastructure without  « programmability » capacity. Why are OPS not reactive enough? It is likely that they are not sufficiently involved with the DEV teams to meet their expectations.

Obviously the physical and virtual infrastructure has to change to become more programmable. At the same time the DEV must be able to program infrastructure and OPS must be able to understand and control the interactions of DEV with the infrastructure. In short, the difficulties between DEV and OPS are as follows:

We will call « DevOps » the necessary confrontation between these two teams. DevOps is the concatenation of English words Development and Operation

Lire la suite

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook