Introduction

Contexte

La petite histoire

Vous avez dit Cloud ?

Oooh... l'arnaque commerciale!! hm!

Il était une fois, un petit commercial qui ne comprenait rien à rien à l'informatique.

Alors, Tim, informaticien génial, dévoué et très patient, a expliqué qu'internet était un nuage de routeurs interconnectés entre eux. Les serveurs d'applications étaient connectés en périphérie de cette toile de réseaux, plus communément appelé web (Angl. toile, tissus).

Alors, le petit commercial, dans son génie (de la communication et de la poudre aux yeux, des strass et des paillettes enfumées) s'exclama :

« C'est divin! La toile est un mot ringard, nous utiliserons désormais le mot nuage et ferons un max de pognon avec du vent !!»

 

Tim poussa un long soupir, regarda le petit commercial et eu cette phrase mémorable : « C'est comme d'hab. »

 

Le cloud était né !

 

Tim pensa alors très fort, à Pierre Deproges ou au cinéma d'Audiard à propos d'orbite ou autres chefs d'escadrilles (voir ici ou )

 

Mais, enfin. C'est quoi le cloud ?

Le réseau internet est fondamentalement un réseau de réseau et ne contient que des routeurs.

Le cloud est donc ce qui reste, c'est à dire un ensemble non limité de serveurs accessibles en ligne. C'est tout.

- Waaaa, mais c'est archi simple !

- Oui, enfin presque.

 

Le cloud ne se limite pas au matériel, c'est plutôt une vision de celui-ci et des services qu'il propose.

Il faut donc aussi tenir compte qu'il existe plusieurs niveaux de service, groupés dans des catégories : IaaS, Paas, Saas, FaaS et plein d'autres aas encore. Des saladiers pleins.

 

Les enjeux

Parties prenantes

Tout le monde est concerné par la question du cloud

  • L'entreprise : Quelles sont les conséquences financières, organisationnelles du cloud, quel est l'impact sur la sécurité à court et long terme ? Est-ce bon pour notre image ? quelles compétences développer, conserver, déléguer ?
  • Les clients : Quelle relation avec notre fourniseur ? Quelle sécurité pour nos données ?
  • Les banques : Quel sécurité pour l'investissement, les prêts ?
  • Les fournisseurs : Quelle évolution des ventes ? Arriverons-nous à suivre la demande ?
  • Les employés : Quelle sécurité de l'emploi, quelles modifications de l'organisation ? Y aura-t-il une externalisation de l'informatique ? Seront-nous assez compétents ?
  • Les ESN : Quels nouveaux métiers développer (hébergement, étude) ? Quelle(s) technologie(s) investir ? Devrons nous nous engager sur des niveaux de services, avec quels risques ?

Pour l'entreprise

Pour une entreprise, les enjeux sont divers et très marqués. On trouve en vrac les enjeux :

  • financiers : quel est le prix du cloud ? par rapport à une architecture auto hébergée ?
  • organisationnels : quel modification des usages, de la structure de l'organisation ? quels gains de mobilité ? quelles connaissances à acquérir ? Peut-on gérer nos données sans aide, en plus de notre activité ?
  • sécurité : peut-on confier nos données, nos traitements à un tiers, quelle pérennité de ce tiers ? Quelle portabilité des données vers d'autres systèmes ?

 

Les niveaux de cloud

Traditionnellement, on distingue trois niveaux techniques principaux de cloud : IAAS, PAAS, SAAS, basés fondamentalement sur la virtualisation des infrastructures

Les principaux niveau de cloud sont :

  • (IaaS) Infrastructure as a service

    Modèle le plus ancien : le fournisseur loue des ressources physiques : ordinateurs, stockage, périphériques réseau, ou plus souvent virtuelles : RAM, Coeurs, disques, …, parfois avec un OS.
    Le client est entièrement responsable du contenu et de sa configuration (installation, gestion des logiciels, supervision et suivi). Le coût de location (redevance) est adapté aux ressources accessibles (machine, périphériques, nombre de coeurs, taille de RAM, de stockage, etc.)
    + Avantages : le client possède une maîtrise totale du contenu, décharge le coût matériel.
    - Inconvénients : pour l'ESN, peu de partage d'infrastructure, les ressources sont bloquées pour chaque client, pour le client : disposer des compétences, nécessité de maintenance logicielle (dev, maj, sécu, etc.)

  • (PaaS) Plateform as a service

    Le client a accès à des plates-formes logicielles qui exécutent des services spécifiques, /ex : stockage intégré, bases de données et environnements d'exécution Java/.NET/php. Le fournisseur s'engage sur la configuration et la gestion des plateformes.
    + Avantage ESN : les plateformes peuvent être partagées par plusieurs clients avec des mécanismes d'isolation (comme la facturation) spécifiques à la plateforme, exploiter le multiplexage statistique de plusieurs clients utilisant la plateforme en même temps.
    + Avantage Client : garantie assurée à travers des accords de niveau de service (SLA).
    - Inconvénients client : mêmes contraintes que Iaas au niveau applicatif. Les sauvegardes sont souvent à sa charge.
    Le PaaS est plus efficace que l'IaaS du point de vue du partage des ressources.

  • (SaaS) Sotfware as a service

    Application complète proposée par le fournisseur. /ex bureautique (ggDocs, MS), stockage (ggDrive, dropbox, own/nextcloud, oneDrive…), stockage et édition de photo, messagerie, gestion de contenu en ligne, etc …
    L'application est totalement exécutée sur l'infra du fournisseur. Il gère totalement la plateforme
    + Avantage ESN : le client est dépendant de l'application. Inconvénient : gérer le développement, les dépendance entre les modules, etc. Avantage : pourvoir faire appel à une communauté de développeurs
    + Avantage Client : aucune gestion de l'application et ses mises à jour, son développement. L'appli est toujours à jour et au top des développements, le cycle de vie est géré à 100% par le fournisseur, on ne gère que des documents, des données. Pas de gestion de sauvegarde
    - Inconvénient : limitation de l'application aux fonctionnalités standard (pas de développement spécifique au client ni d'innovation hors du fournisseur), législation du pays d'hébergement, risque sur la protection des données (production et sauvegarde), confiance, etc.

  • (FaaS), Function as a service

    Dernière évolution du cloud computing : les micro-services, fonctions élémentaires, briques de construction des applications.
    + Avantage dévloppeur : développer des applications comme une composition d'appels de fonctions élémentaires (briques, AWS, MS Azur)
    + Avantage client : idem PaaS et BaaS, forte évolutivité : les fonctions sont activées à la demande, les ressources de calcul s'adaptent automatiquement à la charge, le coût est calculé finement, en fonction de l'usage. Coût évolutif en fonction de la croissance de l'activité
    - Inconvénient : localisation de l'hébergement des fonction et des données n'est pas toujours en accord avec la nature de l'application déployée (confidentialité). Dépendance forte au fournisseurs de service, complexité des parties prenantes.

Intégration comparée des couches logicielles et services d'infra

Fonction Sur siteIaaSPaaSSaaS
Applicationnonnonnonoui
Runtimes nonnonouioui
Intégration SOAnonnonouioui
SGBD nonnonouioui
OS nonnonouioui
Virtualisation nonouiouioui
Serveur nonouiouioui
Stockage nonouiouioui
réseau nonouiouioui

Et les autres ...

En vrac :

  • BaaS : Backend, gestion des données des application, gestion des comptes, des produits, des sauvegardes, des conctenus

    Réponse aux besoins des applications mobiles, synonyme de Mobile Backend as a Service (MBaaS).
    Regroupées sous forme de service par le fournisseur de cloud, prêtes à être utilisées un peu comme le SaaS (càd sans avoir à gérer des serveurs ou une infrastructure (virtuels)) et hautement composable comme PaaS, briques de services. Par exemple : fonctionnalités standard : authentification des utilisateurs (france connect : services de l'état, google connect : pinterest, facebook, etc.), intégration des réseaux sociaux, stockage de fichiers (oneDrive).
    Avantage développement : dev plus rapide mais soumis aux contraintes du fournisseur de la fonctionnalité
    Avantage plateformes : centraliser/externaliser/mutualiser certains services complexes : /ex : authentification garantie par gg
    Inconvénient client : un seul service d'authentification = risque accru sur son usage, le reste est souvent transparent pour le client

  • DaaS : Desktop as a service, des PC en ligne ou comment conserver son bureau quelque soit la connexion

    Plateforme munie d'un environnement graphique avec la gestion d'un bureau personnel à chaque utilisateur. Avantage : réduction des coûts de gestion de l'infrastructure, environnement constant et accessible en mobilité. Inconvénient client : confidentialité des contenus, applications disponibles parfois limitées à l'offre du fournisseur, dépendance à la connexion.

  • AIaaS : artificial "intelligence" as a service, ou les agents conversationnels des sites d'aide, de services après vente, de renseignements
  • MaaS : Maintenance as a service, le garage virtuel pour les logiciels
  • CaaS : Crime as a service, no comment
  • SECaaS : Security as a service, la réponse au CaaS
  • XaaS : Tout as a service, tout et n'importequoi peut être virtualisé et proposé comme un service.

Vision selon le niveau de service

SaaS Données
Application
Intégration SOA, REST (*) Bases de données (*)
PaaS Runtimes
Operating System (*)
IaaS Virtualization
Serveur Stockage
Réseau

(*) Parfois fourni par le niveau inférieur

SOA : Service Oriented Architecture ; REST : REpresentational State Transfer

 

Le cloud en forme

Le cloud, c'est aussi une infrastructure plus ou moins ouverte

On distingue donc les clouds "on premise", privés, public et hybrides, communautaire.

  
  • Cloud "On premise" : Toute l'infrastructure est hébergée au sein de l'organisation, dans une DMZ accessible par internet.
    L'accès est contrôlé par un routeur, firewall, etc.
  • Cloud privé : Accès privé, espace de travail réservé à l'organisation.
    La connexion est souvent faite avec VPN
  • Cloud public : Espace public ou privé sur un serveur accessible librement par internet.
    Pas de sécurité d'accès via le web sauf HTTPS SSL/TLS et authentification interne à l'application hébergée
  • Cloud hybride : Accès privé pour la gestion, public pour l'utilisation par les clients, les fournisseurs
  • Cloud communautaire : Espace partagé par plusieurs organisation ou clients, sans pour autant avoir de connexion entre les données. Voir la notion de multi tenant ci-après.

Architecture des bases de données multi tenant

Il existe quatre voies de partage des services de SGBD :

        

 

PGI & plateformes commerciales

- Allez! Encore un petit dernier, pour la route ?

 

Le cloud, c'est bien. Mais les commerçant ont-ils tous leur propre site de vents ?

- Ben non. Ils vendent par Amazon, Alibaba, Ebay et les autres

- Ben oui. Donc ils confient leur gestion de production à ces boites ?

- Ben non. Mais ils utilisent certains de leurs fonctions (FaaS) comme outil de gestion interfacé avec leur production.

- Ben ... Aaaaaah Oooohhh.

- (Soupir).

Les PGI et ERP

PGI : Progiciel de gestion intégré ; ERP : Enterprise Ressource planning

  • Système autonome, modulaire
  • nourri en ligne (http) ou en direct,
  • propriété de l'organisation

Exemples :

  • Issus de la production : SAP, Infor, Dolibarr
  • Issus de la comptabilité : EBP, Sage, CEGID
  • Autres : Divalto (alsace), Odoo (opensource), ERP5 (gratuit)

Les Plateformes commerciales

  • Logiciel autonomes et hébergé : Shopify, Wix, WooCommerce, PrestaShop, Squarespace
    • Gestion des stocks, des ventes et paiements, vitrine catalogue
    • rôle d'outil de gestion, vitrine/catalogue, comme pour une échoppe classique
  • Service de relation client et vente en ligne : amazon, alibaba,
    • gestion des stocks, des ventes et paiements, des transactions financières, de la relation client, vitrine catalogue,
    • rôle de distributeur (comme un supermarché) : hyperscalers
    • rôle de places de marché en ligne : offrent des outils de communication interactifs avec les ERP des vendeurs

 

Liens divers pour info :

  • https://fourweekmba.com/fr/alibaba-vs-amazon/
  • https://modern-workplace-solution.fr/fournisseurs-de-cloud-le-comparatif/

 

Vous l'avez fait en pratique

Enfin ! Contenu en liaison avec l'activité professionnelle S3A1

Comparatif des offres

Choisir les critères

Le plus important est de bien définir les critères de choix des offres, quelle que soit la cible de l'étude de marché.

Ces critères sont multiples et dépendent des conditions et besoin de l'organisation, aussi insignifiants soient-ils. Chacun possède ses propres revendications et elles ont toutes une origine, une légitimité.

Pour le cloud, on pourra par exemple s'interroger sur :

  • la dépendance de l'organisation cliente à la solution choisie,
  • l'étendue des services disponibles et offerts,
  • les gains financiers et organisationnels dégagés pour l'organisation, ses clients, ses partenaires
  • le niveau de sécurité recherché et obtenu

 

Il n'existe pas de solution miracle, seulement :

  • des compromis : pas terrible, il restera toujours des frustrés, des objectifs partiellement insatisfaits
  • des solutions consensuelles : c'est mieux mais difficile de parvenir à contenter tout le monde, à couvrir tous les besoins
  • se méfier des offres miracles et alléchantes, dépourvue de transparence (si c'est gratuit, le produit, c'est vous)
  • de multiples solutions pour des besoins et contraintes multiples et très différentes

En réalité

Impossible de comparer des architectures cloud sur le seul aspect technique, un comparatif dépend plus :

  • du niveau de service proposé : débit d'accès, volume de stockage et sauvegardes, taille de la BDD, etc.
  • des garanties de services et du droit du pays hébergeur, des risques géopolitiques
  • de l'architecture de l'infrastructure (souvenir d'OVH) et de la gestion des risques numériques

 

Bon, Deux solutions possibles :

  • routage statique
  • routage dynamique avec un protocole de routage automatique (OSPF, EIGRP, BGP, ... selon les capacités du switch)

 

Liens divers pour info :

  • https://www.hebergeurcloud.com/difference-iaas-caas-paas-faas-saas/
  • https://www.marvel-project.eu/did-you-know-the-difference-between-iaas-paas-saas-baas-and-faas/
  • https://blog.desdelinux.net/fr/xaas-cloud-computing-tous-les-services/
  • https://www.researchgate.net/publication/354705423_A_Comprehensive_Overview_of_Privacy_and_Data_Security_for_Cloud_Storage

 

Exemples de métriques

Métrique, quantitatif et qualitatif

On appelle métrique, un critère de mesure, généralement quantitatif et associé à une unité de mesure
Une métrique est souvent une caractéristique, une valeur mesurée par un outil de relevé comme un gestionnaire d'inventaire (la valeur de la RAM, la capacité du disque dur, etc.) ou par un outil de supervision (mêmes valeurs et leur dynamique, la charge réseau en quantité de trames par seconde, etc)
Cependant, il est aussi possible d'associer ce terme à un synonyme de "caractéristique". Il conserve cependant la notion de quantitatif

Quantitatif : qui peut être quantifié, mesuré objectivement par une valeur numérique : taille de la RAM en octets, bande passante en Gb/s.

Qualitatif : qui est mesuré, subjectivement, selon l'intreprétation d'une évolution ou d'un état : bien être au travail, qualité de service client.
Dans qualitatif, on peut trouver des liens au quantitatif lorsqu'on observe la qualité de service par l'évolution des rapports avec les clients : augmentation des ventes, du nombre de clients, etc.

 

CritèreDescription
Complexité infra degré de complexité d'installation, dépendance à l'installation applicative des serveurs et l'environnement de l'infrastructure
Compétence infra Niveau de compétences requis en interne pour gérer l'installation et les services, le développement et les mises à jour de l'application métier et des services supports
Investissement Coût initial en matériel et abonnements d'infrastructure, effort d'organisation, de formation
Exploitation Coûts d'exploitation de l'infrastructure hors applicatif. Les coûts cachés ne sont pas évalués.
Sécurité Effort de supervision, résistance aux attaques, risque d'étendue des incidents
Maîtrise Maîtrise des contenus, de l'applicatif et des processus liés (sauvegarde, design, référencement, etc.), degré de dépendance au service fourni
Souplesse et extensibilité (scalabilité) Facilité d'accès pour les clients, les webmaster, les auteurs. Degré d'adaptabilité aux variations de flux
SLA, disponibilité Évaluation en fonction du rapport des temps de disponibilité, vitesse d'intervention en cas de panne, etc. …

 

Sont exclus : les coûts liés à l'applicatif (CMS) = développement, abonnements, redevances

 

Synthèse vue du client

Étude partielle, limitée à l'infrastructure

Les valeurs sont purement indicatives et produites en 2023. Les investissements sont uniquement matériels (pas de soft ni de services). Aucune architecture de type Faas n'est envisagée ici car sous jacente à l'application dont le coût n'est pas intégré dans cette étude du fait de la grande variabilité des offres.

 

CritèresOn premiseCloud privé (IaaS, VPS)hébergement PaasLogiciel en Saas
Complexité de l'infraélevéemoyenfaiblefaible
Compétences systèmeélevéassez élevémoyennulle
Investissementconséquentmoyenfaible
Exploitationélevéfaibleaucun
SécuritéSelon compétences internesVariable selon SLA et garanties
Maîtrise des donnéesTotale ou presquepartiellefaible
Souplesse, extensibilitéfaiblemoyenneForte selon contrat
Estimation matérielle
Investissement sur 10 ans (2023)
15k€4K€ et plus 
etc.   

 

Conclusion

Au regard de l'investissement, il n'est que peu envisageable de créer une infrastructure on premise et il est souhaitable de favoriser une application en SaaS, selon le degré de confidentialité des données collectées ou diffusées par le portail web souhaité

 

Choix On Premise

Pour une solution "on premise", auto hébergée par l'entreprise, il faut veiller à des conditions nécessaires pour assurer un minimum de sécurité face aux intrusions et autre risques d'attaques.

Un service accessible depuis l'extérieur du LAN ne doit jamais être dans le LAN afin de limiter les possibilités d'intrusion.

Conséquences sur certains services

La supervision des systèmes restera dans le LAN et pas dans la DMZ mais pourra y accéder :

  • pour superviser les services internes et externes,
  • pour être protégé des accès externes

Le PGI restera dans le LAN et pas dans la DMZ mais pourra en recevoir des commandes :

  • pour utiliser les données mises à jour par les clients sur l'interface fontale du PGI,
  • pour être protégé des accès externes

Conséquences pour le routeur

Il sera donc nécessaire de créer des règles de filtrage restrictives sur le routeur R2 :

  • Autoriser les connexions sortantes depuis tous les LANs,
  • Autoriser les connexions entre les LANs,
  • Interdire toute connexion à l'initiative de l'extérieur vers les LANs

Dérogation aux restrictions

Des restrictions ou autorisations supplémentaires pourront être mise en place, selon la politique de l'organisation. Par exemple :

  • Interdire la sortie de certains VLANs : VLAN de sauvegarde,
  • Interdire la communication entre certains VLANs : production et administration,
  • Autoriser certaines connexions vers des services LAN désignés : accès administrateur à la supervision pour permettre la mobilité,
  • Autoriser certaines connexions de la DMZ vers certains LANs : l'application frontale de gestion de la DMZ peut mettre à jour la base de données du PGI dans le LAN

 

Conclusion