Il existe aujourd’hui autant de définitions de DevOps que d’acteurs sur le marché, chacun cherchant à l’orienter en fonction de son activité et ses intérêts. Cette richesse a fait émerger un certain nombre de contre-vérités qui ont fait naître des idées reçues pas toujours très heureuses.
Nous vous proposons de revenir sur les plus répandues et de partager notre point de vue que nous espérons cohérent avec l’ensemble des approches, démarches et pratiques DevOps que nous avons pu exposer.
De notre point de vue, DevOps est compatible avec ITIL et les pratiques ITSM (IT Service Management). Nous pensons même que DevOps est complémentaire d’ITIL.
En effet, ITIL apporte un cadre ou framework permettant d’industrialiser ses processus de production qui paraissent absolument nécessaires pour conserver une rigueur suffisante, surtout, lorsque le rythme de mise en production s’accélère considérablement dans le cadre d’une mise en œuvre des démarches DevOps.
ITIL en tant que receuil de bonnes pratiques n’est en rien opposé aux possibilités d’automatisation qu’apportent les démarches DevOps. Il ne faut simplement pas tomber dans l’excès de formalisation en voulant mettre en œuvre tout le référentiel ITIL sans réfléchir à la valeur apportée par ces concepts. Le just enough process s’applique tout particulièrement dans notre cas.
Non seulement DevOps ne remplace pas les principes de l’agilité mais DevOps est totalement agile et en applique les principes, les utilise et les intègre complètement dans son approche.
Dans le même temps, les méthodes agiles ne sont pas un prérequis à une démarche DevOps, mais un minimum de pratiques agiles doit néanmoins être implémenté. Il ne s’agit pas nécessairement d’adopter une méthode agile en tant que telle mais de mettre en œuvre les pratiques qu’elle inspire dans votre contexte.
Si l’automatisation est au cœur du support technologique des approches DevOps et s’il s’agit selon nous de l’un des piliers de l’outillage de la démarche, ce n’est absolument pas l’élément fondamental de DevOps.
L’automatisation vise à supporter une collaboration pour la pérenniser et la diffuser. Si votre collaboration est déficiente, elle ne sera pas meilleure une fois automatisée. Le cœur de DevOps vise donc à rétablir des mécanismes de collaboration basés sur une confiance réciproque retrouvée.
La confiance est bien plus difficile à construire que l’automatisation et elle est bien plus importante.
Il est vrai que l’aspect automatisation intéresse beaucoup les éditeurs et les experts en différentes technologies, y compris open source, qui peuvent le supporter et qui visent de s’imposer sur ce marché. Mais là n’est pas le cœur de DevOps qui se veut avant tout une transformation culturelle.
Résumer DevOps à l’automatisation est donc une erreur même s’il ne faut pas négliger son importance dans la démarche.
La notion d’infrastructure as code est le bras armé de l’automatisation dans l’esprit de ceux qui cherchent à résumer DevOps aux outils et technologies. Parce que DevOps est avant tout une approche et une culture et non un assemblage d’outils, nous ne pouvons que contredire cette affirmation.
La totalité des arguments différenciant DevOps d’une simple démarche d’automatisation peut de nouveau être appliquée. Si infrastructure as code résume pour certains l’idée que l’on peut se faire de DevOps, elle ne reste qu’une pratique parmi tant d’autres, qui contribuent à cette démarche.
DevOps a connu un essor particulier dans la communauté open source qui l’a vite adopté, et a rapidement proposé des solutions technologiques permettant d’outiller les pratiques associées à la démarche.
Néanmoins, il existe de nombreuses implémentations réussies de pratiques et approches DevOps s’appuyant sur des technologies ou des produits commerciaux. DevOps ne peut donc se résumer au monde de l’open source.
Si les pratiques DevOps cherchent à automatiser des tests, des mises en production ou du monitoring par exemple, de nombreuses solutions technologiques peuvent être utilisées, voire combinées, inclure des solutions open source et des solutions d’éditeurs, voire des solutions issues de vos propres équipes.
DevOps est une culture et une démarche mais certainement pas un cadre technologique prédéfini.
DevOps est parfois interprété comme la fin des équipes de production et d’infrastructure (No-Ops) qui deviendraient alors totalement inutiles. On prête même ce nom à des organisations qui auraient complètement supprimé ce pan des équipes informatiques, souvent en se proclamant full cloud ou full web.
Cette affirmation est fausse. D’abord, parce que DevOps ne se limite pas à ce type d’organisation mais surtout parce que même si ce poste n’existe plus en tant que tel, les activités propres aux équipes de production continuent d’exister.
En effet, si DevOps est une approche de collaboration, il faut être plusieurs pour pouvoir collaborer. DevOps ne vise donc pas à encourager l’extinction naturelle des équipes opérations mais tout au plus à transformer partiellement leur rôle pour tirer le maximum de valeur d’une collaboration réussie.
Donc non, DevOps ne signifie la fin des Ops, bien au contraire, DevOps prépare l’avenir des Ops.
C’est parfois le désir profond de certains managers qui veulent implémenter une approche DevOps mais, comme nous l’avons vu, il existe de nombreuses organisations possibles pour mettre en œuvre DevOps.
Il n’est donc en rien obligatoire de fusionner les Dev et les Ops que ce soit dans la hiérarchie ou au sein d’une même équipe dédiée à l’implémentation d’un domaine fonctionnel.
Il est important de distinguer la fusion des équipes de la fusion des rôles. La fusion des équipes est possible avec des rôles distincts mais sans que cela ne soit un prérequis ni même une recommandation formelle pour mettre en œuvre DevOps. Par contre, la fusion des rôles n’est clairement pas recommandée.
Parfois, dans le cadre d’une transformation DevOps, les développeurs ont pu être tentés d’adopter en priorité les pratiques qui leur apportaient de la valeur directement avant de penser à une forme de collaboration plus globale.
Fort heureusement, cela ne s’inscrit pas dans une volonté d’opposer les parties prenantes, bien au contraire, et autant les développeurs que les équipes de production ont intérêt à adopter ces pratiques.
Cette affirmation a été souvent utilisée pour bon nombre d’innovations. Quel serait l’intérêt de DevOps, si les apports de cette démarche se limitaient uniquement dans les petites entreprises où les personnes ont un profil plus polyvalent et où les risques sont relativement limités ?
Pourquoi chercher à améliorer la collaboration lorsque les équipes informatiques partagent deux bureaux et lorsque le métier est dans le bureau d’en face ?
Vous l’avez compris, les démarches DevOps apportent le cadre et la rigueur nécessaires pour faire collaborer de nombreuses personnes de manière efficace. DevOps n’est donc ni lié aux start-up qui l’adoptent naturellement, ni à la taille de l’entreprise.
Par ailleurs, le support technologique important qui peut être apporté à ce type de démarche amène à penser qu’elles ne peuvent être implémentées que dans des architectures web.
Il est peut-être parfois plus complexe de mettre en œuvre ces principes sur d’autres architectures plus traditionnelles mais ils ne sont en rien spécifiques aux architectures web, petites ou grandes. DevOps n’est lié ni au développement web, ni à internet.
DevOps est une approche de collaboration qui est agile. Les méthodes agiles, sans être un préalable nécessaire, sont parties intégrantes de la démarche.
De la même manière, DevOps n’est en rien incompatible avec ITIL et les deux approches sont complémentaires. L’implémentation d’ITIL doit néanmoins chercher à respecter le principe du just enough process.
DevOps n’est pas un cadre technologique prédéfini et n’est pas limité à la communauté open source. L’automatisation et les pratiques telles que l’infrastructure as code ne sont que des supports à cette approche et sa culture.
DevOps n’impose aucune organisation particulière, et ne préconise pas un modèle No-Ops. La fusion des équipes dev et ops est possible sans être ni nécessaire, ni particulièrement préconisée. La fusion des rôles n’est pas recommandée car elle n’offre pas de certitude sur la valeur apportée.
Enfin, DevOps ne se limite pas aux petites équipes. DevOps est totalement adapté aux grandes équipes, aux grandes entreprises et aux grands défis.