Packer, automatiser la création d’images systèmes

Par défaut

Logo HashiCorp Packer

Il y a, dans le monde surpeuplé des outils DevOps, une société qui aujourd’hui tire son épingle du jeu en proposant des produits open source novateurs et devenus des références sur le marché. HashiCorp est une start-up fondée en 2012 par Mitchell Hashimoto et Armon Dadgar, ils se sont donnés pour but d’offrir un panel d’outils complet pour l’automatisation du datacenter. Cela se traduit par des outils « Infrastructure as a Code » permettant de créer et manager des environnements complexes (Terraform), gérer de manière sécurisée et distribuée les « secrets » liés aux applications (Vault) ou bien faciliter la mise à disposition d’environnement de développement (Vagrant). Dans cet article, je vous propose de nous attarder sur un autre produit, Packer.

Packer a été développé pour faciliter la création d’images de système d’exploitations, que ce soit des machines virtuels ou bien des containers. A partir d’un simple fichier de configuration, Packer est capable de préparer en parallèle ces images sur différents environnements cloud (AWS, Azure, GCE), on-premises (vSphere, Hyper-V,etc…) ou bien même sur son propre ordinateur (VirtualBox, Fusion, Workstation…). Packer est une réponse concrète aux problèmes de gestion des images, que ce soit sur une infra « simple » (qui n’a jamais rêvé d’avoir à disposition des images de VM toujours à jour ?) ou bien sur des environnements plus complexes (une application développée sur des laptops, testée sur une infra locale et mise en production sur un cloud public).

Prérequis techniques

On en a terminé avec la présentation marketing, voyons maintenant comment Packer fonctionne et si oui ou non il est bien l’outil qui réconciliera à jamais les devs et les ops ! Commençons par les habituels prérequis. Il va vous falloir créer un répertoire de travail (pour stocker le fichier de conf ainsi que les différents scripts), un éditeur de texte et… installer Packer… Que vous soyez sous Linux, Windows ou MacOS, pas de problème HashiCorp a pensé à vous. Il vous suffit juste de télécharger l’exécutable (liens vers site) et de le placer dans un répertoire qui est disponible dans le PATH. Maintenant sortez votre plus beau shell et exécutez la commande packer:

En avant pour une première image !

Vous voilà fin prêt à construire votre première image! Je sens d’ici votre excitation ! Mais avant que vous ne vous lanciez à corps perdu dans l’aventure, je vous propose que nous passions du temps à détailler le contenu d’un fichier de configuration qui nous permettra de créer une image Windows Server 2016 sur AWS.

Le reste de l’article va faire appel à des notions liées à AWS ou bien les OS Microsoft. Ce n’est pas grave si cela vous est complètement étranger, cela ne vous empêchera pas de comprendre comment fonctionne Packer.

Vous pouvez retrouver le fichier de configuration Packer ainsi que les différents scripts sur Github.

Le fichier de configuration (appelé template dans la documentation officielle) est au format JSON, il va contenir la trame des différentes étapes qui auraient été nécessaires à un déploiement manuel, à savoir:

  • Créer une « machine virtuelle » (VM VMware vSphere, Instance AWS EC2, container Docker, etc…)
  • Provisionner un système d’exploitation (ce n’est pas forcément nécessaire dans les clouds publics)
  • Personnaliser l’OS à l’aide de scripts (exécutés par exemple via SSH ou WinRM) ou bien d’outils tiers tels que Chef ou Ansible
  • Et enfin, créer une image que vous pourrez utiliser par la suite pour déployer d’autres environnements identiques.

Les Builders, spécialistes du gros œuvre

On va commencer par définir un Builder qui aura la tâche de créer la machine virtuelle avec les caractéristiques qu’on lui aura indiquées. Il existe plusieurs types de Builder en fonction de l’environnement sur lequel vous voulez déployer votre machine. Etant donné que la cible est AWS, nous allons utiliser un Builder du type amazon-ebs

Je ne vais pas rentrer dans les détails car les différents paramètres sont spécifiques à AWS et Windows. Pour résumer, ce Builder va se connecter à AWS en utilisant la clé spécifiée (access_key, secret_key), créer une instance EC2 à partir d’une image fournie par AWS (source_ami) et essayer de se connecter au serveur Windows via le protocole WinRM. Une fois qu’il aura réussi à établir une connexion, il laissera la main pour la suite des opérations.

Les Provisionners, détails et finitions

Maintenant que nous disposons d’un OS « de base » nous allons pouvoir le configurer suivant nos besoins. C’est là qu’entre en scène les provisionners. Comme leur nom l’indique, ils vont nous permettre d’interagir avec l’OS via différents moyens de communication (Scripts, Chef, Ansible…) pour pouvoir le personnaliser.

Dans l’exemple ci-dessus, nous avons défini trois provisionners différents. Ils seront exécutés séquentiellement par Packer. Le premier va exécuter plusieurs scripts Powershell qui sont stockés dans le sous-répertoire scripts de notre répertoire de travail. Étant donné qu’un des scripts va effectuer les mises à jour Microsoft Update, le deuxième provisionner va redémarrer Windows et attendre qu’il soit de nouveau disponible. Enfin, le dernier va exécuter des scripts stockés sur l’OS et qui font partis des outils qu’inclus AWS dans ses images. Ils ont pour but de préparer l’OS à être transformé en template.

Si tout se passe comme prévu lors de l’exécution des différentes opérations de personnalisation, Packer va faire tout le travail restant à savoir:

  • Éteindre l’instance EC2
  • La transformer en un template (AMI) qui sera disponible dans votre console AWS.

Maintenant que nous avons créé notre fichier de configuration, nous allons pouvoir valider qu’il ne contient pas d’erreurs de syntaxe avec la commande packer validate monfichier.json

> packer validate .\aws-windows-dsc.json Template validated successfully.

Si la commande ne retourne pas d’erreur alors nous pouvons lancer la création du template avec la commande packer build monfichier.json

Attention, la création d’un template peut prendre beaucoup de temps notamment si, comme dans cette exemple, vous mettez à jour votre serveur Windows…

Il n’y a plus qu’à attendre que Packer finalise la création du template et vous devriez avoir à votre disposition un AMI flambant neuf dans votre interface EC2.

J’espère que cet article vous aura donné envie de tester plus en profondeur Packer. A mon avis le potentiel de l’outil est énorme et devrait faire partie des indispensables de votre trousse à outils, que vous soyez Ops ou Dev.

N’hésitez pas à laisser un commentaire ou bien contactez moi sur twitter (@erwanquelin) pour toutes questions.

Pour aller plus loin

Les sites ou articles ci-dessous ont été une source d’inspiration non négligeable !:

Le titre auquel vous avez échappé

  • Packer Lewis ne perd jamais
Erwan Quélin est depuis 6 ans Ingénieur Systèmes chez Cheops Technology. Ses interventions sont multiples et auprès de clients très diversifiés dans la région Ouest. Spécialisé dans la virtualisation autour des produits VMware et dans le stockage autour des gammes VNX, Unity et VPLEX de Dell EMC, Erwan est certifié VMware Certified Professional – Datacenter virtualization 4, 5 et 6 ainsi que EMC Implementation Engineer – VNX et Unity et vient d’intégrer les programmes VMware vExpert et Dell EMC Elect pour l’année 2017.

Lorsqu’il lui reste un peu de temps libre, Erwan développe des projets open sources ayant pour sujet principal l’automatisation d’infrastructures.

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

Voir mon profil LinkedIn Erwan Quelin Voir le profil Linkedin d’Erwan

Voir mon profil GitHub Erwan Quelin Voir le profil GitHub d’Erwan

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

L’admin de demain ! [ Introduction ]

Par défaut

Cela n’aura échappé à personne mais nous vivons une époque de profonds changements dans notre métier. De nombreuses nouvelles technologies venant bousculer nos habitudes d’Administrateur Datacenter ou étant sur le point de le faire. J’avais envie de partager avec vous ma réflexion sur le sujet.

Je me rappelle régulièrement cette phrase lorsque que j’effectue une étude technique : « Nous faisons partie du système considéré ». Il est donc aussi évident de se poser la question des impacts de ce nouveau système sur les hommes et les femmes qui le design, l’administrent et l’exploitent.

Je vais dans ce premier article introduire les différents sujets que je traiterais dans le détail sur ce blog dans les mois à venir. Evidemment, certains d’entre vous sont déjà familiarisés avec ces sujets et penserons que nous enfonçons gaiement des portes ouvertes, et c’est tant mieux ! N’hésitez pas à participer aux discussions, décrire vos retours d’expériences car nous allons ensemble prendre des risques !

Les années « Stabilité » et « Résilience »

Depuis une dizaine d’années, je vais forcer le trait en disant que nous avons pensé essentiellement à la résilience de nos plateformes. Des crashs importants intervenus dans les années 2000 ont poussé le marché à développer des solutions de continuité d’activité. Bienvenue au PRA et au PCA qui ont occupé ma vie d’intégrateur pendant pas mal de temps.

D’un autre côté, les entreprises et organismes publics ont pris conscience de leur dépendance au « Système d’Information », et ont essayé de prendre toutes les précautions pour que celui-ci dispose d’une qualité de service très importante.

J’y reviendrai plus tard mais cette période, quoique féconde en révolution, comme la virtualisation. (Quoi ? Qu’entends-je au loin ? Un admin IBM courroucé par mes propos pensant que la virtualisation existe depuis des décennies ? NDLR : Il a raison ;o) ou le stockage partagé me laisse un peu sur ma faim, voir en demi-teinte. Ces nouvelles technologies ont effectivement permis de maitriser son « SI » qui était en pleine croissance, l’émergence de nouveaux produits dans le monde de la protection des données par exemple. Toutefois, la couche supérieure n’a pas franchement évolué (Serveur d’applis + BDD, Annuaire AD, messagerie, serveur de fichier, un firewall périmétrique).

Je vais être honnête, je me suis éloigné d’une certaine forme d’expertise pendant cette période. Pour prendre un exemple concret, là où je passais plusieurs semaines à préparer une Master Windows 2003 Server fin des années 2000, ½ journée était consacrée à la même action quelques années plus tard.  J’ai déplacé mon activité vers l’infrastructure matérielle au détriment des services applicatifs. Pour résumer, je pense que la simplification des outils du SI a entrainé une diminution de mes compétences d’informaticien (scripting, language de dev, SQL…etc). « Mode Introspection = OFF ».

Une simplification et une diminution du maintien en condition opérationnel des infrastructures.

Il faut reconnaitre que les constructeurs et éditeurs font de gros efforts pour simplifier l’administration des infrastructures et son maintien en condition opérationnel. La plupart des produits ont largement réduit la complexité des mises à jour (voir effectuer directement les mises à jour à notre place), créer de nouvelles interfaces beaucoup plus accessibles, des assistants… ; Finalement sont apparus des environnements de plus en plus « User Friendly », nous permettant d’administrer une bien plus grande capacité de ressources avec des moyens humains constants, voir dans de nombreux cas, en baisse.

Après tout, à cette époque, l’informatique n’est pas le cœur de métier des entreprises et des organismes publics.

2010/2015 : « l’explosion »

Après le raz de marée des années 2005/2010 sur Internet, les smartphones, les réseaux sociaux…débute une période d’effervescence. Je ne vais pas m’étendre sur l’ensemble mais je pense que cette liste démontrera simplement à quelle vague nous avons à faire : Disque Flash, Powershell, HTML5, Cloud Public-Privé-Hybrid, Du IaaS au XaaS, Bid Data, Hyper-convergé, Containers, micro-services, NVME, IoT, Blockchain, Intelligence Artificielle, A Réalité Augmenté…Etc. Bodhi, dans Point Break, aurait parlé de la vague des 50 ans. Mais finalement, le résultat de toutes ces innovations, c’est que l’IT ne représente plus un cout mais un vecteur d’innovation et de développement pour les entreprises privées et organismes publics. Le SI intègre le cœur de métier de leurs activités. Et ça, cela change tout !

Et les administrateurs dans tout ça.

Mais revenons à nos moutons. Quel va être notre place dans les années à venir. Nous allons devoir déporter notre activité quotidienne de maintien en condition opérationnel de l’infrastructure vers des actions à plus forte valeur ajouté. C’est le cas pour les administrateurs mais également pour les intégrateurs. Les sujets ne manquent pas. Je vais vous présenter certains aspects de l’évolution de notre métier qui me semblent essentiel d’appréhender. Chaque sujet fera l’objet d’un article dédié par nécessité mais également par plaisir d’aller plus loin sur ces sujets.

Administrateur « Datacenter » – Système « ET » Réseau

C’est une réalité que l’on vit au quotidien mais il devient difficile voire impossible d’appréhender seulement une partie du Datacenter tant les dépendances deviennent importantes. Ce mouvement s’observe depuis déjà quelques années. Evidemment, l’avènement du SDN avec des produits comme VMware NSX vont accélérer cet état de fait mais pas seulement.

Pour maitriser les thématiques de troubleshooting, d’analyse des performances et de tuning, des designs multi-site, il faut comprendre et maitriser le transport des flux. Pas besoins toutefois d’être un « mutant » sur l’ensemble des technologies mais une bonne compréhension des basics me semble nécessaire. Dans un sens comme dans l’autre. Je n’aborde délibérément pas la sécurité que je traiterai à part. Rappelons-nous que notre formation initiale nous avait préparé à ça. Mais plus les structures ou nous exercions étaient importantes et plus les équipes se sont segmentées par expertise.

L’automatisation du Datacenter

1 étape de notre démarche, l’automatisation du Datacenter. Les matériels et logiciels sont aujourd’hui entièrement pilotables grâce à des langages de script beaucoup plus performants comme PowerShell (qui entraine des suites comme PowerCli sur les environnements VMware). Les API (Application Programming Interface) « REST » sont également de la partie. Pourquoi automatiser son Datacenter ? Je pourrais dérouler tous les arguments du marché sur le sujet mais je vais me permettre une rapide synthèse : Faire plus et mieux avec des moyens (financier et humain) identiques ou en baisse. L’automatisation des actions récurrentes d’une faible valeur ajoutée permet de basculer sur des actions plus pertinentes que nous aborderons plus tard. Je prendrais le temps de développer ce point dans un autre article mais avec les outils à notre disposition aujourd’hui dans les secteurs du IaaS et du SaaS, j’ai tendance à dire qu’il suffit d’être imaginatif pour comprendre les enjeux de l’automatisation. Il est également important de noter que chaque action industrialisée permet de diminuer le risque d’erreur et augmente la sécurisation des processus de son IT. Je reviens également sur mon premier point : peu probable d’avancer sur ce sujet sans avoir une bonne connaissance de son réseau et d’avoir mis un pied dans le SDN. Nous allons devoir creuser certains sujets !

Supervision / Monitoring & recherche de la performance

Ce n’est plus nécessaire d’expliquer la nécessité d’avoir un système de supervision à la hauteur des nouveaux enjeux et je ne parle pas seulement de « pinger » des ressources, mais d’effectuer de la supervision applicative, d’automatiser des rapports sur la qualité de service de son SI. De nombreux outils gravitent sur ce marché même si, avec une partialité assumée, je vous conseille EyeOfNetwork (Communauté dans laquelle pas mal d’amis gravitent). Coté Monitoring, nous devons reprendre du temps à analyser notre production, comprendre les points de contention, s’efforcer de mettre les quelques coups de tournevis qui peuvent énormément augmenter les capacités du Datacenter. Encore une fois, je pense que nous avons mis de côté pendant pas mal d’année cette activité pour de nombreuses raisons évidentes : On ne touche pas une « prod » qui marche, on manque de temps, le besoin n’est pas exprimé par l’utilisateur final…Etc. Cependant, quoi de plus intéressant que de comprendre les informations remontées par les bons outils du marché (Sexygraf, DC Scope, VMware vRops…), de les analyser, et d’appliquer des correctifs sur sa production avec des impacts directs et positifs sur l’expérience utilisateur !

La sécurité

Comment aborder ce sujet ? Evidemment la sécurité de son SI devient primordiale. Les données deviennent vitales pour l’entreprise ou pour tout établissement public, les données ont une valeur avec le développement du Big Data. Les sécuriser devient stratégique. Les outils du marché se développent et de nouveaux sujets apparaissent comme la micro-segmentation, les security maps, la gestion de la mobilité…etc. Il y a un boulot énorme sur ces sujets et même si je ne suis pas dans mon domaine d’expertise, je tenterai de balayer l’état des offres actuelles et des différentes méthodologies à connaitre pour augmenter la sécurisation de son SI.

DevOps : Aller au-devant des métiers

Tous les sujets que j’ai évoqués plus haut convergent vers un seul but: offrir un service de meilleure qualité à ces services métiers et aux utilisateurs du SI. La méthode DevOps nous pousse à amener de la valeur, à améliorer la production des équipes métiers. C’est une démarche qui permet aux équipes de développement et d’infrastructure de collaborer plus efficacement face aux nouvelles exigences de la digitalisation.

Quand on a dit ça, on fait quoi ? Finalement, on tente t’intégrer les démarches de sécurité, d’audit, et d’automatisation tout au long du processus de développement de ses offres de service jusqu’à la production par les utilisateurs, en restant agile. Facile, non ?

La protection des données

Tous les modifications de process et d’infrastructure que j’ai évoqué ci dessous nous oblige à repenser nos plateforme de protections des données (sauvegarde/restauration, Archivage, Copie..etc). Le type et l’emplacement des données, les volumétries changement mais le plus important, les données générées ont maintenant un coût et peuvent servir la stratégie de l’entreprise ou de l’établissement public ! Le « Data Management » prends finalement tout son sens aujourd’hui. Apprendre à correctement protéger nos données et le prouver devient essentiel.

Conclusion

A l’heure du développement du cloud public, il serait naïf de penser que les performances et la qualité de service de notre infrastructure ne seront pas comparées avec des ressources du cloud public. La cohabitation est nécessaire, toutefois le datacenter « On Premise/hybrid » n’a pas encore dit son dernier mot !

 

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

L’hyper-convergence et les entreprises ensemble face au paradigme du DevOps

Par défaut

Par Emmanuel Forgues 

Voir le profil d'Emmanuel sur LinkedIn

L’hyper-convergence (Nutanix, Simplivity, VCE) et les entreprises ensemble face au paradigme du DevOps

Pour survivre aujourd’hui, l’entreprise est face à un challenge : l’adéquation entre le temps de développement et la demande du marché. Il n’est, en effet plus possible d’attendre 6 mois pour sortir une application. La parution d’un nouvel OS (Android, IOS, Windows, …) nécessite une réactivité immédiate sous peine d’une sanction financière pouvant être lourde ou simplement de louper un nouveau marché. Cependant, il ne faut pas confondre vitesse et précipitation lorsque le marketing ne peut pas attendre et dans un contexte économique grevant les budgets. Il suffit de regarder le triste exemple de l’application mobile déployée, en urgence, à la demande des pouvoirs publics français pour informer sur les actions terroristes. Cette application (SAIP) développée en 2 mois par une équipe de 15 ingénieurs n’a fonctionnée que plusieurs heures après l’attentat de Nice.

                  Les nouvelles solutions de convergence et d’hyper-convergence fournissent aux entreprises la rationalité de l’infrastructure face aux challenges du DevOps. Les principaux éditeurs ont des approches différentes mais doivent à terme être capables d’intégrer un ensemble plus large de technologies dans une seule et même offre.

La problématique non-nommée rencontrée dans les entreprises :

Deux entités techniques participent aux développements de l’ensemble des entreprises s’appuyant sur l’Informatique. D’un côté les équipes de développement (DEV) qui vont produire une solution informatique (usage interne ou usage externe) et de l’autre côté les équipes des Opérations qui sont là pour mettre à disposition de la première équipe des outils nécessaires et en assurer la maintenance. Nous verrons que leurs objectifs sont trop souvent contradictoires au sein de la même entreprise et l’alignement de ceux-ci est un challenge stratégico-économique pour les DSI.

Par commodité nous parlerons de DEV pour les équipes de Développement et de OPS pour les équipes Opérationnelles.

Où se trouve le frein entre les demandes du marché et les services techniques ? Pourquoi le DEV n’est pas suffisamment réactif ? De premiers éléments de réponse : car ils sont bridés par des infrastructures trop rigides, un catalogue de services inapproprié et infrastructure physique ou virtuelle sans capacité de « programmabilité ». Pourquoi les OPS ne sont-ils pas assez réactifs ? Il est fort probable qu’ils ne soient pas suffisamment impliqués par les équipes DEV pour répondre à leurs attentes.

A l’évidence l’infrastructure physique et virtuelle doit changer pour devenir plus programmable. Dans le même temps les DEV doivent pouvoir programmer l’infrastructure et les OPS doivent pouvoir comprendre et contrôler les interactions des DEV avec l’infrastructure. En résumé, les difficultés entre DEV et OPS :

Nous nommerons « DevOps » cette confrontation nécessaire de ces deux équipes. DevOps est la concaténation des mots anglais : « development » (développement) et « Operation » (exploitation).

La grande majorité des analyses mettent en avant que les années 2016-2017 seraient le début d’une adoption massive du PaaS (Plate-Forme as a Service), du DevOps et du container Docker.

  • IDC : 72 % des sociétés vont adopter le PAAS
  • DZone : 45 % des interrogés répondent qu’ils évaluent ou utilisent déjà les Docker Containers
  • Right Scale : 71 % des entreprises annoncent une stratégie basée sur plusieurs clouds.

PAAS :

paas_myvmworldUne « Plateform as a Service » (PAAS) est un service de « Cloud computing » fournissant une plateforme et un environnement nécessaire aux développeurs avec les avantages du « cloud ».

Ce service offre :

  • Une capacité de montée en charge importante et rapide sans les coûts associés d’investissement et de maintenance.
  • L’usage via une interface WEB sans les compétences d’infrastructure complexe
  • Flexibilité des services à utiliser et des circonstances d’utilisation
  • Environnement collaboratif poussé à l’extrême
  • Sécurité assurée par le fournisseur de PAAS pour les accès et les données

Container Docker :

docker_container_engine_logo

                  Aujourd’hui se pose toujours la question du déploiement des applications actuelles. Mais très vite il va falloir se poser la question du déploiement des applications du futur (container/Dockers). La technologie Docker va permettre l’exécution des services sur n’importe quel serveur quel que soit l’infrastructure cloud ou non.

 Contrairement à une VM (Machine virtuelle de plusieurs Go), le container (quelques Mo) n’embarque pas d’OS. Le container/Docker est donc plus léger et plus rapide à démarrer, déplacer, dupliquer (ainsi que toutes les autres actions de maintenance courante).

Considérons une entreprise qui doit augmenter brutalement les ressources pour un développement stratégique urgent (secteur bancaire, sociétés de développement, …). Avec une solution traditionnelle de VM, il faut avoir provisionné un grand nombre de VM en attente et les démarrer pour les mettre à disposition. Il est donc nécessaire de disposer au même instant de l’infrastructure nécessaire pour supporter le démarrage de tous ces environnements : CPU, RAM, Stockage, I/O disque et I/O réseau, …).

En éliminant l’OS, les containers consomment de 4 à 30 fois moins de RAM et de disques. Dans ce cas quelques secondes suffisent pour démarrer les applications. Les containers/Dockers sont aux applications ce que la virtualisation était aux serveurs dans les années 90.

Aujourd’hui leurs usages facilitent les développements en automatisant l’intégration. Cette intégration est continue et automatise les passages successifs des mises jour du code source provenant des environnements du dev, QA, pre-prod jusqu’à la production.

 Nous mettons en exergue le problème de la mise en production de ces containers qui ne peut se faire par les équipes IT tant que le contrôle du réseau, sécurité, stockage, sauvegarde, supervision… ne sont pas correctement intégrés à la programmation et à la configuration du Container. Dès lors, les containers seront la réponse logicielle au DevOps car utilisés par les DEV qui consomment de l’infrastructure tout en étant maîtrisé par les OPS. Pour une bonne intégration les éditeurs proposent déjà des solutions d’orchestration pour gérer l’équilibrage de charge, la gestion de la résilience, chiffrement, etc.

Selon Datadog, l’adoption des dockers a augmenté de 30% en 1 an :

source Datadog

Les Container Docker apporteront rapidement tous leurs bénéfices comme solution au DevOps !

Le problème nommé est donc le DevOps :

                  devops_03_myvmworldSelon le Gartner, le DevOps dépassera le stade de la niche en 2016 avec 25 % des très grandes entreprises mondiales qui l’auront adopté représentant un marché de 2,3 milliards de $. Selon IDC, En France 53 % des entreprises ont engagé une démarche DevOps généralisée à tous leurs développements.

Face aux difficultés des entreprises à transformer leurs infrastructures classiques en une solution suffisamment agile, les fournisseurs de cloud peuvent proposer la mise en œuvre du DevOps avec leurs approches Scale-Out et leurs propositions d’économies d’échelles.

La mise en œuvre de DevOps oblige à regarder plusieurs problèmes : structurels, organisationnels, de ressources, etc. Pour le DSI, en charge de la réponse technique il est cauchemardesque de mettre en place une infrastructure agile avec des équipements actuels traditionnels. Il lui faut gérer aussi bien des environnements complexes, de multiples serveurs (stockages, computing, réseaux, sécurité) que des services de développements (Bases de données multiples, les portails WEB, les logiciels de développements comme python, C++, les libs et autres APIs, les applications de supervision et d’analyse de performance…). Les technologies de containers et les réseaux overlays apportent des réponses pertinentes aux problèmes de réseaux, à condition que les administrateurs de ces services anticipent leur arrivée. L’ensemble devant se réaliser dans un temps record en supportant la pression externe du marché, la pression interne du marketing et avec des budgets restreints. Une fois l’ensemble en place, il faut enfin en tirer profit au maximum pour que toutes les applications interagissent entre elles correctement tout en étant capable de gérer les besoins de migration rapides. Le tout sans impacts pour l’ensemble de l’infrastructure.

  1. Nombre de serveurs physiques ou virtuels
  2. Nombre de services de développement
  3. Garantir la stabilité et les interactions face à une complexité grandissante en fonction du nombre de serveurs et de services
  4. Temps de mise en œuvre qui soit être de plus en plus court
  5. Contrainte des budgets
  6. S’assurer de la capacité des migrations d’un environnement vers un autre en s’assurant de maintenir les 3 points précédents
  7. Pression du marché (marketing dans l’entreprise) grandissante
  8. Garantir l’évolution des acquisitions sur quelques années

En excluant les solutions traditionnelles, il y a sur le marché deux grandes tendances répondant à ces besoins :

  1. Construire/assembler pour un « Workload » Spécifique : les principaux acteurs étant Oracle Exadata DataBase Machine (les Hyper-Appliances).
  2. Intégrer l’ensemble du stockage, la puissance de calcul (computing), le réseau… dans une solution capable de démarrer plusieurs workloads (les solutions de convergences et d’Hyper-convergences comme Nutanix (http://www.nutanix.com)Simplivity (https://www.simplivity.com/), VCE (http://www.vce.com/), …) Aujourd’hui ces technologies peuvent faire fonctionner les workloads actuels mais devront aussi anticiper les prochains.

Les infrastructures (Hyper-)convergées et les systèmes intégrés présentent le plus fort potentiel pour s’intégrer dans une solution de DevOps. Elles offrent toutes les avantages d’être extensible, standardisation de l’IT, programmable…

Certains acteurs proposent dans leurs offres toute ou partie de l’ensemble des briques intéressantes pour un DevOps :

  • Flexibilité de la mise à disposition des ressources (stockage, CPU, RAM,…) avec des solutions de (hyper-)convergence.
  • Mise à disposition des applications nécessaires avec des solutions dockers ou de containers et les applications pour le provisionnement rapide.
  • Provisionnement rapide des environnements de travail via un portail Web : 1-Click.
  • Réduction des compétences complexes et couteuse dans les équipes d’infrastructure
  • Externalisation totale de l’infrastructure pour ne plus en supporter les couts.

Aujourd’hui les sociétés VMware, CISCO et Nutanix peuvent provisionner aussi bien des VMs que des containers, Simplivity à ce jour est capable de le faire rapidement pour les VMs uniquement, (mais je ne vois pas cette société être en reste longtemps). VMware est capable d’avoir un seul OS pour supporter plusieurs containers simplifiant déjà la gestion de cet OS. Nutanix est capable de provisionner les Containers avec leurs stockages. La société Nutanix à acquis Calm.io mais va devoir faire évoluer le produit pour être capable de déployer les applications actuelles comme elle est déjà capable de le faire pour les applications futures. Toutes ces sociétés montrent une étonnante capacité à ne pas se créer des points de blocage pour aborder le futur sereinement.

devops_02_myvmworld

Ces acteurs peuvent dès aujourd’hui répondre aux besoins des entreprises pour simplifier l’infrastructure en supprimant des serveurs comme le SAN ou de faire disparaître le Fiber-Channel, simplifier les backups et profiter des PRA dans des conditions plus acceptable. Dans un deuxième temps il sera important de pouvoir mieux tirer profit de ces infrastructures pour déployer, déplacer… des environnements. Enfin, ces mêmes acteurs seront alors capables de répondre entièrement aux besoins du DevOps.

Aujourd’hui ces acteurs se battent sur le marché de l’infrastructure mais le nerf de la guerre s’est déjà déplacé sur le « provisionnement » des applications avec l’infrastructure associée et nécessaire (SDDC). Déjà certains d’entre eux se positionnent sur l’infrastructure et dans le même temps montent vers les couches logicielles.  Un œil comptable sur leurs marges pour constater qu’elles se rapprochent de celles des éditeurs de logiciels (85%). Tous ces acteurs sont d’ores et déjà capables de proposer la simplification mais certains anticipent l’optimisation de ces mêmes infrastructures (VCE, Nutanix par exemple). Le gagnant sera certainement celui qui arrivera à proposer une solution intégrée unique et capable de déployer aussi bien les applications d’aujourd’hui (Exchange, etc.) que celle de demain (Containers/Dockers). Quand et qui sera le premier à proposer la première solution « SDDC all in a box » capable de répondre à tous ces besoins ?

Article sur la problématique de l’évolution de l’infrastructure et dans la continuité de l’article ci-dessus : « Transition entre les infrastructures traditionnelles et le cloud natif avec l’hyper-convergence (VCE, Nutanix, Simplivity)« 

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

VMworld 2015 Barcelona- Ready For Any

Par défaut

Feedback autour du VMworld Europe 2015 : Ready for ANY !

Le VMworld 2015 s’est tenu tout récemment, du 12 au 15 octobre dernier et traditionnellement à Barcelone pour l’édition européenne. Dans une atmosphère toujours aussi décontractée et avec une logistique à la pointe, cet événement a proposé plus de 250 sessions, plus de 30 000 VMs ont été crées au Hands-On-Lab, et a réuni plus de 135 sponsors et 10 000 visiteurs dont une délégation française qui représentait à elle seule près de 500 professionnels.

myvmworld2015 - 1Révélation phare de cette édition : le rachat d’EMC par Dell pour un montant de 67 Milliards de dollars. L’éditeur californien a aussi fait état des nouveautés sur les offres vCloud NFV (virtualisation des fonctions réseaux), vCloud Air (Cloud public) et vRealize (software-defined data center); et a axé ses conférences sur la virtualisation de l’environnement utilisateur (VDI) et sur celle du réseau, avec notamment des éléments à souligner concernant les évolutions de l’offre NSX.

Introduction de l’évènement

Edition européenne oblige, la General Session a été introduite par Jean ­Pierre Brulard, vice-président senior et nommé en août dernier directeur général pour la zone EMEA avec pour ligne directrice : “Ready For Any”.

VMworld2015_myvmworld04Carl Eschenbach, président et COO de VMware, a ensuite pris la parole en faisant le focus sur la stratégie One Cloud, Any Application, Any Device. Par le biais d’une courte vidéo faisant témoigner Michael Dell, il est venu confirmer le rachat d’EMC. Via ce canal de communication, Michael Dell a ainsi témoigné de son enthousiasme concernant cette acquisition et du potentiel à devenir. Il a aussi souhaité rassurer les partenaires et clients sur l’autonomie que devrait conserver VMware et sa force d’innovation.vmworld2015_myvmworld08

Tous les interlocuteurs de cette édition on mis l’accent sur la création d’application Native Cloud, c’est à dire apporter aux entreprises les bénéfices d’une plateforme Cloud hybride unifiée avec des solutions pour gérer l’ensemble de ses environnements Cloud (privés, publics et hybrides) pour tout type d’applications (existantes ou natives Cloud) à partir de n’importe quel terminal.

Enzo Project

Lire la suite

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