CR du petit-déjeuner DevOps en pratique du 11/10/2012 - OCTO Technology et TIBCO

Speakers :

Arnaud François Fausse : Responsable infrastructure et Opérations chez OCTO

Stéphane Mahmoudi : National Account Manager chez TIBCO

Agenda :

1/ DevOps : Principes et mises en œuvre

2/ Outillage et mise en œuvre DevOps

3/ Démonstration

4/ Questions / Réponses

OCTO et TIBCO se sont associés pour ce petit-déjeuner car ils partagent la même vision de DevOps et une façon similaire de l’appliquer concrètement. Faciliter les liens entre les Dev et les Ops, réaliser des améliorations concrète et rapide et proposer une approche incrémentale sont des éléments importants.

1/ Principes et mises en œuvre :

Contexte :

La MEP ainsi que la gestion des incidents dans le déploiement représente en moyenne la moitié du temps consacré par les Ops dans leurs travaux. Donc le Time To Market (TTM) est d’autant lent que les applications arrivent doucement en production.

DevOps permet de diminuer cette difficulté du déploiement, de diminuer le TTM générateur de chiffre d’affaires. Il est essentiel de diminuer cette frontière du passage en production des applications. Les objectifs entre les Dev et les Ops sont différents ; les Dev vont s’attarder à innover, répondre aux besoins métier et vont avoir une culture du produit, alors que les Ops vont eux vouloir garantir le SLA, stabiliser leur environnement et auront une culture du service. Le passage d’un groupe à l’autre n’est donc pas aisé et DevOps permet de diminuer cette barrière et de rendre le run plus facile.

Définition :

C’est un ensemble de pratiques qui visent à diminuer le TTM et améliorer la qualité logicielle (pratiques techniques, organisationnelles, méthodologiques…) qui améliorent le passage Dev => Ops.

• Cet ensemble de pratiques touche 4 grands domaines :
• Des architectures et patterns qui répondent aux Dev et Ops
• Une extension de la construction et de la livraison continue
• L’infrastructure as a Code
• Une culture, des méthodes, organisations qui vont transformer ces pratiques et relations en Dev et Ops.

1- Des architectures et patterns qui répondent aux Dev et Ops

Les architectures et patterns qui répondent aux Dev et Ops : l’objectif est de rendre les applications faciles à mettre en prod, substituables, observables et analysables.

Il faut donc dissocier le déploiement fonctionnel et le déploiement technique. Grâce au Feature Flipping, il est par exemple possible de déployer une application sans mettre en route toutes les fonctions embarquées : quand je veux je mets les fonctionnalités sur ON mais si elles bugguent, ne plaisent pas, je peux le remettre en OFF. Le Dark Launch permet le déploiement d’une application où les clients qui l’utilisent vont travailler « normalement » mais où les IHM travaillent par des fonctions cachées avec le serveur (permettant ainsi de debugger ou de tester en charge l’application sans que les utilisateurs ne soient gênés ou s’en rendent compte).

Il faut également savoir observer ce que l’on doit améliorer.  Il existe souvent des débats entre Dev et Ops sur les consommations, sur les éléments que l’on devrait avoir ou non… il est donc essentiel  de mesurer, de créer des tableaux de bord accessibles par TOUS avec des vues d’opérations.

2- Une extension de la construction et de la livraison continue

DevOps permet de diminuer la charge fonctionnelle par le déploiement et augmenter la fréquence de la MEP. Une question peut alors se poser : est-ce que mes utilisateurs vont suivre ? Il est donc essentiel d’utiliser les outils précédemment cités et de tester de manière continue du Build jusqu’à la production. On peut voir DevOps comme une extension de l’agile dans le monde de la production.

3- L’infrastructure as a Code

Aujourd’hui tout est virtualisé, mes infrastructures se comportent donc comme des actifs logiciels. Ce qui signifie que toutes nos méthodologies, nos outils peuvent se décliner dans l’infrastructure. On déploie, on teste… L’interpénétration est très forte. Il est donc possible de provisionner des environnements et être capable d’automatiser en écrivant du code et des descripteurs de l’infrastructure que l’on souhaité déployer. 3 blocs deviennent nécessaires : Application Service Deployment (ce qui connecte des applications et équipements pour en faire un système); Système Configuration (ce qui configure chaque composant de l’infrastructure) ; l’Infrastructure agile (une infrastructure de services virtualisés qui remet des ressources à la demande (cloud de tous composants d’infrastructure).

4- Une culture, des méthodes, organisations qui vont transformer ces pratiques et relations en Dev et Ops

(Ceci est ici une vision proposée).

Les applications s’appuient sur une infrastructure qui offre des services précis. Les personnes qui la font et l’opèrent ne font que de l’infra et les personnes qui s’occupent des applis sont aussi responsables de son run. Ainsi, lors de la MEP les Devs vont être responsables du fait que ça tourne correctement ou non. Chacun est donc responsable de ce qu’il fait :

Les Ops de livrer une infra avec des blocs (élasticité, SLA, Self Service, Pay as you go…)

Les Dev de faire le run applicatif et être en front des utilisateurs.

Tout ceci suppose donc une maîtrise, une éducation et une communication entre les deux groupes pour que les Dev prennent en compte les éléments d’infra. DevOps déplace donc bien la frontière et suppose une réforme et un travail sur de nombreux éléments, facilités par exemple grâce à l’utilisation du Lean Management et de l’agile : post mortem, 5 pourquoi, savoir dire non, Scrum, Kanban…).

Conclusion DevOps :

Démarche progressive :

La douleur provient souvent de la gestion des tests. Il semble donc essentiel de commencer par une amélioration des environnements de build et de tests pour acquérir une qualité et une reproductibilité supérieure.

Il est facile de progresser rapidement sur le bloc ‘infrastructure as a code’ sans tout révolutionner. Puis de raccorder cela aux progrès faits sur la partie continuous delivery (le déploiement devient plus facile si l’infra est maitrisée). La partie collaboration peut venir ensuite : binômer, montrer des tableaux de bords, parler entre les groupes et rendre des process systématiques, organisés et affichés. Une grille d’analyse des pratiques ainsi que des process établis peuvent devenir ici utiles pour permettre une véritable Road Map d’amélioration.

2/ Outillage et mise en œuvre DevOps

TIBCO Silver Fabric va permettre de définir un catalogue de services de stacks applicatifs (à l’intérieur duquel on trouvera des best practices ; à la fois celles de l’éditeur et de l’entreprise). Une administration qui va travailler avec ce stack applicatif peut être mise en place.

Ensuite il sera nécessaire d’avoir un self-service factory et un dev-factory pour permettre l’automatisation de la création des différentes entreprises.

Les ressources devront être partagées et toujours de façon industrielle et automatique.

La collaboration sera plus simple s’il y a des faits : on va pouvoir mettre en place une base de données qui va regrouper toutes les informations. C’est un outil d’analyse qui permet de faire du capacity planning.

Silver Fabric se définit alors comme : Demand driven optimization of heterogeneous platforms and applications on any infrastructure.

Quel type d’applications ?

Business Case Creation : il est important de se demander ce que ca va rapporter ? Quels seront mes gains en productivité, en élasticité ? Une proof of value et un ROI pourront être déterminés.

3/4/ Pour des raisons techniques nous sommes dans l'impossibilité de vous proposer la vidéo de ce petit-déjeuner. Nous vous prions de bien vouloir nous en excuser.