La complexité d'héberger une API, simplement
Il n'y a pas que Docker et k8s dans la vie
Nous sommes à une époque où de fantastiques technologies et outils existent pour notre travail du quotidien (et je ne pense pas qu'à l'IA). Des tâches simples, peuvent devenir complexes, lorsque la dette technique s'en mêle.
Dans le cadre de l'écosystème .NET, il est possible de créer facilement et rapidement des API, des applications web et des workers avec Visual Studio, VSCode et Rider. Les développeurs peuvent ainsi engager facilement, dans la mouvance CI/CD, un projet applicatif prêt à être buildé et délivré en quelques minutes. Mais objectivement, lorsque nous nous situons dans une enterprise ayant son propre SI depuis plusieurs décennies, et qui a tenté d'évoluer avec les apports technologiques au fil des ans, il n'est pas aisé d'être à jour sur ce qui se fait de mieux.
J'ai pu constater lors d'une mission récente, un cas de conscience majeur entre les équipes dev et ops, sur l'hébergement d'une API écrite via .NET 8. Ce client dispose d'une infra on-premise encore importante, mais a aussi franchi le pas de l'hébergement cloud vers Azure il y a quelques années. L'API n'étant pas soumise particulièrement à un besoin de haute disponibilité ni de haute performance, la question s'est posée de l'endroit et de la manière pour l'héberger.
Azure Kubernetes Services ou ..... IIS ?
Oui vous avez bien lu. Ce client, comme beaucoup d'autres entreprises a une équipe opérationnelle (infra/exploit) qui gérait il y a encore 10 ans une infrastructure exclusivement on-premise. Afin d'aller de l'avant, et avec la pression des équipes de conception et de développement, celui-ci a dû s'adapter avec l'arrivée des providers cloud et des nouveautés incontournables telles que Kubernetes et Docker. Le choix du tout managé, ici avec Azure, a été salvateur bien entendu.... dans un premier temps.
Le résultat désormais est le suivant, et ne peut être critiqué car souvent subit (logiquement) avec le temps qui passe : l'usage est désormais hybrid avec des technologies et services de premier plan dans le cloud (Azure, AKS, CI/CD, Blob storage, ...) mais aussi le maintient en conditions opérationnelles d'infrastructures importantes historiques, sur laquelle la société a investit (et investit toujours) et l'envie de ne pas jeter à la poubelle des années de connaissances et compétences.
Revenons-en à notre API. Doit-elle être hébergée sur AKS sachant qu'elle ne requiert que 1 des "3H" (haute dispo, haute perf, haute sécu) et que l'on utiliserait sûrement k8s comme le couteau suisse ultime pour 3 fois rien ou doit-on plutôt privilégier IIS dans l'infra on-premise, plutôt bien maîtrisé par l'équipe, mais en sachant que les perfs ne seront peut être pas au rendez-vous, que le déploiement via Azure Pipelines est très spécifique, et qu'un bundle de rétro-compatibilité est nécessaire tant cette brique Windows date ?
L'acceptation du compromis
Ce que j'adore dans l'architecture de manière générale c'est la notion de compromis (trade-offs). Elle tiens une grande place dans le magnifique ouvrage de Mark Richard et Neal Ford que je vous conseille.
Dans ce cas rencontré, les équipes opérationnelles n'ont qu'un souhait, c'est d'aller de l'avant mais ils doivent ménager encore une fois la frénésie des développeurs, et le maintient de ce qui existe déjà. En somme, l'envie d'utiliser ce qui se fait de mieux, mais l’appréhension aussi de devoir gérer et exploiter toujours plus de systèmes hétérogènes, sans avoir le temps de faire des POCs, monter en compétence, et prendre un peu de recul. Bref, le risque de s'éparpiller.
Leur souhait à moyen terme est d'avoir un "kube" dans leur infra on-premise. Les ressources hardware existent déjà mais il va falloir beaucoup de temps pour se former et la responsabilité de garantir un service stable via une brique nouvelle est grande.
Afin de répondre à la problématique initiale, à court terme, une solution plutôt simple est Kestrel. Ce n'est pas la solution ultime, mais une solution (compromis !).
Depuis l'arrivée de .NET Core en 2016, une application .NET hébergée (API, ASP.NET, Blazor, Worker), peut l'être de manière totalement autonome via Kestrel. Plus besoin de IIS. Plus besoin de rien du tout à vrai dire, quelque soit le système d'exploitation. La possibilité ici est de simplement miser sur Kestrel pour héberger l'API dans un service Linux ou Windows. Aucune dépendance de système n'est requise et la mise en place peut se faire simplement, sans surcouche.
L'envie de ce qu'il y a de mieux
C'est ce que j'adore dans mon métier, le challenge quotidien de jongler avec le besoin visé par le client (souvent ce qu'il y a de mieux), le constat de l'existent, et le compromis.
La démarche de cette entreprise est saine : vouloir aller de l'avant et ne pas stagner. Faire avec l'existant tout en voulant bénéficier de ce qui se fait de nos jour pour être à la page et gagner en productivité, performance et maintenabilité, sans pour autant adopter trop de nouvelles technologies et avoir une infra trop hétérogène. Mais la marche peut être haute. Le compromis est souvent nécessaire pour avancer par palier.
Ne pas chercher l'absolu, juste avancer.