Rappels sur le Cloud

Remise en place de quelques notions liées au concept de Cloud, présenté à une réunion de travail le 19/04/13. Sans prétention, non exhaustif, utile face au marketting stupide de MS etc.

Commentaires bienvenus: @jbbarth sur twitter

Transcript

1. Cloud, nuages, etc. 19/04/13
2. Définition ▪ “Le Cloud computing est l'accès via un réseau de télécommunications, à la demande et en libre-service, à des ressources informatiques partagées configurables” (NIST, Cegid)
3. Caractéristiques ▪ 1- ressources accessibles en réseau ▪ 2- mutualisation de ressources éclatées ▪ 3- libre service à la demande ▪ 4- accès rapide et souple à ces ressources ▪ 5- facturation à l'usage (Cegid)
4. Idée reçue (1) ▪ “Le Cloud c'est une question technique” ▪ d'abord un changement de culture, approche, positions client/fournisseur ▪ … ensuite un projet (très) technique ▪ … nécessitant compétences adaptées ▪ parallèle avec ITIL
5. Idée reçue (2) ▪ “Le libre service c'est l'anarchie” ▪ Exemple: le supermarché ▪ on paye à la sortie (normalement) ▪ mais la caissière ne discute pas avec le client de l'opportunité d'acheter un produit ▪ → minimisation des interactions avec le fournisseur, le client est autonome ▪ → portail client type “self-service” (?)
6. Types / approches (1) ▪ IaaS : “Infrastructure” ▪ le client gère ses VMs, IPs, règles de pare-feu, stockage, etc. ▪ le datacenter garantit l'infrastructure et la connectivité, ne gère pas les applications ni l'OS ▪ exemples: ▪ Amazon EC2/EBS/RDS, Google Compute Engine, Microsoft Azure, Rackspace, Gandi, OVH ▪ Openstack, Eucalyptus
7. Types / approches (2) ▪ PaaS : “Platform” ▪ le client déploie une application, des composants, et les intègre entre eux ▪ le datacenter gère la plateforme jusqu'à l'OS, pas l'appli ▪ limité à certaines technologies ▪ exemples : ▪ Amazon Web Services, Google App Engine, Heroku, Dreamhost ▪ CloudFoundry, Redhat Openshift
8. Types / approches (3) ▪ SaaS : “Software” ▪ le client obtient une appli prête à l'emploi (développée au préalable) ▪ le datacenter gère tout: infra, plateforme, appli, données ▪ exemples: ▪ Gmail, Google Apps, Dropbox, etc. ▪ Facebook?
9. Idée reçue (3) ▪ “Le Cloud me fera faire des économies” ▪ investissement conséquent, ROI dépend de l'échelle et des SIs qui peuvent migrer ▪ si c'est le cas, on a un énorme problème de provisionning des infras ▪ → difficile à garantir en pratique ▪ gains: flexibilité, scalabilité, agilité, autonomie
10. Idées reçues (4) ▪ “On a besoin de de IaaS avant de faire du PaaS avant de faire du SaaS” ▪ → n'a pas de sens à l'échelle d'un seul service informatique ▪ → seuls quelques très gros acteurs ont la force de miser sur plusieurs approches de front (Amazon, Google)
11. Idées reçues (5) ▪ “On fait déjà du cloud, IBM en faisait en 1970 avec ses mainframes” ▪ cloud ≠ virtualisation ▪ presque vrai sur nos offres quasi-SaaS type SPIP, Alfresco, Redmine, RT ▪ évolution possible pour l'auto-hébergement PHP
12. Implémentations ▪ Cloud public ▪ chez un prestataire, opéré par lui ▪ Cloud privé ▪ interne dans l'entreprise ▪ Cloud hybride ▪ approche mixte / multiple
13. Sécurité dans le cloud ▪ acteurs non-hébergeurs autonomes ▪ … donc perte possible de contrôle ▪ moins de cas par cas, souplesse ▪ → la sécurité ne peut plus se traiter tout à fait comme en informatique traditionnelle
14. Produit: Openstack (IaaS) ▪ ensemble de projets/composants de gestion de l'infrastructure ▪ projet assez actif / soutenu par Rackspace, NASA, et nombre constructeurs/éditeurs ▪ nombreuses technos compatibles (OS, virtu, stockage) à choisir par le fournisseur ▪ mais fonctions limitées (pas de “storage vmotion” par exemple) ▪ demande des compétences système, réseau, et stockage poussées
15. Produit: Vmware Vcloud (IaaS) ▪ un peu “vcenter à la portée du client” ▪ API complexes et pauvres ▪ interfaçage difficile avec autres produits ▪ → peu flexible → a évolué, mais non testé ▪ produit peu reconnu
16. Produit: Cloudfoundry (PaaS) ▪ plateforme PaaS : PHP, Java, Ruby, Python, Postgresql, etc. ▪ projet actif / sponsoring Vmware ▪ nécessite des développeurs qui savent ce qu'ils déploient
17. Conclusion (personnelle) ▪ quels besoins ? quels problèmes cherche-t- on à résoudre ? ▪ pour quels SI ? quelle proportion de nos SI ? ▪ si client = fournisseur = nous + pas d'autonomie client final → ce n'est pas du cloud !