Plus qu’une mode, l’environnement Cloud natif cherche à donner une réponse durable aux stratégies multi-Cloud et Cloud hybride maintenant privilégiées par les entreprises.

 

«Nos clients et nous fonctionnons déjà avec des orchestrateurs comme Kubernetes et d’autres outils open source d’automatisation. L’environnement Cloud natif apporte une abstraction complète des fermes de serveurs. On ne parle plus de virtualisation : vous envoyez des containers avec votre application et l’infrastructure va grossir ou réduire toute seule. Elle va devenir automatiquement redondante », explique Arnaud de Bermingham, le CEO de Scaleway, la filiale datacenter du groupe Iliad/Free.

L’industrialisation des datacenters encourage de tels automatismes tout au long de la chaîne de conception, d’intégration et de livraison des applications. Plus qu’une mode, l’environnement Cloud natif cherche à donner une réponse durable aux stratégies multi-Cloud et Cloud hybride maintenant privilégiées par les entreprises.

Il s’agit de garantir aux nouvelles applications qu’elles pourront s’exécuter en interne, sur un Cloud privé ou sur un Cloud public, pratiquement sans intervention manuelle. Fonctions, applications ou conteneurs, le conditionnement de l’application ne détermine plus l’infrastructure d’exécution. L’orchestration de services s’étend à la compilation, au déploiement et à la mise à l’échelle des applications. Ne soyez donc pas surpris face à la multiplication d’offres Serverless, CaaS (containers as a service) ou encore FaaS qui promettent d’exécuter toutes vos « fonctions à la demande » (lire l’article Migrer vers le Cloud natif en 10 étapes).

Déclencher des fonctions par événement

Le marché des plateformes Cloud hybride sera le théâtre d’un clash de titans : Red Hat (OpenShift), IBM (avec Kubernetes et Docker) et VMware (Pivotal PKS) font évoluer leurs solutions Cloud privé vers les ressources de plusieurs Cloud publics. En sens inverse, AWS, Microsoft et Google ouvrent leurs datacenters à une variété croissante de services d’entreprises. Les équipementiers réseaux pourraient se retrouver entre le marteau et l’enclume. Dès avril 2016, Cisco avalait CliQrTechnologies dont la plateforme d’orchestration Cloud facilite la modélisation, le déploiement et l’administration d’applications exécutables sur n’importe quel Cloud ou datacenter. Les clients du Cloud Center de Cisco peuvent à présent répartir leurs services tout en propageant leurs propres règles et priorités, respectées partout. En mars 2019, l’acquisition de Nginx par F5 Networks (pour 670 millions de dollars US) s’inscrit aussi dans cette transition. En associant l’innovation open source de Nginx à l’expertise ADC (Application Delivery Controller) de F5, l’infrastructure doit s’étendre du code jusqu’au client, dans un environnement multi-Cloud.

A10 Networks, Citrix Systems et Fortinet viennent également à l’administration multi-Cloud depuis l’analyse des paquets réseaux et l’optimisation des protocoles. Ils veulent offrir une infrastructure reconfigurable, à l’écoute des métiers et de leurs besoins de ressources à chaque instant. L’ultime étape consiste à déclencher les applications (ou certaines fonctions seulement) selon des événements prédéfinis.

Un socle libre pour le Cloud natif

En pratique, repenser son infrastructure pour l’environnement Cloud natif passe par l’intégration de plusieurs composants open source, pilotés par des communautés, elles-mêmes guidées par des standards et protocoles ouverts. Cette approche facilite l’innovation rapide autour de composants ciblés, simples à intégrer et interchangeables. Plusieurs écosystèmes partageant ces briques de base, les utilisateurs et les intégrateurs contribuent à la sélection naturelle des stacks et de leurs outils, via des prototypes, puis des infrastructures complètes. La transparence et l’interopérabilité étant prévues dès la conception, quelques experts corrigent les failles tandis que les premiers utilisateurs signalent les problèmes rencontrés, voire contribuent à leur résolution.

Le succès de Kubernetes suit cet itinéraire depuis quatre ans ; l’orchestrateur de micro-services initié par Google a rejoint la fondation CNCF (Cloud Native Computing Foundation) en 2016, sous la forme de projet open source. Il s’impose comme une alternative – et parfois en complément – à la virtualisation d’applications. De nombreuses formations et certifications pour développeurs et pour administrateurs entourent déjà l’orchestrateur des containers applicatifs.

« L’open source est la bonne façon de bâtir une nouvelle infrastructure. Aucune entreprise ne peut assumer seule l’ensemble du travail requis à bas niveau ni fédérer l’écosystème nécessaire. Et les clients ne veulent plus être pieds et mains liés avec un seul fournisseur, fût-il éditeur de logiciels ou opérateur de services Cloud », souligne Dan Kohn, Executive Director de la CNCF, ex-fondateur de NetMarket (transactions sécurisées) et transfuge de Teledesic, un prestataire Internet par satellite. Il pilote à présent la croissance de l’écosystème et de la communauté Cloud Native Computing Foundation, qui fait partie de la Linux Foundation. Parmi ses 375 membres, on retrouve AWS, Microsoft Azure, Google Cloud , IBM Cloud , VMware, Red Hat, Pivotal et une dizaine d’industriels mondiaux, mais aussi 79 entreprises utilisatrices, fédérées en quatre années seulement.

Une marge de manœuvre pour les ESN

Ces clients professionnels n’ont pas toujours l’équipe ni la patience nécessaires pour mettre à niveau des piles d’outils de bas niveau, ce qui laisse une marge de manœuvre aux ESN et grands acteurs IT généralistes prompts à basculer d’une plateforme à une autre pour faciliter la création et la supervision d’applications en environnement Cloud natif. « Des produits commerciaux et des composants d’autres communautés open source sont fréquemment combinés aux outils de notre fondation », reconnaît d’ailleurs Dan Kohn.

Outre son projet phare Kubernetes, la CNCF promeut l’outil de supervision Prometheus, le proxy de services Envoy, l’outil de découverte de services CoreDNS, et l’environnement d’exécution Container D plus une quinzaine de projets en incubation, comme Helm pour la gestion des packages ou encore Vitess et Rook pour le stockage. Dernier signe de sa popularité croissante, sa conférence Kubecon, à Barcelone les 20-23 mai, devait accueillir près de 10 000 professionnels.

 

---

AVIS D’EXPERT

 

Pete Johnson,
Principal Systems Engineer de Cisco depuis l’acquisition de CliQr

 

Un runtime FaaS pour libérer le développeur

« Au stade de la conception d’applications, les développeurs ont besoin d’une plateforme qui leur délivre des ressources informatiques sous forme de fichiers digestibles. L’environnement d’exécution FaaS (Function as a Service) – tel AWS Lambda, Azure Functions ou Google Cloud Functions – est à l’architecture serverless ce qu’un environnement d’exécution pour containers est à l’architecture de micro-services. Un runtime de containers prend en charge la mise à l’échelle automatique, les mises à jour progressives et la résolution des noms de services.

L’environnement d’exécution FaaS masque les détails du runtime de container sous-jacent et offre aux développeurs une expérience plus propre leur permettant de se concentrer sur la logique métier »