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 là)
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 site
IaaS
PaaS
SaaS
Application
non
non
non
oui
Runtimes
non
non
oui
oui
Intégration SOA
non
non
oui
oui
SGBD
non
non
oui
oui
OS
non
non
oui
oui
Virtualisation
non
oui
oui
oui
Serveur
non
oui
oui
oui
Stockage
non
oui
oui
oui
réseau
non
oui
oui
oui
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.
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)
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ère
Description
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ères
On premise
Cloud privé (IaaS, VPS)
hébergement Paas
Logiciel en Saas
Complexité de l'infra
élevée
moyen
faible
faible
Compétences système
élevé
assez élevé
moyen
nulle
Investissement
conséquent
moyen
faible
Exploitation
élevé
faible
aucun
Sécurité
Selon compétences internes
Variable selon SLA et garanties
Maîtrise des données
Totale ou presque
partielle
faible
Souplesse, extensibilité
faible
moyenne
Forte 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
