Le pouvoir du proxy : Combler le fossé entre le développement et la production

Le monde du développeur d’applications et celui de l’architecte réseau ne pourraient pas être plus différents, sauf peut-être dans la manière dont chacun perçoit le domaine de l’autre.

Une perspective réseau typique d’un déploiement d’application ressemble souvent à ceci :

De l’autre côté du « mur », la perspective du développeur sur le même déploiement d’application ressemble souvent à ceci :

Les deux sont sans doute précis dans leurs domaines respectifs, mais très indifférents à l’architecture réelle de l’autre. Ceci illustre pourquoi de nombreux problèmes surviennent lorsque les applications passent en production. Et ils se lèvent. Les recherches indiquent qu'en 2013, « 90 % des développeurs ont déclaré qu'ils passaient leurs week-ends, leurs jours fériés et leurs vacances à résoudre les urgences liées aux applications en phase de production. [1]”. Si bon nombre d’entre eux sont certainement liés à des défauts et des erreurs logicielles, beaucoup d’autres sont sans aucun doute causés par les nombreuses différences entre les environnements. La production n’est pas le développement, et vice versa.

Les applications d’aujourd’hui tirent parti d’une variété de services qui existent dans les environnements de production, mais rarement dans les environnements de développement ou de test : équilibreurs de charge pour l’évolutivité, caches pour améliorer les performances et pare-feu d’applications Web pour la sécurité. Ces services non seulement touchent chaque demande et réponse lorsqu'elles traversent le réseau entre l'utilisateur et l'application (ou l'application et l'API, si vous préférez), mais dans certains cas, ils modifient les demandes et/ou les réponses. L’adresse IP de l’utilisateur en est un bon exemple. Cette valeur se trouve dans les en-têtes HTTP de chaque requête, mais lorsqu'elle passe par un proxy d'équilibrage de charge, elle devient l'adresse IP du proxy , pas du client.

Pour le développeur peu méfiant, cela peut entraîner des « pannes » d’applications et des heures de dépannage en plus du temps nécessaire à la modification de l’application. Ces types de problèmes découlant de différences d’environnement sont sans doute la raison pour laquelle 28 % des développeurs ont répondu à une enquête [2] a déclaré à la mi-2015 que « plus de 50 % des problèmes de production auraient pu être détectés et résolus avec le bon environnement de test ». Et plus de la moitié (52 %) ont déclaré qu’« entre 25 % et 50 % des problèmes de production auraient été résolus ».

De nombreux problèmes survenant en production sont directement imputables aux différences dans l’application, et en particulier celles développées à l’aide de méthodologies agiles. Les méthodes agiles peuvent augmenter la probabilité que ce type de conflits survienne en production en raison de la fréquence à laquelle le code change.

De plus en plus de ces défis, mais pas tous, sont résolus en utilisant un proxy programmable, car cela élimine le besoin de modifier le code déjà en production et de retarder davantage la livraison de l'application sur le marché. Le problème « d'adresse IP » mentionné ci-dessus est généralement résolu en demandant au proxy d'insérer un nouvel en-tête HTTP contenant l'adresse IP réelle afin que les développeurs aient toujours accès à ces informations et que les proxys d'équilibrage de charge de couche 7 soient capables de router les demandes d'application et d'API en fonction de diverses données, notamment le contrôle de version et les signatures d'API.

Il est intéressant de noter que le composant qui est souvent mentionné dans les diagrammes d’ingénierie logicielle et réseau est l’équilibreur de charge. Même si ce proxy est traditionnellement déployé et géré par l’équipe réseau, il est suffisamment essentiel aux architectures d’application pour qu’il soit presque toujours inclus dans l’application. De même, les développeurs reconnaissent aujourd’hui l’importance de l’équilibrage de charge pour la mise à l’échelle des applications et l’incluent généralement dans leurs diagrammes.

Cela reflète également les cas croissants dans lesquels les développeurs et les opérateurs ont assumé la responsabilité de l'évolutivité et ont ainsi pris le contrôle de l'équilibrage de charge de leurs applications.  C’est une bonne chose, car cela signifie que les développeurs et les opérateurs peuvent (et, espérons-le, incluent) l’équilibrage de charge (et tous ses avantages de couche 7) dans le pipeline CI/CD, en particulier pendant les tests, pour garantir que tout problème potentiel puisse être détecté rapidement et résolu avant de passer à la production. Le déplacement de l'équilibrage de charge vers la gauche dans le pipeline CI/CD permet également une approche plus holistique de la livraison continue dans laquelle l'ensemble du package d'application (architecture) est géré sous forme de code et peut être mis à jour simultanément. Cela permet à l’infrastructure réseau (car c’est là que l’équilibrage de charge se situe traditionnellement lorsqu’il est décrit) de prendre en charge une architecture immuable dans laquelle les applications (ou les microservices si vous empruntez cette voie) sont entièrement redéployées avec de nouvelles configurations plutôt que simplement mises à jour, évitant ainsi l’entropie logicielle naturelle qui peut introduire des défis et une dette technique.

Le proxy est à bien des égards le pont qui relie le « réseau » à l’« application » par-dessus le fossé figuratif (plutôt un mur, pour être honnête) qui sépare les ingénieurs et architectes logiciels et réseau. C’est l’une des lacunes que DevOps doit combler si les organisations veulent pouvoir évoluer pour relever les défis des architectures modernes.

[1] http://solutions-review.com/mobile-application-development/5000-developer-survey-mobile-app-development-insights-revealed/

[2] https://www.ravellosystems.com/blog/software-is-not-quite-ready-to-eat-the-world-state-of-devtest-infrastructure-survey-results/