«De la même manière que la machine virtuelle était devenue la ressource élémentaire du data center, l’application devient le capital de l’entreprise, explique Hugues De Pra, Head of Architecture, Data Center & Virtualization, Cisco. Les rythmes de développement et de mise en production ne sont plus les mêmes qu’auparavant, les applications ne peuvent plus se satisfaire d’organisations en formes de silos; tout pousse vers l’intégration du développement et des opérations -le fameux DevOps. Les infrastructures, aussi, doivent s’aligner avec les exigences applicatives et passer d’une gestion centrée sur les équipements à une gestion centrée sur les besoins applicatifs pour offrir plus d‘agilité.»
On en revient toujours aux applications, l’élément clé qui supporte le business. La capacité de les déployer rapidement et de maintenir leur niveau de performance, tout en gérant les règles de sécurité, est donc essentielle… «Le problème, aujourd’hui, est qu’il y a un fossé entre le monde des infrastructures et celui des applications : il peut ainsi s’écouler plusieurs semaines entre l’arrivée d’une nouvelle application et sa mise à disposition des utilisateurs, notamment du fait du temps requis pour le provisionnement des ressources et services réseaux, serveur, stockage, mais aussi pour la mise en place des paramètres de sécurité adéquats que l’on a parfois tendance à sous-estimer», enchaîne Juan Lage, Principal Engineer Data Center SDN, Cisco.
La solution dépasse le cadre du SDN
Tout l’enjeu d’ACI, selon Cisco, est de proposer une architecture capable d’accélérer la mise à disposition de ces applications dans le data center; une architecture qui se traduit par la mise à disposition de composants matériels et d’un nouveau langage permettant de traduire les besoins en infrastructure des applications.
Est-ce pour cette raison que Cisco ne propose pas l’ACI sous l’étendard SDN ? Cisco le répète : «l’ACI va plus loin que le SDN !» Le principe de l’ACI remonte à 2008, quand, avec l’UCS, Cisco a combiné l’informatique, la mise en réseau, l’accès au stockage et la virtualisation. L’UCS a été -et reste- la base d’une plate-forme de consolidation visant à fournir des applications sur demande, un modèle d’automatisation des fonctions de calcul. L’ACI s’en inspire.
«L’ACI repose sur le même modèle pour l’automatisation du réseau, poursuit Hugues De Pra. L’ACI permet de fournir des applications où et quand le besoin s’en fait sentir, et de le faire dans les bonnes proportions, tout en tirant parti d’une sécurité intégrée.»
Mais pas question de se limiter à l’automatisation du réseau. L’ACI prend en compte les environnements physiques et virtuels. «L’approche se veut globale, le principe de base de l’ACI est non exclusif, insiste Juan Lage. En ce sens, l’ACI se distingue des autres solutions du marché en offrant un modèle opérationnel commun pour des réseaux physiques ou virtuels sans ajout d’autres composants. Il n’est donc pas nécessaire de gérer séparément ses réseaux.» Bref, la complexité s’en trouve réduite. L’ACI ne nécessite qu’une seule console, contrairement à d’autres solutions, pour les services réseaux de couches 4 à 7 fournis par des sociétés tiers.
L’ACI est agnostique
Agnostique vis-à-vis du ‘form-factor’ de l’équipement sur lequel l’application va être déployée. L’ACI supporte aussi bien des serveurs bare-metal, des machines virtuelles que des containers. C’est important. «La technique des containers bouleverse la manière dont sont déployées les applications, observe Hugues De Pra. Des entreprises comme Spotify, Evernote ou Airbnb, pour ne citer que les plus en vue, l’ont adoptée. Et beaucoup vont suivre dans un souci de simplicité. Désormais, installer un ERP ou une base de données sur un serveur se fait par un simple glisser-déposer d’icône : plus de processus d’installation, plus de copie de DLL ou de fichiers dans de multiples répertoires, plus de données placées dans les registres ! L’application se trouve dans une bulle étanche, un container, où elle s’exécute indépendamment des autres containers de la machine.»
Si la virtualisation a prouvé son intérêt pour la consolidation efficace de serveurs, il ne demeure pas moins que certaines applications peuvent pâtir d’overheads dus à l’hyperviseur. Il faut donc tenir compte de la portabilité de l’application. Une technologie comme Docker apporte cette portabilité quel que soit le serveur… Grâce à cette flexibilité, l’ACI peut appliquer des règles à travers une infrastructure hétérogène qui comprend des containers Linux.
«L’adoption des conteneurs étant appelé à s’accélérer, la gestion d’un nombre important de containers va devenir critique», renchérit Juan Lage. De nombreuses initiatives Open Source travaillent sur le sujet en s’intéressant particulièrement à la scalabilité, la planification et l’administration. Cisco est engagé dans des initiatives ou communautés comme OpenStack, Mesos, Kubernetes pour assurer l’intégration de l’ACI. Et de poursuivre : «Nous allons offrir une plate-forme pertinente à l’application, que celle-ci soit physique, virtuelle, un conteneur Linux ou un legs, nous devons accueillir tout cela !»
Plus simple, donc plus économique
Sur un autre registre, Cisco présente l’ACI comme ‘la’ solution de sécurité. Pour Hugues De Pra, tout est lié. Il convient d’avoir une sécurité au niveau du système, tant pour le matériel que pour les logiciels. «Si vous prenez en charge un réseau sans sécurité, il devient votre maillon faible. Avec l’ACI, la sécurité est intégrée à vos politiques en matière de réseau et aux profils de politique d’application. Vous pouvez être plus proactifs au plan de l’atténuation des risques puisque vous pouvez contrôler l’ensemble du trafic dans votre centre de données en temps réel.»
Selon le Cisco Cloud Index, 31% des charges de travail seront dématérialisées dans des clouds publics de centres de données en 2018, contre 22% en 2013. De là, l’importance du provisionnement.
«Avant toute chose, il convient de reconnaître que les opérations visant à fournir des services d’infrastructure à vos applications constituent une tâche manuelle et cloisonnée, justifie Juan Lage. Ne serait-il pas plus simple d’opter pour une mise en service automatique des applications, via le LAN, le WAN, le cloud privé ou public ?»
Plus simple… et moins coûteux. De fait, les services dématérialisés devraient être fournis dans le cadre d’un modèle instantané et pratique qu’il soit hybride, privé ou public. «Ce faisant, vous réduirez automatiquement vos coûts ! En interne, confirme encore Hugues De Pra, nous exploitons désormais 20% de capacités de calcul et de stockage en moins. Cela correspond à une réduction de 40% par rapport à nos modèles OPEX et CAPEX.»
