2017 sera-t-elle l’année de DevOps NoOps ?

Ce blog vous fournit tous les éléments pour rester compétitif face aux entreprises numériques DevOps qui évoluent déjà vers le NoOps

French - Ron Gidron
Ron Gidron, March 6, 2017 10:00 am
Blog > AgileOps | ASO | ARA | DevOps | Agile | Digital Transformation > 2017 sera-t-elle l’année de DevOps NoOps ?

Si DevOps poursuit la même trajectoire en 2017 que ces dernières années, les équipes de production pourraient rapidement devenir redondantes. DevOps pour les entreprises numériques n’aura besoin à terme que de développeurs pour pousser leur propre code en production. Alors comment des entreprises établies telles que la vôtre peuvent garder la dose nécessaire d’agilité alors que vous dépendez d’un mélange d’applications historiques et de nouvelles applications numériques ? Lisez le blog pour en savoir plus.

NoOps pour les start-ups ?

La croyance selon laquelle une organisation informatique a besoin d’une équipe de production est souvent incorrecte. Instagram a généré 1 milliard de dollars sans équipe production ; et lorsque Facebook les a rachetés pour ce montant, ils n’avaient aucun expert Opérations. DevOps signifie que Développement et Opérations vont bien au-delà de la simple coopération : chaque équipe s’enrichit au contact de l’autre. Idées et compétences sont décuplées et chacun comprend mieux l’intégralité du cycle applicatif et leur propre rôle dans ce cycle. Rien de neuf dans cette méthode, qui devrait d’ailleurs être appliquée à toutes les professions, que ce soit l’informatique, la médecine, la loi ou d’autres secteurs.

Si DevOps continue à gommer les frontières entre les deux disciplines, les pratiques opérationnelles pourraient tout à fait être mise en œuvre par des développeurs expérimentés. Ceci insufflerait de l’agilité en réduisant le besoin de coopération : DevOps serait un seul et même collaborateur.

Les entreprises qui partent de zéro dans le monde actuel de DevOps doivent être agiles et innovantes dans leur développement : les équipes de production ne devraient être recrutées qu’en cas de besoin impérieux. Une solution plus agile encore serait de ne recruter que des équipes de Développement soucieuses du déploiement de leur code.

A quel moment les équipes de production sont-elles absolument indispensables ?

L’un des inconvénients de ce modèle est que, en réalité, les développeurs démontrant les compétences et la volonté nécessaires pour accomplir les tâches opérationnelles pourraient bien hériter d’une charge de travail supplémentaire. Par conséquent, même les personnes les plus douées et les plus adaptables pourraient être frustrées et mal à l’aise, devenant dans le pire des cas, et ironiquement, des goulets d’étranglement pour tout le monde. Peut-être aussi le rythme de croissance de l’organisation va-t-il au-delà des compétences de ces développeurs doués, les contraignant à sortir de leur zone de confort.

Ce qui est important, dans cette situation, ce n’est pas simplement de recruter un profil production pour gérer toute cette charge de travail. Dans l’idéal, il s’acquitterait d’un minimum de tâches opérationnelles et ferait plutôt office de mentor pour les développeurs soucieux de connaître le côté opérationnel de DevOps, comportement que les développeurs devraient tous avoir, en théorie. Il est donc important de recruter quelqu’un dont les compétences divergent de celles qu’ont déjà l’équipe, pour apporter quelque chose de neuf à l’organisation, et transmettre ses compétences. Offrez un poisson à un développeur et il s’en nourrira une journée. Offre-lui une canne à pêche et ... vous voyez tout de suite le principe.

Quid des organisations traditionnelles ?

La réalité, c’est que toutes les entreprises ne sont pas des start-ups numériques dont la seule préoccupation est de publier des messages courts ou des images. La plupart dépendent d’applications traditionnelles et/ou d’un certain niveau de sécurité et de fiabilité pour réussir, dans le monde de la finance, par exemple. Peut-être dans les domaines qui privilégient la sécurité, les équipes opérationnelles seront-elles toujours indispensables.

Pour les entreprises établies souhaitant adopter un modèle NoOps, comment procéder ? Licencier toutes leurs équipes production du jour au lendemain ? Dans un contexte international, opérant en 24h/24h, nécessitant un déploiement continu d’applications distribuées, l’interruption de service n’est plus une option. Un scénario NoOps sans interruption de service majeure est par conséquent difficile à envisager.

Toutefois, votre entreprise doit s’adapter pour rivaliser avec le niveau d’agilité déployé par vos concurrents numériques. La réputation et l’histoire d’une entreprise ont été remplacés par deux prérequis fondamentaux dans l’esprit de ses clients : fonctionnalités et applications. Une réputation bâtie sur des décennies peut rapidement être ternie et oubliée si cette société ne va pas au bout de sa transformation numérique. Demandez donc à  Blockbuster le roi de la location vidéo, détrôné par les acteurs du streaming.

La réponse est AgileOps

Le Développement est déjà agile et il est conçu pour l’être. Si cette agilité n’est pas transmise aux Opérations, les silos sont renforcés au lieu d’être supprimés, surtout si la production utilise un outillage de déploiement ou des mécanismes d’automatisation différents. Pour rivaliser avec les entreprises nativement numériques, nous devons d’abord rendre les Opérations agiles. Voilà le vrai défi pour DevOps en 2016.

Aujourd’hui, le développement fonctionne mode projet/pipeline : intégration continue –> test –> provisionnement –> déploiement. Mais ensuite le code est poussé en production, un environnement toujours largement perturbé, et les Opérations ne parviennent pas à maintenir le rythme. Il est impossible pour elles de se fixer un plan précis, devant répondre simultanément à toutes les requêtes des autres équipes. Elles éteignent des incendies toute la journée et n’ont pas le temps de rendre leurs pratiques plus agiles.

Alors comment rendre les opérations agiles ?

Provisionnement automatisé

Les ordinateurs font ce que vous commandez, pas ce que vous sous-entendez. Introduire le libre-service pour les processus clé, chronophages lorsqu’ils sont manuels, comme le provisionnement de serveur, évite à la production d’être monopolisée. Ils peuvent donc réaliser des tâches à plus grande valeur ajoutée.

Automatisation cohérente du Continuous Delivery

Dans son livre « Continuous Delivery », Jez Humble affirme que vous avez besoin des mêmes mécanismes d’automatisation pour tous les environnements cible, une technologie capable d’appréhender de multiples environnements. Jenkins et d’autres outils équivalents, bien que tentants car open-source, sont inadaptés. Un produit d’Application Release Automation, couvrant l’intégralité de la chaîne d’outils, y compris l’ensemble des outils de développement et opérationnels, confère la cohérence requise et élimine les silos.

Une automatisation homogène transcende les équipes, qui peuvent évoluer professionnellement, dans leurs missions ou au sein de différents services. Le système est fiable et réutilisable, synonyme de pérennité de l’activité. Ainsi, lorsque vous intégrez de nouveaux employés, ils peuvent suivre un processus de travail standardisé au lieu de tâtonner et de récupérer des informations auprès de différents collègues.  Les passages de compétences complexes ne vous font pas perdre en agilité. Si, en 2017, vous devez rivaliser avec des entreprises nativement numériques, capables de travailler sans équipes de production, vos propres équipes doivent, elles, être aussi agiles que possible. Pour en savoir plus sur AgileOps, visionnez ce webcast.

 

AgileOps
ASO
ARA
DevOps
Agile
Digital Transformation
Back to the blog
French - Ron Gidron

Ron Gidron

Ron Gidron est Directeur du Marketing produit Release Automation chez Automic Software. Il a 14 ans d’expérience dans le marketing produit, le management de produit et l’avant-vente à la fois dans des startups et des grandes entreprises. Ron est fasciné par l’intersection des logiciels, des utilisateurs et des tendances du marché.