Chez PagerDuty, nous accordons une grande importance à notre implication dans la communauté DevOps. Nous partageons notre vision de notre parcours, de notre situation actuelle et de nos perspectives d'avenir, et nous restons bien sûr à l'écoute de la communauté ! Si vous suivez ce blog, vous avez probablement déjà vu… article précédent récapitulatif de notre Prévisions et tendances en matière de DevOps   webinaire Cette conférence réunissait quatre experts DevOps qui nous ont fait part de leur vision des évolutions en 2017 et au-delà. Si vous ne l'avez pas encore visionnée, vous pouvez encore la regarder. Regardez-le à la demande !

Dans la première partie de la discussion, nous avons abordé le généralisation du DevOps et son adoption en entreprise. Dans la seconde partie de notre conversation, nous avons examiné deux autres questions clés, plus précisément :

• La sécurité devient-elle une composante du modèle opérationnel DevOps ?
• Les équipes d'exploitation centrales vont-elles se rapprocher du code source de l'application ?

Je vous invite à visionner la webdiffusion originale et/ou lire l'article précédent Si vous ne l'avez pas encore fait. Si vous êtes déjà au courant, rejoignez-moi pour discuter des points suivants :

• Ilan Rabinovich, directeur de la communauté technique chez Datadog
• Chris Gervais, vice-président de l'ingénierie chez Pile de menaces
• John Rakowski, directeur du marketing produit chez AppDynamics
• Arup Chakrabarti, directeur de l'ingénierie pour PagerDuty

Plongeons-nous dans le vif du sujet !

La sécurité devient-elle une composante du modèle opérationnel DevOps ?

La sécurité devrait faire partie intégrante de chaque produit.

Ilan Rabinovich de Datadog trouve étrange que l'idée de sécurité soit considérée comme quelque chose de « nouveau » qui doive être ajouté à culture DevOps Il souligne que la sécurité fait partie intégrante des bonnes pratiques de développement logiciel et devrait être intégrée à chaque produit. De la même manière que les développeurs ont appris à tester tôt et souvent avec Intégration continue et Livraison continue Outre l'automatisation des tâches d'assurance qualité, les équipes DevOps doivent également automatiser la sécurité et l'intégrer à chaque commit. Il souligne que les équipes performantes intègrent la sécurité depuis des années. Le monde DevOps doit suivre les bonnes pratiques, à l'instar des organisations de développement les plus performantes, et aborder la question de la sécurité plus tôt.

Intégrez la sécurité dans vos processus

Chris Gervais de Threat Stack estime que la sécurité DOIT faire partie intégrante du modèle opérationnel en 2017. Bien qu'il reconnaisse certaines dépendances possibles lors de sa mise en œuvre, il assure que c'est faisable. Les équipes DevOps doivent saisir l'opportunité d'intégrer la sécurité au processus global, même si cela ne fait pas partie du modèle DevOps actuel de leur organisation. Gervais suggère d'intégrer la sécurité au cycle de vie du développement logiciel et produit, afin que chaque membre de l'équipe y soit sensible. Au lieu de percevoir la sécurité comme « l'équipe qui dit non », elle doit être intégrée aux bonnes pratiques et à l'automatisation. Si une équipe de sécurité distincte existe déjà, il est préférable de l'impliquer dans le DevOps. Il est important de l'intégrer rapidement et en amont afin qu'elle ne se retrouve pas en fin de processus. Son influence étant intégrée dès le départ, les négociations et les compromis habituels entre l'ingénierie, les opérations et la sécurité seront bien mieux pris en compte, et les livrables seront alignés sur les objectifs organisationnels d'agilité, de vélocité et de sécurité.

Dans cette optique, et en matière de collaboration en matière de sécurité, Gervais suggère d'engager des discussions préliminaires, partant du principe que l'organisation s'engage collectivement sur la voie du DevOps. Le DevOps doit donc contribuer à préparer le terrain et à créer des environnements de travail collaboratifs. Il prévient que ne pas impliquer l'équipe de sécurité dès le départ peut engendrer des blocages ultérieurs et ralentir inutilement les projets de développement. La sécurité doit être intégrée à la philosophie DevOps et ne plus être l'apanage de quelques-uns, mais bien l'affaire de tous.

La sécurité ne fait-elle pas déjà partie intégrante d'une bonne informatique ?

Interrogé sur la sécurité dans le cadre du DevOps, John Rakowski d'AppDynamics a répondu avec une pointe d'insolence : « La sécurité ne fait-elle pas déjà partie intégrante d'une bonne informatique et d'une informatique d'entreprise ? »

Il a ensuite affirmé que, dans ce cas, la sécurité fait également partie intégrante du DevOps, tout en reconnaissant qu'il peut exister un certain manque de communication entre les différents services informatiques. Rakowski souligne que le terme « DevOps » désigne en réalité la convergence des équipes de développement et d'exploitation, mais que la tendance de fond s'explique surtout par l'importance cruciale que revêt désormais la technologie pour les entreprises et leur réussite globale, au point qu'elle impacte tous les acteurs du secteur informatique. Cette importance se traduit par l'apparition de nouveaux termes, comme « BizDevOps », qui vont au-delà du simple cadre du développement et de l'exploitation. Il déplore l'émergence de nouvelles expressions similaires sur le marché, telles que « DevSecOps », qui ne font qu'accroître la confusion. La position éloquente de Rakowski est que la sécurité EST L'intégration proactive d'autres considérations essentielles, telles que les exigences métier et de sécurité, fait partie intégrante du DevOps, ou du moins devrait en faire partie. Il conçoit le DevOps comme englobant l'ensemble du cycle de vie du développement logiciel et la fourniture de ce dont l'entreprise a besoin.

L'automatisation dans le domaine de la sécurité

Arup Chakrabarti de PagerDuty entrevoit une future convergence entre sécurité et DevOps grâce à de nouveaux outils. Il évoque notamment les outils d'intégration continue capables de garantir la sécurité du logiciel dès sa conception, ainsi que la possibilité d'exploiter des outils d'analyse statique (comme les solutions d'inspection de code) qui contribueront à promouvoir les bonnes pratiques de test logiciel et, par conséquent, à favoriser la convergence avec les tests de sécurité. Il prévoit des gains d'efficacité grâce à une automatisation accrue dans le domaine de la sécurité, avec le lancement de nombreux outils dédiés à l'automatisation et à la collecte de données de sécurité. Arup se réjouit que les problèmes de sécurité soient pris en compte plus tôt dans le cycle de vie du logiciel. Il souligne toutefois qu'il est parfois trop tard pour effectuer des tests a posteriori : « Il est possible d'intégrer les tests de plus en plus tôt dans le cycle de vie, pour de meilleurs résultats. »

Les équipes d'exploitation centrales vont-elles se rapprocher du code source de l'application ?

Nous devons comprendre les besoins des uns et des autres

« Oui, nous devons mieux comprendre ce que chacun fait et ce qu’il fait », a commenté Rabinovich de Datadog prévoit qu'en 2017, les équipes de développement se rapprocheront de l'infrastructure et les équipes d'infrastructure se rapprocheront de la pile applicative, afin de résoudre les problèmes plus rapidement. Il a de nouveau insisté sur la collaboration : « Si nous ne comprenons pas les besoins des uns et des autres, nous ne pourrons pas répondre à leurs attentes respectives. » Il suggère que les échanges avec les utilisateurs et les chefs de produit permettront d'identifier les fonctionnalités nécessaires pour répondre aux besoins des clients, et que la proximité des équipes d'exploitation avec le code contribuera à éviter de « développer la mauvaise solution ».

Rabinovich suggère que si vous travaillez dans une organisation où l'équipe Ops centralise les services d'infrastructure et n'intervient pas nécessairement directement dans l'application, vous devrez savoir concevoir des API, des outils et une plateforme sur laquelle les applications sont déployées, et vous assurer de leur bon fonctionnement. Il souligne l'importance de services de déploiement logiciel robustes, permettant un déploiement et une mise à l'échelle aisés du code. Selon lui, il ne s'agit pas simplement d'utiliser une solution clé en main ; il s'agit plutôt de comprendre les besoins de l'équipe de développement produit et, simultanément, de bien cerner ceux des développeurs. Rabinovich note également que dans une organisation où les ingénieurs produit doivent transférer le code aux ingénieurs infrastructure ou opérations, ces derniers doivent savoir résoudre ou atténuer les problèmes et exploiter l'environnement de production en attendant la prochaine mise à jour ou le prochain correctif, car ce sont eux qu'on appelle en pleine nuit !

Ils le feront, et ils le doivent.

Chris Gervais de Threat Stack perçoit très clairement ce problème : « Ils le feront, et ils n’ont pas le choix – et la nature des informations partagées entre les équipes de développement et d’exploitation deviendra plus explicite. » Il a cité des équipes qui ont… microservices adoptés Il évoque ensuite l'externalisation des paramètres de configuration, un exemple parmi d'autres qui ont considérablement enrichi les outils de travail des équipes d'exploitation. Il suggère que ces dernières « n'ont pas forcément besoin de connaître le code source en détail », mais qu'en utilisant des outils de gestion de la configuration pour déployer, provisionner et mettre en service les ressources, elles peuvent mieux comprendre le fonctionnement des systèmes. Cela leur permet d'identifier les problèmes plus rapidement.

Gervais a expliqué que si les équipes d'exploitation comprennent mieux le fonctionnement des différentes applications, elles peuvent mieux cerner les besoins d'ajustement. Il entrevoit également une collaboration étroite entre les équipes de développement et d'exploitation, permettant d'effectuer des modifications via un guide de bonnes pratiques et des ajustements rapides. Il envisage aussi un avenir où les équipes d'exploitation pourront collaborer avec les ingénieurs pour réaliser des contrôles de santé et de performance liés à des outils comme les manuels d'exploitation, afin d'intervenir et de corriger les problèmes plus efficacement et de manière plus autonome.

Il explique ensuite que, dans un environnement où des contrats de partage d'informations ont été établis entre les équipes de développement et d'exploitation, ces dernières peuvent tirer parti des configurations externalisées et de la découverte de services. Ainsi, les équipes d'exploitation peuvent modifier les caractéristiques du logiciel et ajuster ses performances selon les besoins. Il considère cela comme un moyen de fédérer les équipes autour d'une communication efficace et de démocratiser l'accès à des informations autrefois cloisonnées. Car, comme le souligne Gervais, « en pleine nuit, disposer d'une procédure claire permet à l'équipe de prendre les bonnes décisions dès le départ », et donner aux équipes d'exploitation les moyens de modifier le code accélère la résolution des problèmes.

La réponse est simplement oui.

John Rakowski d'AppDynamics pense que le déménagement L'importance d'une collaboration étroite entre les équipes d'exploitation et le code source des applications « semble être un sujet brûlant actuellement », et « la réponse est tout simplement oui ». Selon Rakowski, les équipes d'exploitation devront être plus proches du code source qu'elles prennent en charge et le maîtriser parfaitement, notamment pour la fourniture d'applications et de services. Il constate également que, de la même manière, les équipes de développement devront se rapprocher des équipes d'exploitation, car il ne s'agit pas seulement d'écrire du code, mais aussi de la manière dont les produits associés à ce code contribuent à la performance de l'entreprise en termes de chiffre d'affaires, d'expérience client et de fidélisation.

Il ajoute que l'un des thèmes centraux du DevOps est la suppression des silos entre le développement et les opérations. De ce fait, la convergence de ces deux disciplines est essentielle. Même à l'ère du « NoOps », le besoin en opérations restera toujours présent. Il prévoit que l'objectif principal des opérations sera de garantir la qualité, notamment les performances en production. Dans les 3 à 5 prochaines années, les équipes de développement et d'opérations évolueront, combinant les compétences informatiques et opérationnelles nécessaires pour gagner en rapidité, avec un accent mis sur l'automatisation et la fiabilité.

Concentrez-vous sur le fait de récupérer du temps.

Arup Chakrabarti de PagerDuty a également exploré la notion quelque peu controversée de « NoOps », soulignant le tollé suscité par son apparition. Il constate un consensus quant à l'intention et à l'état d'esprit d'automatiser certaines tâches opérationnelles. Le NoOps a le potentiel de libérer du temps pour se concentrer sur des missions plus importantes et critiques (comme apporter de la valeur ajoutée lors de crises majeures ayant un impact sur l'activité). Arup a fait remarquer que les bons ingénieurs d'exploitation et administrateurs système s'attachent à automatiser les tâches manuelles et que les meilleurs adoptent une approche leur permettant de gagner du temps.

Nous avons abordé de nombreux aspects du DevOps lors de cette discussion approfondie. Nos quatre experts nous ont apporté des éclairages pertinents, et nous en partagerons d'autres prochainement. Chez PagerDuty, nous sommes impatients de voir comment le DevOps évoluera d'ici la fin de l'année, et nous reviendrons certainement avec d'autres réflexions à mesure que nous verrons comment les prédictions se sont réalisées cette année, en 2018 et au-delà. En attendant, vos commentaires sont les bienvenus, et nous vous encourageons à suivre notre Prévisions et tendances en matière de DevOps webinaire !