DevOps est-il à son apogée ?

Afin d'être vraiment Agile, les organisations doivent casser la norme qui consiste à parachuter du code aux équipes d'exploitation pour qu'elles en assurent le maintien.

Le mouvement DevOps doit encore gagner en maturité tout comme la méthodologie Agile qui continue à évoluer et à progresser dans de nombreuses organisations. Afin d'être vraiment Agile, les organisations doivent casser la norme qui consiste à parachuter du code aux équipes d'exploitation pour qu'elles en assurent le maintien. Elles doivent instaurer des processus collaboratifs qui permettent des itérations et des changements rapides sans devoir constamment éteindre des incendies.

Certes, les outils d'automatisation abondent sur le marché pour les équipes ayant déjà de bonnes pratiques DevOps, mais il faut encore briser les silos au sein des entreprises. Néanmoins, il faut noter une meilleure collaboration non seulement entre les équipes de développement et d'exploitation, mais aussi entre ces équipes et les principales unités opérationnelles. Cerise sur le gâteau, l'adoption rapide du cloud ouvre de nouvelles opportunités DevOps avec notamment à la popularisation de la fonction d'ingénieur SRE (Site Reliability Engineer).

Lorsque le développement et les opérations sont totalement indépendantes, il peut être particulièrement difficile d’instaurer des processus alignés sur ceux de DevOps. Les équipes doivent avoir la volonté de travailler en étroite collaboration et de s'aligner sur des objectifs organisationnels similaires propices à la collaboration, tels que se soucier conjointement de la disponibilité des systèmes. Des outils disparates nécessitent également la mise en œuvre de processus DevOps afin de favoriser un travail collaboratif. Cela est particulièrement vrai si les équipes examinent divers paramètres et métriques dans différents outils. Elles ne seront pas sur la même longueur d'onde tant qu'elles ne seront pas capables de parler le même langage. 

DevOps doit aussi être abordé avec soin et attention. En faire trop, trop vite, peut entraîner des problématiques majeures. L'adoption de nouveaux processus, outils et architectures tout en essayant d'inculquer une nouvelle culture prend du temps. La direction doit en tenir compte notamment lorsqu’il s’agit d’applications traditionnelles et d’équipes bien établies. Un plan de déploiement doit être défini avant de tenter une transformation DevOps complète, laissant ainsi le temps aux ingénieurs d'acquérir les nouvelles compétences nécessaires à cette mutation. 

L’aide cruciale du cloud monitoring 

Le cloud monitoring apporte une véritable valeur ajoutée, lorsque les équipes de développement dans le cloud adoptent DevOps et souhaitent travailler de manière plus collaborative. Il fournit une vision globale et continue d’une infrastructure Agile+DevOps dynamique composée de systèmes modernes fortement distribués et éphémères. Aujourd’hui, les solutions de monitoring doivent être évolutives pour offrir une vue centralisée sur une prolifération d'outils exploités par les équipes Dev et Ops. Elles facilitent le processus de publication de code en permettant la corrélation entre les événements, tel que l’envoi du code vers la production, et les indicateurs, tels que santé de l'infrastructure et erreurs de code. Un monitoring centralisé au travers d’un langage commun aide à briser naturellement les silos et encourage la collaboration entre les groupes de développeurs, les équipes d'exploitation et les analystes métiers. Cela s’opère en corrélant paramètres et métriques pour une vision des métriques individuelles dans le contexte global d’un système. En montrant ces métriques dans le contexte des uns et des autres et en mettant l'accent sur l'importance de la santé du système dans son ensemble, le cloud monitoring permet le travail collaboratif souhaité.  

Trois principales catégories de données doivent être capturées pour une équipe DevOps efficace. Les indicateurs de travail correspondent aux points de données et de mesures se rapportant à l'utilité des systèmes en termes de débit et le rendement par rapport aux objectifs. Les indicateurs de ressources renseignent sur l'état actuel des systèmes en termes d'utilisation
des processeurs par exemple. Ils sont essentiels pour diagnostiquer les problèmes qui sont potentiellement découverts grâce aux indicateurs de travail. Les événements rassemblent des faits distincts au sein de l’environnement. Par exemple, une équipe DevOps veut capturer des données à chaque fois qu'un nouveau code est poussé, qu'une alerte se déclenche ou que de nouvelles ressources sont ajoutées à un système. Ces données peuvent fournir un contexte aux autres types de métriques, souvent utiles dans l'analyse des causes profondes. Par exemple, un événement de poussée de code peut avoir réduit le débit. Plus les données sont proches du temps réel, plus les équipes peuvent agir rapidement pour reconnaître, diagnostiquer et réparer les problèmes qui diminuent la production des systèmes. Elles peuvent également être compilées par les équipes pour mesurer les indicateurs du succès de DevOps, tels que fréquence de déploiement et taux d'échec en fonction des événements, temps moyen de détection (MTTD) et temps moyen de réparation (MTTR) basé sur les paramètres de travail, disponibilité du système basée sur les métriques de ressources. 

Rivalité entre philosophies DevOps et Agile ? 

DevOps et Agile doivent être complémentaires. Agile définit une nouvelle façon de gérer le Système de Cycle de Vie (SDLC) et de nouvelles attributions pour la gestion de projet. DevOps se rapporte à la culture collaborative entourant le déploiement, la maintenance et l'automatisation des applications. Il ne devrait donc y avoir aucune rivalité entre les deux, DevOps étant une méthode qui permet d'atteindre les objectifs d'Agile. Les équipes Agile s'efforcent de publier du code fréquemment, ce qui crée un besoin de méthodes de travail plus rapides et plus efficaces avec un processus d’accélération de publication de code. DevOps fournit la solution à cette problématique grâce à la communication, la collaboration et l'intégration des équipes.   

À moyen terme, je pense que l'accent sera mis sur le passage à des architectures conteneurisées, basées sur des micro-services, cloud agnostiques et conçues pour une orchestration Kubernetes. Beaucoup d'organisations le font déjà, d’autres commencent à le faire, mais cherchent encore le juste équilibre pour un nombre optimal de micro-services. Le développement de cette tendance va mener à un besoin croissant d’un monitoring plus complet et plus granulaire. Dans leur quête d’agnosticisme, les équipes d'ingénieurs passeront outre les outils de monitoring natifs des fournisseurs pour bénéficier de vues de plus en plus transparentes sur la santé de leurs systèmes. Je vois aussi les équipes analytiques travailler plus en collaboration avec les équipes de développement, afin de prendre des décisions fondées sur des données et relier les métriques de monitoring à celles de la réussite de l'entreprise.