Le CLoud : non plus un choix mais une obligation urgente pour toute dsi

Découvrez la suite de notre série Cloud. Après avoir examiné les raisons pour lesquelles une DSI se trouve dans l’obligation immédiate de prendre en compte les technologies Cloud, plongez au cœur de l’informatique « cloudifiée ».

Dans cette deuxième partie nous allons essayer de définir quelques uns des grands traits architecturaux de l’environnement informatique d’une entreprise qui s’est engagée dans le Cloud.

Le but est d’identifier les domaines informatiques qui devraient être impactés fortement par la « cloudification » de manière à déterminer les actions qui doivent être engagées pour anticiper ces changements, actions qui seront détaillées dans la 3e partie.

Tout d’abord, sur le plan de l’infrastructure, le Cloud dépendant fortement des moyens de communication entre l’entreprise et ses fournisseurs, on apportera une importance maximale à la résilience de son infrastructure de connexion Internet avec un doublement au minimum, voire un triplement ou plus de ses connexions.

De même, devant des besoins sans cesse croissants dus à une utilisation sans cesse augmentée de services externes Cloud, une politique de mise en place de la qualité de service (QOS), et donc de priorisation du trafic, devra être définie pour lutter contre les effets perturbateurs entre bande passante fournie et demandée.
Tout aussi important, la mise en place d’une solution d’APM (Application Performance Management) minimisera au maximum les pertes de productivité dues à des incidents, tout en vérifiant la tenue des SLA promis par les fournisseurs.

Toujours dans le domaine des connexions Internet, la DMZ verra apparaître de nouveaux venus, des appliances /gateways jouant le rôle d’intermédiaires entre les utilisateurs en entreprise et les fournisseurs Cloud. Bien sûr, ces gateways pourront également se retrouver au niveau des VPNs spécialisés permettant l’hybridation des clouds externes et internes de l’entreprise.

Cette hybridation du cloud est nécessaire car elle permettra au cloud interne de disposer avec les clouds externes d’une soupape de sécurité en termes de puissance et/ou stockage ; et surtout elle mettra à disposition des ressources internes (annuaires utilisateurs par exemple) permettant de ne pas répéter la mise en silos de parties de l’IT qui guette toute « cloudification » non maîtrisée.

Ces gateways seront au minimum de deux types :

• des gateways IRM (Identity Relationship Management), extension aux objectifs du Web 2.0 de la «traditionnelle» IAM (Identity and Access Management). L’objectif principal de ce type de gateway est de contrôler l’accès aux ressources SaaS mises à disposition des employés internes à l’entreprise tout en mettant en place au minimum un SSO avec tous les fournisseurs SaaS externes.

• des gateways de cryptage pour assurer la confidentialité des données stockées dans le Cloud. En effet si les données dans le Cloud sont toujours encryptées par les fournisseurs Cloud, elles le sont avec leurs clés. Ces gateways permettent le cryptage avec des clés définies par l’entreprise, donc assurant la confidentialité complète de ces données.

«Les données sont tout, les traitements ne sont rien». Cette phrase entendue au début de ma vie professionnelle est encore plus vraie dans le cadre du Cloud où il est impensable de sélectionner un fournisseur SaaS sans se soucier de réversibilité, avec le transfert de données afférent qui aura lieu à la fin de l’utilisation du service (fin de disponibilité du service pour une raison quelconque ou volonté de passer à un autre fournisseur SaaS).

Il est à noter que ce souci sera aussi d’actualité à l’initialisation du service dans la mesure où la migration des données existantes (cas le plus fréquent) vers le fournisseur SaaS devra également être effectuée. Ceci entraînera l’introduction d’appliances database/storage qui devront en permanence contenir une copie actualisée des données confiées au(x) fournisseur(s) SaaS.

Cette capacité, non triviale, augmentera le besoin de compétences ETL (Extract, Transform and Load) pour les entreprises qui auront compris que conserver cette maîtrise des données est une condition sine qua none de leur pérennité et de leur capacité à changer de fournisseur.

En interne, même si les applications internes deviendront les futures applications «historiques» (legacy), le développement / déploiement d’application se fera de manière orientée devops c’est à-dire par une intégration croissante des univers développement et exploitation.

Là encore, le Cloud va avoir un effet «booster» en permettant :

• une mise en place rapide et bien moins coûteuse de moyens de tests plus efficaces, comme par exemple pour les tests de performance ou avec une plus grande similarité avec l’environnement de production finale

• une réduction significative du délai de mise en place d’une nouvelle version qui donnera à l’entreprise une agilité accrue.

Comme nous venons de le voir, l’introduction du Cloud dans une entreprise aura de profondes conséquences sur la manière de «faire de l’informatique» tant en termes de développement que d’infrastructure à adapter ou mettre en place. Nous verrons dans la troisième partie les actions qu’il faut dès à présent engager pour mener cette transformation à bien.