V110207a date.

Présentation au sujet: "V110207a date."— Transcription de la présentation:

1 V110207a date

2 Faut il avoir peur du Cloud à la DSI? (La réponse est OUI)
10 février 2011 Guillaume Plouin Responsable Offre Cloud OCTO Technology Benjamin Guinebertière Architecte avant vente Microsoft France

3 AGENDA Un Cloud inéluctable…pour le bénéfice de l’entreprise & des utilisateurs Les achats Le RSSI La cellule d’architecture Les études La Prod En conclusion

4 Rappel express sur le Cloud
Software as a Service Platform as a Service Infrastructure as a Service API ouvertes « Self Service » « Pay as you go » CLOUD PUBLIC OU PRIVÉ Abstraction de la localisation Partage des ressources VIRTUALISATION Elasticité

5 Le Cloud intéresse l’entreprise
Le Cloud = une « lame de fond » inévitable Pourquoi ? Métaphore électrique de Nicholas Carr : déléguer les commodités Externalisation de la « plomberie informatique » Recentrage sur facteurs différenciant Effet d’échelle : élasticité Effet d’échelle : (souvent) réduction des coûts Green IT

6 Le Cloud intéresse les utilisateurs
Pourquoi ? Time to Market, agilité « Customer Driven Roadmap » «  béta perpétuelle » Accessibilité Disponibilité liée à une infrastructure industrielle Intégrité liée à une infrastructure industrielle MAIS, le Cloud implique une réorganisation de la DSI…

7 Achats : problématiques juridiques
Contractualisation avec un fournisseur Cloud Abstraction sur localisation : quel droit applicable ? Droit fournisseur ou client ? Contrat standard Force de négociation si grand compte Annulation closes abusives : droit du consommateur Droit sur la donnée Réglementation sur données sectorielles (ex. secret bancaire) Possibilité de localisation en Europe Patriot Act : non respect réglementations par acteurs américains Réglementation sur données personnelles (CNIL) Approbation CNIL nécessaire pour exporter données Safe Harbour : accord EU/USA, pas toujours utilisé

8 Achats : garanties de SLA
Disponibilité proche de 99,9% (8h/an) chez la plupart des acteurs Pénalités sous forme d’extension de service en cas de dépassement Pannes dans la pratique en 2009 chez Amazon, Google, SalesForce Reste < 2 jours Différentes politiques de fonctionnement Salesforce : offre purement B2B Google : plateforme entreprise idem plateforme grand public Une certaine jeunesse dans la relation commerciale…

9 Achats : nouvelles modalités
Difficile d’avoir un interlocuteur (self service) Paiement par CB ou Paypal : inhabituel… OPEX / abonnement plutôt que CAPEX Calcul de coût pas toujours trivial : cf. calculatrice Amazon Réduction des coûts pas toujours avérée

10 Achats : calculatrice Amazon

11 Achats : les vertus de la mesure
Pay As You Go à mettre en perspective avec : Les licences inutilisées Les contrats internes, parfois obscurs Plus de contractualisation = plus de rigueur

12 RSSI : remise en cause Mise à mal de la politique de sécurité
Externalisation de données vers un tiers Robustesse des datacenters ? Sécurisation des flux ? Criticité de la classification des données Engagement pour le RSSI Collusion possible avec concurrents américains Tentation du refus du Cloud (syndrome tour d’ivoire)… … Et risque de contournement

13 RSSI : accompagner plutôt que résister
Intégrer le Cloud à la politique de sécurité Mention Cloud dans la classification des données Règles sur le provisioning des mots de passe ou fédération d’identité Règles sur les échanges de flux en architecture hybride Homologation de certains opérateurs Cloud Engagement SLA et sauvegardes de données Politique de chiffrement Contrôle des audits SAS70 type 2 et ISO27001 Test d’intrusion date

14 Cellule architecture : remise en cause
Mise à mal des bonnes pratiques d’architecture Dépendance au réseau Création d’annuaires de sécurité pirates Création de référentiels désynchronisés Middlewares peu performants, sans reprise sur incident Déport de la conception d’architecture vers des tiers Tentation du refus du Cloud (syndrome tour d’ivoire)… … Et risque de contournement

15 Des impacts à tous les niveaux…

16 Cellule architecture : accompagner plutôt que résister
Mettre en place un centre de compétence Cloud Etat de l’art sur plateformes PaaS/IaaS, leurs spécificités architecturales, leurs APIs Usage de nouvelles architectures Etudes sur commodités externalisables Homologation d’opérateurs Tests de réversibilité « Architecture Hybride » Solutions d’intégration & fédération d’identité sur étagère

17 La réversibilité Réversibilité assurée via API
Pour applicatifs : scénario de sortie comparable à progiciels Stratégies de vérification Confiance dans les API de l’opérateur Protocole de test des API Demande d’engagement de faisabilité auprès du prestataire Demande au prestataire de fournir la solution de réversibilité clef en main

18 Etudes : nouvelles contraintes
Développement sur PaaS = architecture contraintes Modèles de données dénormalisés, No SQL, … Gestion atypique des transactions, … Limitations sur les temps de réponse, volume et format des objets stockés, volume des réponses… Cloud = perspective DevOps SaaS métier (relativement rare) = Danger Pas de remise en cause profonde dans l’organisation du travail

19 Théorème de CAP Théorème de CAP
Consistency Consistance Availability disponibilité Partition-Tolerant tolérance aux pannes Théorème de CAP « dans une architecture distribuée de grande envergure, il n’est possible d’assurer que deux des trois propriétés CAP ». Les acteurs du Cloud privilégient les propriétés A et P -> Scalabilité horizontale -> Banalisation des composants serveurs

20 Gains Pertes NoSQL Performance, débit en écriture
Résilience, Disponibilité Manipulation de gros volumes de données Parallélisation / Distribution des traitements Modélisation impossible ou difficile à requêter dans le modèle relationnel Pertes Perte des aspects relationnels Perte du système de requêtes SQL Relâchement des propriétés ACID Autant de fonctionnalités à gérer au niveau de l’espace applicatif

21 Prod en danger ? IaaS Acquisition de nouvelles compétences sur les plateformes concernées Changement : agilité, facilitation DevOps SaaS Réduction du spectre d’intervention de la Prod : provisioning des comptes et paramétrage PaaS Remise en cause de la Prod : simple monitoring/surveillance

22 Gérer la dépendance au réseau

23 La console office 365 date

24 La console Azure

25 Supervision IaaS/PaaS ?

26 La Prod au chômage ? Recentrage sur : Support utilisateur
Exploitation applications métiers différenciantes Exploitation infrastructures innovantes Les équipes de Prod seront probablement réduites…

27 Ou l’occasion de travailler sur les processus ITIL
CHANGEMENTS MISES EN PRODUCTION INCIDENTS PROBLEMES NIVEAUX DE SERVICE DEMANDES DE SERVICE PROVISIONING IT Utilisateurs SERVICE DESK - Service Strategy Service Design Service Transition Service Operation CONFIGURATIONS (CMDB) date

28 Impacts organisationnels du Cloud
DELEGUE COMMODITES direction NÉGOCIE CONTRAT directeur général achats direction sureté direction informatique ACCOMPAGNE ou RESISTE ACCOMPAGNE ou RESISTE direction architecture du SI RSSI DSI : direction des études DSI : direction de la production directions métiers utilisateurs PaaS/IaaS OK SaaS : CONCURRENCE IaaS OK SaaS/PaaS : DANGER GAGNE EN TIME TO MARKET TENTATION CONTOURNEMENT DSI date

29 MSDN et TechNet : l’essentiel des ressources techniques à portée de clic
Portail administration et infrastructure pour informaticiens Portail de ressources technique pour développeurs

30