Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Automatisation du lancement des applications et automatisation de l’infrastruct

Automatisation du lancement des applications et automatisation de l’infrastructure Présentation de la proposition de valeur de ces deux options Par Julian Fish, Director of Product Management, Serena Software (désormais membre de Micro Focus) Livre blanc Table des matières page Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Pourquoi opter pour l’automatisation ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Bref historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Le progrès n’est pas forcément une gageure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Qu’est-ce que l’automatisation de l’infrastructure ? . . . . . . . . . . . . . . . . . . . . . . . 4 Qu’est-ce que l’automatisation du lancement des applications ? . . . . . . . . . . . . . 5 Caractéristiques communes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Automatisation de l’infrastructure via Deployment Automation ou Puppet . . . . 8 Automatisation du lancement des applications via Deployment Automation ou Puppet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Valeur ajoutée des pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Déploiements basés sur des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 La question de l’extensibilité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Le meilleur des deux mondes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1 www.microfocus.com Résumé Les entreprises ayant entamé leur transformation DevOps, ou recherchant simplement le moyen d’automatiser l’installation et la configuration de leurs environnements, sont souvent dubitatives quant à la valeur de l’automatisation du lancement des applications par rapport aux outils d’automatisation de l’infrastructure. Il existe une pléthore d’outils, dont certains remplissent, semble-t-il, les mêmes fonctions. Le présent document aborde deux leaders du marché : la solution Micro Focus Deployment Automation1, dédiée à l’automatisation du lancement des applications, et le logiciel Puppet2, qui gère l’automatisation de l’infrastructure. Il détaille également les propositions de valeur de chaque produit, ainsi que le domaine principal qu’il couvre et les avantages qu’il peut proposer au sein d’une chaîne d’outils DevOps intégrée. Pourquoi opter pour l’automatisation ? De nombreuses entreprises s’efforcent de simplifier le déploiement de leurs applications, tout en garantissant la stabilité des opérations, dans le respect des SLA, et en vérifiant que les objectifs en matière de réactivité des applications sont atteints. Pour assurer sa survie, une société doit être capable de réagir plus efficacement aux aléas de l’activité et de se « développer rapidement et sans heurt ». Pour atteindre ses objectifs en matière de concurrence, elle a de plus en plus besoin d’automatiser la pile d’applications complète. Malheureusement, la notion de « pile complète » tend à prendre un sens différent selon le secteur d’activité du service. Ainsi, le service des opérations considère souvent la « pile complète » comme l’infrastructure requise pour héberger les applications hôtes et les systèmes sous-jacents, l’application jouant le rôle de petit composant de la pile. Le service de développement, quant à lui, voit en elle l’ensemble des niveaux de l’application, qui fonctionnent de concert, harmonieusement, sans s’intéresser particulièrement à l’infrastructure sous-jacente. Du point de vue DevOps, tout particulièrement, il s’avère que l’ensemble des composantes doivent collaborer étroitement pour garantir une prise en charge efficace des ressources désormais considérées comme critiques pour l’entreprise. Depuis une dizaine d’années, le service informatique n’est plus perçu comme un facteur de différenciation commerciale. Ainsi, le fait de maintenir les systèmes métiers en conditions opérationnelles n’est plus une valeur ajoutée : il s’agit désormais d’une obligation. Pour les entreprises, l’application est reine. La différenciation commerciale et la valeur métier dérivent des modifications apportées aux applications. Il est impératif de mettre en oeuvre autant de changements métiers que possible et ce, très rapidement, tout en maintenant des niveaux élevés en termes de qualité, de stabilité et de fonctionnalités. Or, les processus de déploiement manuels des applications sont incapables de répondre à ces exigences cruciales. L’automatisation est donc une étape obligatoire, et non facultative. Le présent document aborde deux leaders du marché : la solution Micro Focus Deployment Automation, dédiée à l’automatisation du lancement des applications, et le logiciel Puppet, qui gère l’automatisation de l’infrastructure. Il détaille également les propositions de valeur de chaque produit, ainsi que le domaine principal qu’il couvre et les avantages qu’il peut proposer au sein d’une chaîne d’outils DevOps intégrée. __________ 1 Deployment Automation (SDA) est un outil leader du marché conçu pour assurer l’automatisation des applications. Il peut s’intégrer dans les outils de provisioning de l’infrastructure et les gérer. www.serena.com/sda 2 Puppet est un outil leader du marché conçu pour assurer l’automatisation de l’infrastructure. Il peut également gérer l’automatisation du lancement des applications, même si cela nécessite un codage et des manipulations supplémentaires. https://puppetlabs.com/ 2 Livre blanc Automatisation du lancement des applications et automatisation de l'infrastructure Bref historique Au cours des 15 dernières années, l’évolution dans le secteur de l’industrie du logiciel a connu un net essor, qui a conduit à ce que l’analyste Glenn O’Donnell de Forrester qualifie d’« industrialisation de l’informatique »3. Cette évolution a d’abord été favorisée par une réduction des dépenses informatiques au début des années 2000, puis par la récession du secteur point-com et le développement massif d’Internet, en parallèle avec une approche métier reposant sur le maintien des activités en continu. Ainsi, elle a fortement affecté l’informatique en entreprise. Les entreprises qui, quinze ans auparavant, ne voyaient pas la nécessité de créer un site Web d’entreprise, voire d’assurer aux clients un accès 24 heures sur 24 à ce dernier, ont dû repenser entièrement leur stratégie. La réduction des dépenses informatiques a poussé les services à faire toujours plus avec moins de moyens, en réduisant les effectifs et en demandant plus d’efforts à l’infrastructure informatique de l’entreprise. L’adoption de fonctionnalités permettant un accès en tout lieu à Internet nécessite un niveau élevé d’efficacité opérationnelle, mais aussi une réactivité et une disponibilité des systèmes encore inégalées. Du fait de la complexité de nombreuses applications d’entreprise, il n’est plus aussi simple d’assurer une diffusion efficace et reproductible des changements métiers. Le service informatique ne peut pas se contenter d’accélérer la diffusion de ces changements, car l’entreprise court le risque d’exposer les applications à des tiers susceptibles de rechercher des faiblesses ou un accès non autorisé à des systèmes back-office stratégiques. Il est désormais nécessaire de déployer les applications rapidement, tout en assurant un niveau de qualité et de sécurité élevé et en proposant la nouvelle fonctionnalité phare attendue. Il n’est plus possible de garantir la fiabilité, la traçabilité et la reproductibilité des opérations au moyen de processus manuels. En effet, une fourniture manuelle des applications risque de compromettre la réussite de l’entreprise face à la concurrence. Le progrès n’est pas forcément une gageure Par tradition, les équipes de développement sont ouvertes au changement, par exemple à la transition depuis les langages de programmation « hérités » comme COBOL vers d’autres langages plus récents, tels que C et Java et .Net. Elles ont modifié leurs uploads/Management/ application-release-automation-vs-infrastructure-automation-wp-fr.pdf