Pourquoi l'infrastructure est importante pour les développeurs utilisant des conteneurs
Aujourd’hui, l’une des questions les plus fréquemment entendues dans les couloirs d’un fournisseur d’infrastructure est de savoir comment expliquer la valeur de cette infrastructure à la communauté des développeurs. Le problème est que la plupart des avantages des infrastructures sont obtenus après leur mise en production. Aucun d’entre eux n’apporte réellement de valeur directement au développeur, du moins pas de manière significative qui ait un impact sur sa routine quotidienne.
Les avantages supplémentaires en termes de développement sont quelque chose dont les développeurs sont certainement conscients. Dans notre rapport sur l’état de la distribution des applications de 2018, un petit pourcentage de développeurs étaient représentés. Mais ce pourcentage en disait long sur les services applicatifs qu’ils souhaitaient déployer. Certains de ces services d’application (équilibrage de charge, mise en cache et accélération) sont aussi souvent déployés dans le cadre de l’application elle-même qu’en tant qu’infrastructure. Les optimisations TCP et WAF sont presque toujours des services d'infrastructure, déployés en amont (dans le chemin de données) devant les applications (qu'elles soient monolithiques ou microservices).
Il y a de la valeur dans tous ces services applicatifs. Réduction des risques, amélioration des performances, évolutivité. Mais il s’agit là d’avantages applicatifs et commerciaux ; ils profitent aux développeurs après la livraison de l’application à la production. Il est difficile de trouver – et encore moins d’articuler – les avantages de l’infrastructure avant sa livraison, c’est-à-dire dans le cadre du cycle de vie du développement.
Mais à mesure que nous continuons à adopter les conteneurs et les microservices, la valeur de l’infrastructure avant et après la livraison devient plus évidente.
Comme la plupart des technologies émergentes, les premiers jours d’une nouvelle architecture d’application s’accompagnent de très peu d’infrastructures. Il peut être surprenant pour les développeurs d’apprendre que l’architecture des applications façonne de manière significative l’infrastructure des services d’application. Le passage aux applications Web à trois niveaux a apporté l’évolutivité (équilibrage de charge). L’adoption du Web 2.0 avec sa couche de présentation réactive a donné naissance à une infrastructure d’accélération frontale. Avec l'avènement du mobile et la numérisation croissante de chaque secteur, nous avons vu les infrastructures réagir avec des services de sécurité tels que WAF, DDoS et la défense contre les robots.
Ce que nous voyons se produire actuellement, c’est que les développeurs codifient les capacités des services d’infrastructure dans leurs applications. Les développeurs mettent dans le code ce qui était traditionnellement la responsabilité des services en amont. Réessayez à partir des équilibreurs de charge. mTLS à partir des plateformes ou des proxys. Contrôle d'accès pour restreindre la communication aux clients légitimes.
Il s’agit de responsabilités d’infrastructure qui, en raison de la nature naissante des frameworks de conteneurs et des taux d’adoption rapides, ont été assumées par les développeurs.
Mais comme cela a toujours été le cas, les choses changent. Tout comme les architectures d’applications précédentes ont généré des réponses dans l’infrastructure réseau, il en va de même pour les conteneurs et les microservices. Mais cette fois, les changements ne se présentent pas sous la forme d’une nouvelle boîte. Ce qui se passe actuellement est le mouvement visant à intégrer les services d’application dont les développeurs ont besoin dans l’environnement de conteneur. C'est là qu'intervient le service mesh, qui offre une valeur réelle et quantifiable directement aux développeurs.
Comme l'explique Andrew Jenkins, architecte principal chez Aspen Mesh dans une interview avec Linux.com :
« C’est remarquable à quel point il est facile de commencer à créer un service Web aujourd’hui. Vous pouvez insérer le code dans un tweet. Ce n’est cependant pas un véritable service Web. Pour la rendre résiliente et évolutive, vous devez ajouter certains éléments au plan de données de l'application. Elle doit effectuer le protocole TLS, réessayer les échecs, accepter uniquement les requêtes de ce service mais pas de celui-là, vérifier l'authentification de l'utilisateur, etc. Un service mesh peut vous aider à obtenir cette fonctionnalité de plan de données sans avoir à ajouter de code à l'application. »
La valeur avant livraison réside dans la réduction de la portée et l’élimination du code répétitif mais nécessaire pour gérer la sécurité de base et l’évolutivité dans un environnement de conteneur. Un service mesh présente une grande variété de fonctionnalités intéressantes, mais ses avantages restent largement opérationnels : observabilité, responsabilité, évolutivité. La valeur la plus significative pour un développeur réside dans l’élimination du code (et donc dans la réduction de la dette technique et architecturale).
L’utilisation d’un service mesh pour mettre à l’échelle, sécuriser et observer les applications déployées dans des environnements de conteneurs allège la charge d’écriture de code qui doit être gérée par l’infrastructure – mais qui, jusqu’à récemment, était déléguée aux développeurs. Un service mesh est un moyen de décharger les développeurs de leurs responsabilités et de leur redonner un temps précieux qu'ils pourraient utiliser pour développer des services et des applications qui, à leur tour, apportent de la valeur à l'entreprise.