The Doppler Quarterly (FRANÇAIS) Été 2016 | Page 72

Six raisons pour lesquelles votre stratégie cloud doit inclure un plan de changement

Joey Jablonski
Vous avez vu la même histoire se répéter au cours des années . Une nouvelle technologie disruptive apparaît et les entreprises plongent la tête la première dans l ' apprentissage et dans son implémentation . Cependant , très peu d ' attention est portée sur les impacts humains .
En 2016 , tout recommence . Les entreprises adoptent le cloud computing en plus de DevOps , de l ' infrastructure en tant que code et même possiblement des microservices et conteneurs , mais nous constatons encore des problèmes humains et de processus qui ralentissent l ' adoption à grande échelle . Quand apprendrons-nous de nos erreurs ?
Pourquoi est-ce si important de se focaliser sur un changement organisationnel lors de l ' adoption du cloud computing au sein d ' une grande organisation ? Découvrons quelques exemples de la manière dont le cloud change notre manière d ' opérer .
Rapidité de livraison
Pour répondre aux exigences commerciales d ' obtention de nouveaux services à commercialiser plus rapidement , de nombreuses entreprises ont choisi le mouvement DevOps . Les entreprises qui réussissent à passer à un modèle de livraison agile sont capables de déployer de plus petits ensembles de changements vers la production de manière plus fréquente . Traditionnellement , les entreprises ont adopté des cycles de publication trimestriels ou semestriels . Ces modèles de déploiement classiques comportaient de grandes fenêtres de test , plusieurs portes de révision manuelle et des tonnes de sessions de planification .
Ce changement d ' état d ' esprit , à savoir le passage du déploiement de grandes applications monolithiques quelques fois par an uniquement , au déploiement de petits services hebdomadaires ou bihebdomadaires , modifie considérablement le modèle d ' exploitation requis pour gérer et exécuter les applications . Les fenêtres de test sont considérablement comprimées , d ' où l ' augmentation du nombre de tests d ' automatisation . Il n ' y a plus de temps suffisant pour plusieurs portes de révision manuelle pour vérifier l ' architecture , la sécurité , la qualité , etc .
Les déploiements rapides exigent de nouveaux niveaux d ' automatisation , de provisionnement en self-service , de surveillance continue de la sécurité en production , de la surveillance proactive et de nombreuses autres pratiques quotidiennes modernes . Les transferts entre silos doivent donner lieu à une approche plus collaborative de création et de déploiement des logiciels .
Nombreuses sont les entreprises qui pensent que l ' implémentation d ' une intégration en continu ( CI ) et d ' une livraison en continu ( CD ) résoudra tous leurs problèmes , et se focalisent uniquement sur leur silo de développement . Bien que l ’ approche CI / CD puisse réduire considérablement le temps de création d ' un logiciel , elle ne peut pas traiter tout le processus qui se produit avant et après la procédure de création , et qui est généralement chargé de déchets . Le DevOps concerne le cycle de vie de développement du logiciel ( SDLC ), de bout en bout , et pas seulement les CI / CD . Les entreprises doivent compter sur les changements des processus et du personnel requis pour optimiser le flux SDLC complet , de gauche à droite .
Fourniture de services vs . Fourniture de produits
Avec le passage des entreprises de la fourniture de grands monolithes à la fourniture de services , un changement d ' état d ' esprit majeur est nécessaire au sein de l ' entreprise . Avec un produit , une fois qu ' il est
70 | THE DOPPLER | ÉTÉ 2016