Les conséquences de la crise actuelle du coronavirus
Comment parler de 2020 sans parler de la crise du coronavirus qui frappe actuellement le monde entier ? En effet cette crise impacte toutes les organisations, quelque soit leur taille, des plus petites aux plus importantes. Impossible de ne pas y voir des conséquences sur le DevOps en 2020, telles que le télétravail de près de 8 millions de personnes (en France) ou encore un fort impact sur l’activité :
>un arrêt brutal pour une majorité et une sorte de mise en veille des systèmes d’information en espérant repartir vite à la levée du confinement
> une augmentation de la demande pour une minorité (par exemple : les services de vidéos à la demande ou de la grande distribution) et des systèmes d’information plus sollicités que jamais
4 priorités DevOps pour 2020
Si de plus en plus d’organisations étaient déjà bien lancées dans leur adoption du DevOps, le contexte actuel les conduit à revoir en profondeur leurs priorités.
1) Usage du Cloud Public
Le Cloud Public a démontré en cette période difficile tous ses avantages. En apportant de la souplesse et de l’agilité aux systèmes d’information, le Cloud public offre un accès rapide et simple à des ressources à la demande quasi-illimitées. Ce qui signifie que ces ressources peuvent être allouées dynamiquement pour répondre à une forte sollicitation sur une période plus ou moins courte. Ou au contraire, elles peuvent être tout simplement stopées entrainant également l’arrêt de leur facturation.
Les systèmes fortement sollicités ont ainsi pu bénéficier rapidement de davantage de ressources. Et les organisations dont l’activité s’est réduite, ont pu stopper net tout ou partie de leurs investissements en arrêtant des projets et détruisant les ressources Cloud afin de réaliser des économies.
Le Cloud Public est ainsi un allié de premier choix face aux changements et toutes sortes d’imprévus. Notons par ailleurs que la vélocité des projets Cloud est plus de dix fois supérieure à celle des projets traditionnels. Par conséquent l’adoption du Cloud Public est sans conteste prioritaire.
2) Monitoring, Log et Incident Management
Ces dernières années, de nouvelles solutions de monitoring, de log management et plus récemment d’incident management ont vu le jour. La modularité apportée par l’approche microservices décompose les systèmes d’information en sous-systèmes moins complexes, plus maintenables et rapides à développer. Mais dans le même temps le système d’information est quant à lui plus complexe, distribué et difficile à observer. C’est ainsi que de nouveaux outils deviennent nécessaires pour comprendre ce qu’il se passe.
Les systèmes fortemant sollicités ont ainsi pu s’appuyer sur le monitoring, les logs voire même des alertes automatiques pour pallier aux éventuelles dysfonctionnements survenus avec la charge anormalement élevée. Pour les organisations dont l’activité s’est réduite, les outils de monitoring sont là encore bien utiles d’une part pour constater la baisse de fréquentation de certains sous-systèmes et envisager des redimenssionements (s’ils ne sont pas automatiques) pour faire baisser la facture. D’autre part, pour permettre à des équipes d’intervenir sur un périmètre plus large alors que les effectifs ont pu être revus à la baisse en faisant par exemple appel à du chômage partiel.
Monitoring, Log et Incident Management sont des sujets prioritaires pour réduire le temps lié à la maintenance des systèmes d’information et réaliser des économies ou se montrer réactif en cas d’incident.
3) Plateformisation du SI
Pour accélérer la réalisation de nouveaux projets toujours plus nombreux, il faut donner la capacité aux équipes projets d’avancer plus vite et avec plus d’autonomie. D’avancer plus vite en proposant l’infrastructure sous forme de plateforme en libre accès permettant le provisionnement rapide et simple de briques d’infrastructure réutilisables telles qu’une base de données, un serveur d’application, etc. Dans un contexte Cloud, il s’agira de lister les services autorisés et d’en cadrer l’utilisation (par exemple activer par défaut les options de sécurité en cohérence avec la politique de sécurité de l’organisation). Ainsi les équipes projets pourront acquérir quelques compétences en infrastructure leur donnant d’avantage d’indépendance et d’autonomie. En supprimant d’une part des dépendances avec d’autres équipes ou travaux et en ne restant plus bloquées d’autres parts à attendre la mise à disposition de différentes ressources systèmes, la productivité de l’ensemble des équipes est améliorée et les réalisations sont accélérées.
Après l’APIsation dont l’un des nombreux objectifs consistent à rendre disponibles des APIs sous forme de catalogue pour favoriser la réutilisation et accélérer les réalisations, la plateformisation de l’infrastructure suit la même logique en tentant de proposer un catalogue des briques d’infrastructure réutilisables, qui si ce n’est pas déjà le cas, deviendra une nouvelle priorité à considérer pour les grandes organisations.
4) Infrastructure as Code et GitOps
Les avantages de l’infrastructure as code face à une gestion d’infrastructure traditionnelle sont déjà bien connus : la réduction des coûts et du risque, la rapidité d’exécution et la collaboration au sein de l’équipes.
GitOps propose d’utiliser Git pour stocker et versionner ce code d’infrastructure en construisant une chaîne de déploiement automatique pour maintenir aligné le code d’infrastructure dans Git avec des environnements cibles.
Ainsi l’historique des actions (qui, quoi et quand) est inscrit dans l’historique des commits Git et peut même faire l’objet de revue de code avant déploiement.
En proposant un modèle déclaratif où l’on décrit non pas les étapes pour construire l’infrastructure, mais plutôt le résultat final (peu importe l’ordre) et en implémentant l’idempotence afin de garantir ce résultat final (peu importe l’état initial du système – construction d’un nouvel environnement ou mise à jour d’un environnement existant), les outils de déploiement continu simplifient les opérations. Par ailleurs, le code sous Git constitue une documentation précise et exacte de l’infrastructure, qui contribue là encore à la réutilisation entre projets. C’est aussi l’occasion d’alléger peut-être un processus de « change management » devenu trop lourd pour réduire un risque de défaillance humaine possible, qui n’a plus lieu d’être.
Que vous ayez déjà lancé ou non la construction d’une plateforme offrant des composants d’infrastructure, l’infrastructure as code est incontournable pour sécuriser et simplifier des processus de « change management » devenus trop lourds et ainsi accélérer les déploiements.