Et si Devops nous emmenait vers TDI (Test Driven Infrastructure) ?

Des usines de développement au service de l’infrastructure ?

Le mouvement DevOps a permis aux applications de gagner en productivité et donc en rapidité d’évolutions grâce entre autre à une démarche très efficace : le Continuous Delivery.
Grâce à un rapprochement des pratiques entre Dev et Ops on arrive à apporter aux équipes infrastructures tout l’outillage du développement d’applications. Et c’est là qu’arrive l’un des grands concepts Devops : Infrastructure As Code.

Les géants du web sont largement en avance sur ce que l’on fait aujourd’hui dans la majorité des entreprises. Surtout concernant la mise en place et le déploiement des infrastructures mais également sur un sujet encore peu exploré : l’automatisation des tests d’infrastructure.

On sait aujourd’hui parfaitement tester nos applications mais quid des infrastructures qui les hébergent et que l’on automatise de plus en plus ?

Pourtant, si on rentre dans Infrastructure as Code, on écrit bien du code, on a bien un cycle de vie habituel de code, il faut donc tester ce code!

Une chose est sûre, on doit tester de bout en bout tout ce que l’on automatise soit même.

(Lire la suite…)

Synthèse subjective de la conférence de l’EBG du 27/09/2012 – le marché des télécoms mobiles peut-il se restabiliser?

En tant qu’associé chez OCTO, en charge du secteur des opérateurs télécom, j’ai assisté récemment à une table ronde organisée par l’EBG dont le thème était: le marché des télécoms mobiles peut-il se restabiliser?

Le point de départ de la table ronde: le secteur était effervescent il y a un an, mais depuis janvier le mot qui circule est plutôt « déclin », notamment du fait de l’arrivée de Free en France. Cette arrivée a dans un premier temps provoqué un raz-de-marée sortant des opérateurs établis, pour arriver ensuite à un nouvel équilibre à l’été, semble-t-il. Ce nouvel équilibre établit un chiffre d’affaire global plus faible – le gain de chiffre d’affaire de Free est sensiblement inférieur à la diminution de ceux des autres opérateurs, notamment à cause des baisses de prix consenties par tous. SFR annonçait en août que la croissance revenait, mais récemment seulement. De façon durable?

En fait, plus largement cette baisse est le reflet d’un tassement du marché à l’échelle européenne, et pas seulement liée à l’actualité hexagonale. Alors, déclin inéluctable?

(Lire la suite…)

Devops corner, épisode 2 : Chef, les limitations

Cette épisode sera dédié aux limitations découvertes dans Chef; cet outil, même si je l’adore, n’est pas parfait ! Il est de plus intéressant de constater que les limitations que je vais présenter ici sont souvent aussi présentes dans les outils concurrents.

(Lire la suite…)

Les Patterns des Grands du Web – Commodity Hardware

Description

Bien qu’invisibles depuis nos navigateurs des millions de serveurs fonctionnent continuellement pour que le web reste disponible 24h/24. Même si les chiffres restent confidentiels, un seul grand acteur du web peut nécessiter des dizaines, des centaines de milliers de machines comme EC2[1] voire aux alentours de 1 million chez Google[2]. La mise en œuvre d’un si grand nombre de machines représente un défi technique mais surtout économique. La grande majorité de ces acteurs ont relevé ce défi en utilisant du matériel de grande série, du « commodity hardware » – terme que nous allons préciser par la suite.

(Lire la suite…)

L’Infrastructure agile

Les principes de l’Infrastructure agile

Au cours de la vie d’un logiciel, beaucoup de temps est consacré à son déploiement sur différentes plates-formes (recette, preprod, prod…). Bien souvent, nous réalisons des sous-projets de création d’environnements pour les logiciels nouvellement développés. Ce type de sous-projet est rarement capitalisé techniquement et peu contributeur à la valeur métier. Être capable de composer,  monter et démonter des environnements à la demande offrirait une flexibilité appréciable. Pour cela, il est efficace de standardiser les ressources d’infrastructure pour les utiliser comme des composants combinables. C’est ce que propose le cloud computing en offrant des capacités de production industrialisées sur Internet. (Lire la suite…)

Premiers pas dans les infrastructures auto-scalables

On parle d’une infrastructure auto-scalable quand on est face à un système qui est capable d’adapter dynamiquement sa capacité ou les services qu’il fournit en fonctions d’événements extérieurs, et ce pour en garantir un rendement maximum.

Ce article se veut un point de départ pour les prochains travaux que nous allons mener, visant à recenser les principaux enjeux, acteurs, technologies et les problématiques inhérents à ces systèmes. Commençons par formuler quelques questions sans avoir nécessairement la prétention d’y apporter toutes les réponses. Citons simplement celles qui nous viennent spontanément, nous aurons tout loisir de les remettre en question.

(Lire la suite…)

Datacenter as a Computer : une plongée dans les datacenters des acteurs du cloud

Dans ce papier (de 2009), Luiz André Barroso and Urs Hölzle (entre autres) de Google Inc. présente une introduction aux “Warehouse-Scale Computers” (abrégé WSC); une introduction aux grands datacenters du l’industrie du Web.

Alors certes c’est assez loin de notre quotidien (à la fois en termes d’échelle mais également en termes de métier car on ne construit pas tous les jours un nouveau datacenter) mais ce papier nous aide à nous projeter dans ce qu’est un datacenter chez les acteurs du Cloud d’aujourd’hui. Une merveille qui présente très certainement ce que seront nos datacenters traditionnels à terme, les impacts que cela aura sur les architectures applicatives.

L’objectif ici n’est pas de reprendre l’exhaustivité de ce papier de 90 pages mais de vous faire part des éléments, à mon sens, les plus marquants et qui s’articule autour de plusieurs axes :

  • Présentation des concepts généraux d’un datacenter, ses services, son organisation (Alimentation électrique, gestion de climatisation…)
  • Un zoom particulier sur les serveurs qui composent un datacenter
  • Une analyse très détaillée des enjeux énergétiques associés
  • Une discussion (et des études de cas) autour des TCO
  • Un zoom particulier sur les pannes et leurs origines

(Lire la suite…)

ITIL v3: La gestion du cycle de vie de services

 

En 2007 ITIL (IT Infrastructure Library), a lancé sa version V3 en devenant le référentiel le plus répandu de bonnes pratiques pour le management de services informatiques (ITSM). Il se focalise sur le « comment » gérer chaque phase d’un service, en contraste par rapport à des autres référentiels qui se focalisent sur le « quoi », ce qu’on doit gérer.

ITIL v3 élargit le périmètre en donnant une vue “cycle de vie” des services, par rapport à sa deuxième version (v2) qui se focalisait sur les processus pour le Soutien de Services (Service Support) et la Fourniture de Services (Service Delivery)[i],

Cet article vous présente d’une façon globale ITIL à l’égard de la version 3 en montrant son but, les bonnes pratiques proposées pour gérer chaque phase d’un service et ce dont il faut tenir compte pour l’adoption de ce référentiel.

 

(Lire la suite…)

Comment Puppet, Cfengine ou Chef peuvent aider études et production

Pour faire suite à l’article d’introduction sur le mouvement des DevOps, nous pressentons que, dans leur lourde tâche, nos héros vont devoir s’appuyer sur un certain outillage leur permettant de fluidifier la phase de Mise En Production ; qui dit fluidification dit appli déployée plus vite et le business traduit ça par : « la fonctionnalité va arriver bien plus vite au client ». Et le business aime ça.

L’utilisation du shell est une solution, mais qui montre ses limites. Il est temps de faire appel à d’autres outils. Voici un rapide tour d’horizon de quelques instruments de déploiement automatisé et de leurs principes.

(Lire la suite…)

Les 3 S de l’administrateur UNIX, saison 3

Nous avons vu dans les articles précédents comment ssh permettait à Bob de chiffrer ses connexions aux serveurs, comment sudo permettait de restreindre et de tracer qui fait quoi, et comment screen pouvait éviter à Bob de perdre du temps. Fort des ces outils, Bob a commencé à automatiser plusieurs tâches, mais se heurte à des problèmes d’échelle : taper une fois un mot de passe passe, mais cent fois trois mots de passe ne passe plus. (Lire la suite…)