Depuis plusieurs mois, Microsoft met en avant le concept de « Run Anywhere » au travers des annonces de Satya Nadella (Directeur général de Microsoft) et des équipes produits lors des conférences (Build, Ignite & Inspire). Derrière ce concept, on retrouve une tendance profonde de l’industrie IT (Java 1995). Les dernières évolutions technologiques et changements de paradigmes (PaaS, microservices, containers) peuvent-ils tenir cette promesse.
Dans l’écosystème Microsoft, cette promesse se matérialise par la création de nouveaux services tel qu’Azure ARC ou bien encore le tout nouveau Azure App Containers qui vont nous aider dans cette démarche d’évolution du standard des applications.
Avanade via le Technology Office France s’est forgé une conviction sur cette évolution naturelle des applications et a eu l’occasion de partager son point de vue à travers plusieurs présentations techniques, hands-on et démos animées en interne pour nos consultants. Nous vous proposons cet article en guise de synthèse et vous invitons à votre tour à vous questionner sur ces paradigmes.

Le sujet peut être abordé de différentes façons mais globalement il ressort deux approches :
- L’infrastructure cible peut être déployée n’importe où et impose le type d’application à mettre en œuvre
- L’application s’adapte aux spécificités de l’infrastructure sous-jacente

L’application est portable : Les containers

Nous ne pouvions pas adresser ce sujet sans parler des containers. L’objectif lorsque nous utilisons cette approche est de packager une solution et toutes ses dépendances dans une image n’embarquant que le nécessaire pour faire fonctionner l’application/le service de manière isolés. Grâce à ce mécanisme vous aurez à la fin une « image » permettant de déployer votre application sur n’importe quelle infrastructure, qu’elle soit locale ou chez un Cloud Provider Public ou privé tant qu’il sache gérer ce standard: les containers.

Pourquoi les containers aident à la réponse du « Run Anywhere »

Ce standard de facto, largement plébiscité et utilisé par la communauté, a imposé sa prise en compte par l’ensemble des acteurs : Cloud Providers, plateformes de virtualisation jusqu’aux devices « Edge ». L’application peut ainsi tourner de la même façon sur le poste du développeur, sur une infrastructure locale ou sur un service d’un Cloud Provider. De plus, aujourd’hui les outils DevSecOps, nous proposent de nombreuses possibilités pour automatiser la construction de conteneurs, l’analyse d’un point de vue sécurité (socle et code) ainsi que pour le déploiement final.

L’infrastructure Azure peut se déployer n’importe où : AKS & Azure ARC

Sur le cloud Azure, la solution plébiscitée de gestion de containers à grande échelle basée sur Kubernetes s’appelle AKS pour Azure Kubernetes Services. Mais Microsoft ne s’arrête pas là.
En effet, Azure Arc propose une gestion centralisée et simplifiée des ressources hybrides (cloud/on-prem) et multi-cloud (Azure/AWS/GCP/etc.), pour un développement d’applications cloud natives plus rapide et l’utilisation des services Azure cohérents en tout lieu et avec tout type d’environnement. Azure Arc permet d’organiser, de gérer et de sécuriser facilement un large éventail de ressources technologiques telles que des serveurs Windows et Linux, des bases de données SQL Server, des clusters Kubernetes et un certain nombre de services PaaS Azure telles que les data services (Azure SQL, PostegreSQL), les Azure Functions, API Gateway, Machine Learning etc.

Hybride

L’avenir est un monde hybride (multi cloud + edge) sans compromis (culture du « ET » ; cloud ET local / Azure ET AWS…).C’est sur cet enjeu que Microsoft propose une solution unique et compréhensible avec (entre autres) Azure Arc :
• Rendre disponible des services Azure sur vos infrastructures « on top of » Kubernetes
• Manager le tout directement depuis Azure « at scale »
Microsoft n’a pas oublié l’On-Premise et fournit grâce à la famille Azure Stack (MDC, Hub, HCI, Edge) une palette d’options pour faire tourner vos applications containerisées sur des machines allant d’appareils rigidifiés jusqu’au datacenter mobile le tout géré directement sur Azure et en mode locatif (OPEX).

Cas d’utilisation réels

La mise en place d’Azure ARC peut permettre à une entreprise par exemple de :
- Simplifier les moyens de supervisions d’un SI hétérogène dans un seul outil,
- Étendre un SI existant sur d’autres datacenters,
- Créer et opérer des applications cloud natives à grande échelle,
- Assurer la cohérence des déploiements et de la configuration,
- S’appuyer sur les connaissances existantes des développeurs Azure

Quel que soit le scénario, Azure Arc répond aux enjeux actuels des DSI.

L’application s’adapte à son environnement : DapR

Depuis quelques temps nous suivons de près le projet DapR.io qui peut être un véritable accélérateur dans la mise en place de solution de type micro-services. De plus, Microsoft vient d’annoncer durant l’événement Ignite 2021 l’ouverture d’un nouveau service Azure nommée Azure Container Apps qui intègre le runtime DapR.
L’objectif de DapR est simple, il propose au développeur de se concentrer sur le code de son application en limitant les dépendances à l’infrastructure sous-jacente.

Focus sur l’app pas sur l’infra

DapR utilise un modèle « sidecar » permettant de faire le lien entre les différents services applicatifs via l’usage d’API internes et propose un système d’interfaces pour communiquer avec l’infrastructure via des fichiers de définitions. Afin de répondre aux différents scénarii applicatifs DapR possède des « Building Blocks » qui vont être de véritables accélérateurs :

Evolution simplifiée de l’infra

L’ensemble de ces briques peuvent être associés à différents types de services via de nombreux connecteurs proposés par la communauté et en perpétuelle évolution. Comme nous pouvons le voir sur le schéma suivant les différents services d’infrastructures peuvent être modifié par simple configuration et permet de faire évoluer le socle sans toucher à l’application.

Dans cet exemple, cela peut nous permettre de déployer la même solution applicative sur différents socles d’infrastructure en ne modifiant que des fichiers de configurations.
DapR est donc une technologie essentielle pour entrer dans l’ère du « Run Anywhere » en découplant le service ou le code de la plate-forme qui l’exécute.

Conclusion : Cloud Provider agnostique ? Mythe ou Réalité ?

Nous l’avons démontré dans cet article, la mise en place de solutions « Cloud Provider agnostiques » est aujourd’hui possible. Microsoft, pourtant cloud provider lui-même, investit dans des technologies facilitant cette multiplicité.
Toutefois, cet agnosticisme nécessite des moyens et des efforts supplémentaires tant en ressources qu’en temps de développement. Quand c’est possible, privilégiez le choix d’un Cloud-Provider (et de ses services) qui correspondent à votre besoin. Cela permettra de gagner en temps dans l’implémentation et de tirer parti de fonctionnalités natives : sécurité, scalabilité, backup… Il serait dommage de ne pas utiliser ces avantages.
Toutefois, l’approche « run anywhere » offer une abstraction qui ouvre le champ des topologies possibles et permet des scénarios complexes et globaux. Aujourd’hui, une application de type microservices qui doit être déployable sur tout type de configuration doit s’appuyer sur les Containers, Azure ARC et DapR.
La vérité est sans doute entre les deux. Affirmer un choix et une conviction pour bénéficier du spécifique, mais s’ouvrir à la possibilité d’étendre sa topologie au-dela du périmètre initial. Aujoud’hui, les technologies le permettent. Et ce sont les Cloud Provider eux-mêmes comme Microsoft qui déverrouillent le « Run Anywhere »