Now Reading
Cloud privé, automatisation : une transformation
0

Cloud privé, automatisation : une transformation

by Cloud Guru25 mars 2013

Etat des lieux business

Les entreprises ont depuis plusieurs années vu l’intérêt de l’automatisation des gestes techniques. L’organisation des services informatiques en sous-ensembles fonctionnels à favorisé la création d’une rupture entre ses services. En effet, chaque silo organise, documente et instrumente les processus. Il existe, dans la plupart des cas des processus globaux documentés. L’ensemble de ces processus assemblés de bout en bout donne un service plus ou moins consommable. Par exemple, le déploiement d’une machine virtuelle, le provisioning des agents pour la gestion opérationnelle ou le déploiement de middlewares / applicatifs utilisent des outils différents et le processus transverse n’est pas instrumenté.

Les éditeurs de logiciel

Les outils permettant d’adresser l’automatisation des gestes techniques sont répandus depuis une décennie, ceux-ci permettent de coller aux processus techniques existants.

D’un autre coté, les acteurs du marché ont tendance à fournir des « appliances » logiciel ou matériel fournissant un service efficace et déployables avec un investissement minimum. Il est donc possible de directement profiter des meilleures pratiques pour bénéficier d’une productivité maximale. Cette approche se base en premier lieu sur les services d’automatisation et d’usage des services au travers d’un portail. Celui-ci facilite l’usage et l’adoption  des services. Les services permettant un maintien opérationnels ne sont pas dans les packagings standards.

Analyse

La réalité n’est pas dogmatique, les clients ont besoin de transition dans cette transformation. La difficulté n’est pas dans la technologie pour fournir un service Iaas ou Paas, mais dans la transformation des processus existants et dans l’industrialisation des services/outils organisés en silo.

Il est aisé de comprendre que plus le nombre d’outils est important, plus il est difficile de créer un service automatisé. Chaque intégration point à point correspond à un processus complet. Il s’agit donc d’un effort très important pour documenter, réaliser et maintenir ces interfaces dans des écosystèmes en évolution permanent.

La difficulté est d’identifier le sponsor ayant accès à la transformation car l’intérêt local n’est pas celui de l’entreprise.

Il y a donc une évolution dans les rôles. Une étape importante est de bien définir les rôles pour s’assurer que les services correspondent à chaque contrainte, utilisateur pour le consommateur, technologique et opérationnel pour le développeur de service.

Etapes d’adoption

article1_1La transformation des processus existants n’est pas instantanée. Il est nécessaire de définir une  « roadmap » d’adoption du Cloud incluant plusieurs étapes dans la maturation d’automatisation des services. Ce changement doit formaliser les services et architectures correspondantes. Par exemple un Cloud disposant d’un outil permettant de mesurer l’usage afin de le refacturer (Mode Opex Vs Capex) , il est très rare que les entreprises changent directement le charge-back, qui est le plus souvent basée sur la base Asset ou CMDB. De même il faut créer un service standard de « Iaas » (Image avec outils standards) avant de pouvoir imaginer et l’orchestration et le déploiement d’application complexe.

Il faut donc définir des « pattern » d’architecture d’adoption incluant tous les composants nécessaire à la création et au maintient opérationnel des ressources IT.

Une règle simple est de limiter le nombre d’outils, afin d’accélérer et limiter les coûts de mise en œuvre et de  maintient.

article1_2

Illustrations

Le provisioning d’un logiciel middleware sur un environnement virtualisé demande l’intervention d’un architecte pour chaque application. Il semble donc difficile d’imaginer une orchestration standard. Les architectes applicatifs doivent être la source des développements, des offres standardisées, mais aucunement le groupe définissant le contenu du catalogue.

Rationnel de transformation

Si l’entreprise décide de prendre les processus existants, et de les orchestrer dans un outil, le coût sera infini car le nombre de services est infini et en évolution constante.

Il faut également prendre les processus en cours et comprendre les outils existants. Un autre exemple peut être : « j’ai besoin de cloner des environnements complets pour les distribuer à mes testeurs ». La vraie question est alors de fournir un service à un testeur incluant des OS, des middlewares et une version application. Si le Cloud permet de reproduire automatiquement une configuration prédéfinie, il n’y a plus de raison de cloner. Dans ce cas on observe que le Cloud offre une forte gouvernance sur les services de test.

Cette opération de standardisation a aussi une logique économique, si celui-ci est demandé 3 fois par an, il est difficile de faire l’investissement d’industrialisation.

article1_3

Conduite du changement

Cette transformation passe par la compréhension du client et la construction d’un catalogue de service. Il n’est pas possible de s’affranchir de l’existant mais il est indispensable d’en comprendre la finalité : un service pour des consommateurs dans un contexte technologique et économique.

Avec une approche globale du processus de l’entreprise il est plus aisé de s’engager dans une transformation vers le Cloud privé.

Bertrand Raillard
En tant que Lead Architect depuis 4 ans pour des engagements chez de nombreux clients, Bertrand a une connaissance avancée du cloud.
Auparavant il faisait partie d’une équipe globale sur Service Management (SWAT) au sein d’IBM software. Ce groupe possède les best practices Service Management et déploiement des solutions software.

{lang: 'fr'}
About The Author
Cloud Guru

Vous souhaitez réagir sur cet article ?