Technologies

CPI-B2B : le SDx pour l'automatisation des infrastructures

CPI-B2B : le SDx pour l'automatisation des infrastructures
Le 25 janvier 2019, le CPI-B2B s’est réuni sur le thème « Quand le matériel se transforme en logiciel : infrastructures convergées et automatisation. »

Les infrastructures définies par logiciel (SDx) permettent une automatisation de leur administration mais elles ne sont pas sans défaut.

PublicitéVingt ans la naissance du Google File System, un quart de siècle après celle du stockage unifié, la virtualisation des infrastructures est rentrée dans les moeurs des entreprises. Nous en sommes aujourd'hui aux infrastructures définies par logiciel ou « software defined » (SDx) : SDS (stockage), SDN (réseau), SDDC (datacenter complet)... La base de cette approche est la scalabilité et l'agilité sur du matériel banalisé. Le 25 janvier 2019, le CPI-B2B s'est réuni sur le thème « Quand le matériel se transforme en logiciel : infrastructures convergées et automatisation », occasion de revoir les avantages et inconvénients de cette approche.

Côté avantages, ils sont bien connus et évidemment mis en avant par les fournisseurs. L'administration unifiée et la capacité à l'automatiser par scripts permettent ainsi de simplifier grandement les tâches courantes des responsables d'exploitation. Les administrateurs (ceux qui restent...) peuvent ainsi se concentrer sur des tâches plus complexes (et nécessitant plus de compétences) ainsi que sur la réponse aux attentes métiers. Le coût global de fonctionnement des infrastructures baisse donc. Surtout, la DSI interne devient capable de répondre en « as a service » aux attentes soudaines des métiers qui n'ont plus d'excuses pour recourir à du cloud public en shadow IT. L'infrastructure devient ainsi une commodité parmi d'autres, son agilité autorisant au passage à des approches de type DevOps.

Mais il ne faudrait pas oublier des difficultés nouvelles. Déjà, sur le plan humain, gérer des infrastructures par codage implique que les administrateurs deviennent des codeurs. Côté cloud public comme côté cloud privé, les API de programmation varient selon les fournisseurs : il est donc impossible de disposer d'outils communs, unifiés, à moins d'employer des logiciels spécifiques, des Cloud Management Platforms. Les programmeurs peuvent être tentés d'user et d'abuser des ressources illimitées (ou presque), n'ayant aucune gestion des ressources et multipliant ainsi les coûts inutiles (comme des machines virtuelles sans utilité mais laissées allumées et donc facturées). Enfin, plus on multiplie les couches, ici de virtualisation et d'abstraction, plus les risques de dysfonctionnement et la complexité augmentent.

Partager cet article

Commentaire

Avatar
Envoyer
Ecrire un commentaire...

INFORMATION

Vous devez être connecté à votre compte CIO pour poster un commentaire.

Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire

    Publicité

    Abonnez-vous à la newsletter CIO

    Recevez notre newsletter tous les lundis et jeudis

    La question du moment
    Une procédure simple est-elle à disposition de la DSI pour réclamer des pénalités aux fournisseurs ne respectant pas les SLA / les clauses contractuelles ?