[Oldies] Club client D2SI : DevOps

©2013 Property of D2SI 1

DEVOPS en pratiqueMatinée Club clients d2si – 21 juin 2013

Laurent B. Consultant DevOps & Cloud

Bruno C.Consultant Méthodes Agiles

Clément C. Développeur Java


Travailler avec des Lots Plus PetitsAdapté de Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach, CA, USA : Celeritas Publishing, 2009. ISBN 978-1935401001.

http://www.amazon.fr/dp/1935401009




Taille de Lot Optimale

Coût d'AttenteCoût de TransactionCoût Total

Taille de LotAdapté de Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach, CA, USA : Celeritas Publishing, 2009. ISBN 978-1935401001.


Constat: accélération de la demande métier

?


Continuous Delivery

Request Approve & Prioritize

Technical Assessment Code & Test Verify & Fix Deploy

20 min 2 min 15 min 2 h 4 h 3 min

½ week 2 weeks 2 weeks 1week ½ week

Exécution = 6 h 40 min Attente = 6 semaines

Objectif: réduire le temps entre le commit du code et le déploiement

Adapted from Implementing Lean Software Development: From concept to Cash, Mary & Tom Poppendieck, 2006


Continuous Delivery en pratique

Repository

Version Control System

Source Code

Continuous Integration

Feedback

Source Code

Deploy

BuildAnalyze Code

Env 1 Env 2

Automatisation: Capacité à livrer des fonctionnalités beaucoup plus rapidementMais aussi: Processus fiables et répétables entre les différents environements

©2013 Property of D2SI

Démo


Quel impact sur le reste de l’écosystème?


Deploy

Test

Le Continuous Delivery étendu à l’infrastructure

CommitVersionBuild

Automated tests Build test env

Create Linux VM

Create Apache

OS

VM

Conti

nuou

s D

eliv

ery

OS

VM

OS

VM

Web Server

Conf Apache Upload pages

Create Tomcat Conf Tomcat Upload WAR

Application Server

Create MySQL Conf MySQL Apply DDL

Database

Destroy test env

Unit TestPackage

UATBuild UAT env Destroy UAT env

Production Deploy to PROD

Prod

uctio

n

Incident Build PREPROD

Diagnostic

Fix

Destroy PREPROD

Infrastructure programmable


La situation actuelle


ProvisioningCombien de temps pour mettre à disposition l’infrastructure nécessaire à une application ?

Request management

Application infrastructure

Web Server

Application Server

Database

1. Commander des serveurs2. Racker, connecter les serveurs au réseau / SAN3. Allouer de la volumétrie sur le SAN4. Installer et configurer les OS5. Installer et configurer les composants Middleware/Base de données

SAN

Réseau

OS

Application Server

Physique: 2-3 moisVirtuel: 2-3 semaines


OS

Database

Load Balancer

OS

Application Server

OS

Load Balancer

Web Server

OS OS

Web Server

OS

Application Server

Failover

Livraisons

OS

Application Server

OS

Database

OS

Web Server

OS

VM

Application Server

OS

VM

Database

OS

Web Server

VM

Préproduction ProductionTest

Description des environnements

Binaires

Configuration

Les livraisons sont manuelles, dans des environnements hétérogènes et complexes, les applications souvent insuffisamment testées=> Proportion d’échecs importante (parfois >50%)


Méconnaissance du DEV par les OPS

• Les besoins DEV et métier– « Le standard pour les serveurs d’application java est Weblogic » Les équipes de DEV ne font plus de J2EE mais du Spring et utilisent Tomcat sur leur poste

– « On n’a pas de serveur overclocké au catalogue » Si on en avait le métier X pourrait gagner 20% de plus

– « On a un incident sur l’application Z, c’est la catastophe »– « OK, OK, ça sert à quoi Z? C’est plus grave que l’incident sur Y??»– « Aucune idée » Difficile de se sentir impliqué et motivé quand on ne connait pas les enjeux

• Les méthodes de DEV– Les équipes OPS développent de plus en plus (outils, automatisation) Les outils sont souvent insuffisamment testés, les interfaces vers les autres outils ignorées


Méconnaissance des contraintes OPS

• Disponibilité: « Je veux une infrastructure 100% disponible » Les pannes sont inévitables et il faut des fenêtres d’intervention

• Performance: « Je veux que mon application soit plus rapide à Hong Kong » Si l’application est à Londres, la latence réseau est inévitable

• Scalabilité: « Je veux recevoir deux fois plus de clients » On ne sera pas toujours capable de trouver de serveurs deux fois plus puissants

Les coûts de cette méconnaissance des contraintes OPS sont très élevés

OS

Database

Load Balancer

OS

Application Server

OS

Load Balancer

Web Server

OS OS

Web Server

OS

Application Server

Failover

?


Diagnostics et confiance

• Diagnostics « Mon application est lente »

– C’est vague Difficile d’objectiver la critique

– Réaction OPS1. Attends, je vais regarder…. Ce n’est pas mon load-balancer2. Ce n’est pas serveur WEB3. Ce n’est pas mon OS…4. « Chez moi tout va bien » Les diagnostics sont très longs et n’aboutissent pas toujours

• Transparence en cas d’incident– Les OPS ont tendance à maintenir le flou (« Finalement ,on ne sait pas trop »)– Les DEV ont tendance à maintenir le flou (« Non, non on n’a rien changé. Enfin si mais ça n’avait rien à voir »)– Les OPS et DEV sont invités au fingerpointing (« Ce n’est pas un problème chez moi »)

OS

Database

Load Balancer

OS

Application Server

OS

Load Balancer

Web Server

OS OS

Web Server

OS

Application Server

Failover


DEVOPS


DEV et OPS, beaucoup d’incompréhension

StabilitéRationalisation

Nouvelles fonctionnalitésInnovation

« Wall of confusion »


Les bases du DevOps

Culture

Automation

Measure

Share


Measure, AnalyzeAnd Describe

Constraints (from DEV and OPS)Best practices, methods

Automation

Measure

Share

Culture

Continuous Integration Delivery Agile Infrastructure

Align objectives on business needsInnovate

Les grandes composantes du DEVOPS


Infrastructure Agile

Provisionning

Configuration des ressources

Déploiement des applications

Fournir des ressources de manière automatisée -serveurs (physiques, virtuels, dans le cloud)-middlewares, bases de données

Définir l’état des systèmesVérifier que les systèmes sont dans le bon étatMettre les systèmes dans l’état souhaité

Fournir un service de déploiement d’applications• Industriel / Rejouable / Reversible

Auto

mati

satio

n

SA

OO

kickstart/cloudforms

cloudformation

CDAJON


Mesurer et analyser

OS

Database

Load Balancer

OS

Application Server

OS

Load Balancer

Web Server

OS OS

Web Server

OS

Application Server

Failover

Requests/secondEstablished connectionsConfiguration

StateRequests/secondConfigurationService time

CPU usageRAM usageIOPSProcessesConfigurationLogs

Correlation

Dashboard

History

Configuration

Mais aussi, Watts, coûts, temps de mise à disposition…

Appli

Infra


Mesures applicativesConstruire le monitoring avec l’application

Evènements métiers (deals)

Sécurité (accès refusé)

Temps de réponses

Correlation

Dashboard

History

Configuration

Appli

Infra


Mesurer, analyser et partager• Avoir une vision détaillée et fine de ce qui se passe

• Avoir une vue d’ensemble

• Analyser des données réparties et volumineuses

• Partager ces outils entre OPS et avec les DEV

Application

Serv

eurs

Stoc

kage

Rése

au

SGBD

MDW

OS

Database

Load Balancer

OS

Application Server

OS

Load Balancer

Web Server

OS OS

Web Server

OS

Application Server

Failover

Index

IndexAnalyse & Presente

Appli

Infra


Culture et partage

• Aller dans la même direction Etre aligné sur les enjeux métier Impliquer les OPS dans les projets Impliquer les DEV dans les évolutions d’infra Diagnostiquer/améliorer ensemble au lieu de chercher des responsables

• Partager les méthodes et enjeux OPS: Utiliser les méthodes du DEV pour les outils OPS

• Version Control• Tests• Environnements de validations

DEV: comprendre les contraintes de PROD et repenser les applications• Disponibilité: peut-être plus efficace si c’est l’application ou le middleware qui gère?• Performance: si on peut se passer d’une base relationnelle envisager le NoSQL• Scalabilité: éviter les architectures « stateful »


DEVOPS, vue d’ensemble

Repository

Version Control System

Source Code

Continuous IntegrationD

evel

oper

s

Feedback

Source Code

Deploy

BuildAnalyze Code

EnvCreate

environment

Provision

ConfigureMeasure &

analyze

OO


Conclusion• Enjeu principal : aligner DEV et OPS sur les besoins métiers

– Avoir une vision de bout en bout– Optimiser la livraison de nouvelles fonctionnalités– Comprendre les applications dans leur ensemble– Innover, faire de l’amélioration continue

• Principaux axes– Automatisation– Mesure– Partage des objectifs, des méthodes et des enjeux– Culture de la collaboration

Un enjeu d’organisation et de culture bien avant les outils

Métier

OPSDEV


Questions ?

[Oldies] Club client D2SI : DevOps

Technology

Transcript of [Oldies] Club client D2SI : DevOps