« Désolé, la prochaine fenêtre de déploiement des applications est dans trois mois » : qui n’a jamais pesté de devoir attendre son tour pour que soit corrigée ou améliorée une application métier pourtant indispensable ? 

Curieusement, cela était très vrai avant mars 2020. Mais pendant la crise sanitaire de nombreuses entreprises se sont soudain découvert la capacité d’aller (beaucoup) plus vite. Comme l’a récemment expliqué un client : « Avant la crise, il nous fallait de six mois à un an pour déployer une nouvelle application, et tout d’un coup, cela ne prenait plus que six semaines. C’est ça, l’effet d’une crise existentielle ! ». 

La crise sanitaire a changé fondamentalement les règles du jeu. Tous les processus formels et les jeux de politique interne ont été écartés, et on a simplement demandé aux développeurs « d’y aller ». Alors ces derniers « y sont allés » : ils ont codé, créé des prototypes et mis le code en production en une fraction du temps habituel. 

Le problème ? C’est que les processus habituels qui encadrent le fonctionnement quotidien de l’entreprise ne sont pas inutiles, ou bien ils auraient été supprimés depuis longtemps (pour la politique, c’est une autre histoire !). Et ce qui peut être réalisé sous la pression d’une crise existentielle ne peut être maintenu en temps normal. 

Car quand on dit aux développeurs « d’y aller », en réalité, cela revient à les laisser courir avec des ciseaux, selon l’adage populaire. Bien sûr, on sait qu’il ne faut pas le faire, mais en situation d’urgence, a-t-on vraiment le choix ? 

Mais l’on sait aussi qu’à généraliser cette pratique, il va forcément arriver un moment où le nouveau code d’un développeur (les ciseaux) pourrait casser quelque chose, ce qui pourrait entraîner par effet domino la perte d’applications critiques et avoir un impact sur la réputation de l’entreprise, ses revenus, voire compromettre des données des clients. 

Ne pas confondre vitesse et précipitation

Cela dit, maintenant que de nombreuses entreprises ont goûté à l’ivresse de la vitesse, elles n’ont pas non plus envie de revenir aux limitations du modèle précédent.

Alors, peut-on concilier le meilleur des deux mondes ?

Un début de réponse peut se trouver dans l’infrastructure : cela fonctionne bien pour les entreprises dites « Cloud natives », entièrement bâties sur des architectures modernes hébergées dans le Cloud. Elles n’ont pas de dette technologique et ont été conçues dès le départ pour pousser plusieurs changements d’infrastructure ou de code par jour.  

Mais pour les autres, une grande banque par exemple, il est impossible d’apporter autant de changement aussi vite. Ces entreprises interdisent à leurs développeurs de courir avec des ciseaux. Pourquoi ? Tout simplement parce que leurs infrastructures plus anciennes et technologiquement moins agiles leur imposent de s’appuyer sur des équipes de production dont le travail est diamétralement opposé à la volonté de vitesse des développeurs, puisqu’il consiste à améliorer la fiabilité, le temps de fonctionnement et la sécurité.

Mais la crise sanitaire est passée par là, et même ces entreprises sont résolues aujourd’hui à résoudre cette tension. Elles doivent permettre aux développeurs de travailler en toute sécurité… mais avec des ciseaux !

La solution passe par le rapprochement des équipes de développement et de production, au sein d’une approche DevOps : ce n’est pas nouveau, et tout le savoir-faire en matière d’équipe, d’outils et de technologie existe déjà depuis quelques années. Les outils d’intégration et de livraison continue (CI/CD) et d’orchestration sont arrivés à maturité. Les conteneurs, les Kubernetes et, au-delà, les architectures natives du nuage sont prêts pour la production, y compris pour de grandes entreprises.

Bref, tout est là et il s’agit donc maintenant d’une simple question de mise en œuvre de l’organisation nécessaire. Mais comme d’habitude, c’est là où réside le vrai défi !

Les micro-services à la rescousse

Le salut se trouve dans le concept de micro-services : la décomposition d’une application en petites fonctions indépendantes. Chacune est réutilisable et optimisée pour les équipes, les outils et les technologies DevOps. Avec les micro-services, si un développeur casse quelque chose, il casse un petit morceau et non l’ensemble de l’application. Celle-ci va probablement continuer à fonctionner dans son ensemble.

Bien entendu, cette évolution n’a pas besoin de se faire du jour au lendemain : les entreprises déploient généralement ces environnements de micro-services en parallèle de leurs applications existantes, créant ainsi progressivement une architecture hybride. 

Un tel découplage de l’architecture permet aussi aux développeurs de mettre en libre-service les capacités dont ils ont besoin pour tester et déployer de nouvelles fonctionnalités dans des configurations différentes et en les interchangeant eux-mêmes.

Ils peuvent ainsi effectuer des tests (de type canari ou A/B testing) sans jamais attendre l’autorisation de l’équipe d’infrastructure, ouvrir un ticket informatique ou attendre une fenêtre de mise en production. 

La sécurité, nouveau goulot d’étranglement ?

Problème résolu ? Pas tout à fait ! Car la technologie ne résout que la moitié du problème. Il reste le défi de l’organisation. Pour de nombreuses entreprises dont les flux de travail sont complexes, la rapidité avec laquelle les développeurs peuvent agir importe en définitive peu : il faudra toujours attendre que la sécurité vérifie le code ou modifie une règle de pare-feu. Il n’est pas rare que 50 équipes distinctes, chacune travaillant sur son propre micro-service, doivent attendre après la sécurité, qui devient dès lors une ressource partagée et, malheureusement, aussi le nouveau goulot d’étranglement.

Mais au moins, ce n’est plus la faute des équipes réseau !

Alors certes, rapprocher le développement et l’infrastructure résout le problème de l’intégration logiciel/réseau. Mais si ces couches doivent attendre leur tour auprès d’une troisième (la sécurité), le problème a simplement été déplacé. La moitié de l’équation peut aller vite, mais l’autre moitié ne le peut toujours pas. 

On pourrait alors presque parler de « latence humaine ». En tant qu’ingénieurs, nous aimons mesurer la latence des applications. Nous pouvons faire passer une application de cent à dix millisecondes et nous féliciter de notre ingéniosité. Mais si l’équipe de sécurité prend 60 jours pour approuver le code ou mettre en œuvre de nouvelles politiques de filtrage, cela ajoute finalement 5 milliards de millisecondes de « latence humaine » ! C’était bien la peine de gagner 90 millisecondes sur la partie technologique…

Pour résoudre ce problème de latence humaine, il faut donc trouver un moyen de fournir la visibilité, l’orchestration et l’automatisation qui supprimera les frictions entre les équipes de développement, d’opérations, d’infrastructure et de sécurité. Comme l’ont fait, justement, les entreprises natives du cloud.

Une intégration horizontale des services

Auparavant, une solution populaire pour cela consistait à s’appuyer sur une plate-forme intégrée qui s’occupait de tout. C’est l’approche adoptée par les fournisseurs de « platform-as-a-service » (PaaS) et « d’infrastructure-as-a-service » (IaaS). L’inconvénient est que cela oblige à coupler les services applicatifs à l’infrastructure sous-jacente. Il s’agit d’une intégration verticale où l’application, les services et l’infrastructure sont étroitement liés.

Alors, certes : la simplicité de l’approche tout-en-un permet d’aller vite au début des projets, mais elle peut entraver par la suite la capacité d’adaptation. En cas de changement majeur comme une acquisition, par exemple, il sera difficile de fusionner rapidement les systèmes, de migrer vers un nouveau cloud ou de rapatrier l’application sur site.

À l’opposé de ce modèle, une intégration horizontale, qui coupe au travers des silos, offre une visibilité sur les flux de travail et les API à toutes les étapes du cycle de vie des applications. Cela créée en définitive une sorte de relais où chaque équipe court certes avec des ciseaux, mais de manière isolée et contrôlée dans son propre environnement, ce qui ne fera pas tomber l’ensemble de l’édifice à la première erreur.

C’est pourquoi les entreprises qui souhaitent rivaliser en agilité avec les concurrents « Cloud native » devraient envisager de créer cette couche d’abstraction vitale qui automatise la livraison et la configuration de la sécurité des applications de silo en silo, d’équipe en équipe, et qui permet à chacun de faire son travail rapidement, sans contrainte ni dépendance forte aux autres équipes et en toute sécurité. Une sorte de course avec des ciseaux… à bouts ronds !