Avec l'avénement du DevOps et du cloud public, quel avenir reste-t-il pour les Ops ? Dans cette conférence, Adrien Blind et Ludovic Piot présentent les mutations en cours du métier des Ops. Conférence jouée au DevOps D-Day 2016 et lors du Treeptik/Nutanix DevOps Tour 2017.

1. by Adrien Blind
DevOps Coach & Docker Captain
@adrienblind
by Ludovic Piot
DevOps & architecture consultant
@lpiot
DevOps, Microservices, le cloud…
Quel futur pour les Ops ?

2. by Adrien Blind
DevOps Coach & Docker Captain
@adrienblind
by Ludovic Piot
DevOps & architecture consultant
@lpiot
May the 4th! be with U… always

3. Un contexte en pleine
mutation

4. Dimension organisationnelle
Build Run
App
Infra
Mur de la confusion:
Objectifs orthogonaux = frictions 
Porté par l’innovation
et la vélocité
Porté par la
rationalisation et la
stabilité

5. Le mur de la confusion
 Depuis toujours, DEVs et OPS s’opposent à
cause d’objectifs antagonistes...
 Les DEVs recherchent :
• la rapidité de mise à disposition des nouvelles
fonctionnalités aux utilisateurs finaux
• culture du produit
 Les Ops recherchent :
• la stabilité, la robustesse
• la maîtrise, la performance
• la sécurité
• l’industrialisation
• l’efficience économique
• culture du service
 Mais il y a confusion : ces objectifs sont des
objectifs intermédiaires et non exclusifs !
Oxalide © 2016 – D
Depuis toujours, DEV et OPS s’opposent à ca
d’objectifs antagonistes…
Les DEV recherchent :
• la rapidité de mise à disposition des nouve
fonctionnalités aux utilisateurs finaux
• culture du produit
Les Opsrecherchent :
• la stabilité, la robustesse
• la maîtrise, la performance
• la sécurité
• l’industrialisation
• l’efficience économique
• culture du service
Mais il y a confusion : ces objectifs sont
objectifs intermédiaireset non exclusifs!
Le mur de la confusion

6.  L’agilité est progressivement entrée dans les mœurs
des DEVs
 … mais cela engendre de nombreux challenges pour les
OPs
 Immédiateté des ressources nécessaires pour couvrir les
itérations
 Chaque itération va jusqu’à la production !
 …
Emergence du continuous delivery

7.  Résilience et scalabilité portés par
l’architecture logicielle
 Microservices, scalabilité horizontale, designed for
failure…
 Commoditisation de l’infrastructure
 Le cloud propose des solutions en résonnance
avec les archis applicatives actuelles
 Perte de sexyness pour les ops
 Plus de design d’infra ad-hoc
Evolution de l’architecture applicative

8.  Software is eating the world : des solutions « Infra-as-Code » de
plus en plus tournées vers les DEVs
 Vagrant, Docker sont des outils d’OPs pensés pour les DEVs
 Gain d’autonomie important, illusion de maîtrise: NoOps ?
 Homo-opsus est il déjà mort ?
 Des outils pas nécessairement conçus pour eux
 De nombreuses connaissances à acquérir
 Une offre de valeur à réinventer
Des tendances Ops…. Pour les Devs

9. La software factory : réconciliation
L’usine logicielle,
utilisée par les DEV,
nécessite le savoir-
faire des OPS :
• forts besoins en
optimisation
d’infrastructure
• forts besoins en
automatisation
« système »
Usine logicielle
Build
local
Notifications
Documentation
& Indicateurs
Référentiel
binaires
Build
Récupérer
les dépendances
Compiler
Exécuter les tests
Build
Packager
Déployer
Documenter
Vérifier la qualité
du code
Plateforme
de tests
Référentiel de tâches
et anomalies
Serveur
d’intégration
continue
Gestionnaire
de sources

10. Des solutions réalistes

11. Une approche portée par le produit
Build Run
App
Infra
Produit métier
Produit Infra
Feature team de
BA/DEVs/Ops, agile
et portant l’ensemble
du cycle de vie de
leur produit
Le meilleur ami d’un
OPs est le DEV qui
construit la
fonctionnalité qu’il
déploie et opère

12. Un exemple avec Docker
DevOps Apps team
Dans les conteneurs
 Ignore où les conteneurs
fonctionnent
 Sait comment builder les
conteneurs et opérer les
apps
“You build it, you run it!”
DevOps Infra team
Hors du conteneur
 Ignore comment les
images sont buildées
 Sait comment gérer de
grandes quantités de
conteneurs

13. Un exemple avec Docker
 Maintenance des layers
sous-jacentes
 Monitoring du contenu
des containers
 Patch management

14.  Ne plus être le robot, inventer le robot
 Etre moins opérateur, et plus co-créateur
 Des managers d’OPs à transformer en leaders de
communautés transverses
 Recréer de la proximité requiert possiblement de
« dérationaliser »
Un challenge de leadership

15. Infrastructure as code
1. Provisionner
2. Configurer
3. Opérer
Cloud IaaS - PaaS
IT historique
Décrire
l’environnement
de l’application
“Piloter l’infrastructure avec des paradigmes et des outils de développeurs”
API
+
code
Produit métier Produit Infra

16.  Software-Defined-Everything : créer et
consommer des interfaces programmatiques
 Apprendre de la transformation des DEVs
 Intégrer les preceptes de l’agilité : proximité client
et itérations!
 Développer le craftsmanship (TDI avec serverspec
par exemple)
 Une approche budgétaire itérative!
L’infra est un logiciel comme un autre

17. Plateforme
Continuous
Delivery
“Réconcilier le cycle de vie de l’application et de son
infrastructure dans un pipeline commun”
Pipeline automatisé
DEV UAT PROD
Infrastructure as code

18.  Le cloud public est voué à prendre une
importance grandissante
 Vous porterez peut être de moins en moins vos
assets en propre
 L’enjeu porte sur l’orchestration des topologies
et l’hybridation du SI
Devenir un chef d’orchestre

19.  Supervision et monitoring restent de mise
 Extension du sujet à la métrologie, afin d’améliorer le
feedback applicatif et fonctionnel
 Là aussi, les paradigmes/outils de DEVs prévalent
désormais (bigdata, etc.)
Et la métrologie serait l’autre clé ?

20. Vraiment, plus de
sexyness pour les Ops?

21.  What
 Historiquement plus centré sur
l’abstraction des couches basses
 Plus proche du FaaS/event-driven
programming (like AWS Lambdas)
 Why / Pros
 Eviter d’avoir des serveurs attendant
perpétuellement des requêtes
 Une démarche encore plus orientée vers
l’immuabilité
 Cost savings avec un business modèle
adapté (paiement à l’appel)
 Pitfalls / Cons
 Encore assez jeune, faible maturité
Serverless / Event-driven prg.
OpenWhisk frameworkGoogle Trend results for
« serverless »

22.  Why / Pros
 Hypervisors now replace what OS were aimed at:
sharing scarce resources & creating abstraction
 Shrink amount of regular OS to manage : cost saving
 Efficient : 6ms boot time,
 Limited surface attack, quality through immutability
 Pitfalls / Cons
 More difficult to debug low-level issues!
 Some great features miss by design (mem. isolation)
Unikernels
 What
 Micro-OS only able to run the app bundled
with it (no SSH, etc.)
 App is part of the kernel (shared mem, etc.)
 Immutable approach : build an image
containing the app and it’s dedicated OS
 Really full-stack, self-sufficient images
 Maybe automatable with Docker paradigms
in near future

23.  What
 Tiny SoCs based on ARM architecture
 Poor per-core perf but up to 54 cores per SoC
 Why / Pros
 Green IT: better perf/watt & density ratio
 Cost efficiency for massive threading usecases: micro srv,
but maybe bigdata/grids too?
 Pitfalls / Cons
 Litteraly rebuild apps for ARM
 Only fits some usecases, not a silver bullet!
ARM: end of the x86 hegemony ?
ARM v8 architecture
Up to 54 cores/SoC + 1TB RAM
Cavium srv: 384 cores enclosed in 2U

24. SERVERLESS / Lambda Arch.
UNIKERNELS
Quelques pistes à creuser parmi tant d’autres…
Vraiment, plus de sexyness pour les Ops ?
ARM

25. Conclusion

26.  Le métier des OPs ne disparait pas, il évolue
et se réorganise
 Penser produit, produit, produit !
 Il y a encore de la sexyness pour les Ops !
Un sujet DevOps finalement…

27. Ca n’existe pas!

28. Increase impacts…
LEARN FROM YOUR PRODUCT
FOSTER COLLABORATIONRELEASE FREQUENTLY
LOWER STRESS AND RISK
SHIP confidently & faster the product
Product-centric
Software oriented
Change oriented
Deliver rapidely new
features with quality
Application teams (DEVs)
fosters INNOVATION
Stability oriented
Ensure proper run of
applications
Operation teams (OPs)
fosters RATIONALIZATION
Service-centric
Server, storage,
databases
Committed together toward the whole product’s lifecycle
“You build it, you run it”
Different objectives
leading to
confusion & friction
≠
e.g. INFRA is becoming SOFTWARE
(Infrastructure as Code)
DEV practices shared with OPSOPS practices shared with DEV
01101
01010
10010
e.g. MEASURE EVERYTHING
(From monitoring to Metrology)
CULTURE
AUTOMATION
MEASURE
SHARE
©OCTOTechnology

29. Merci!