Capacités courantes des grandes infrastructures infonuagiques en tant que service (IaaS)

13.2 Capacités courantes des grandes infrastructures infonuagiques en tant que service (IaaS)

Objectifs d'apprentissage

À la fin de cette section, vous serez en mesure de :

  • Apprendre à utiliser les services de stockage IaaS
  • Apprendre à utiliser les services de calcul IaaS
  • Comprendre les services de support IaaS pour les applications web et mobiles
  • Comprendre les services de gestion de conteneurs IaaS
  • Comprendre les services de support IaaS pour la gestion de bases de données

Du point de vue du modèle d'affaires, les start-ups et les entreprises ayant des charges de travail fluctuantes dépendent de la recherche d'un moyen de déployer et de gérer efficacement leurs applications. Cela inclut des considérations telles que des performances fiables et économiques qui peuvent s'adapter à des demandes saisonnières imprévisibles. Cela nécessite un modèle de service qui permet aux entreprises d'accéder aux ressources infonuagiques et d'adopter des infrastructures agiles sans avoir à se soucier de la gestion informatique.

Une solution à une telle demande est l'infrastructure en tant que service (infrastructure as a service (IaaS)). L'IaaS offre un accès à la demande aux services d'informatique en nuage, propose un modèle de tarification à l'usage et permet à l'utilisateur de tirer parti des serveurs infonuagiques en gérant virtuellement les données et les serveurs pour son application. L'IaaS permet à l'équipe d'ingénierie d'optimiser la plateforme à partir de l'infrastructure et de ne pas être liée aux paramètres d'un fournisseur de services infonuagiques.

Dans cette section, nous examinerons plus en détail les différentes couches d'opérations que l'IaaS fournit. L'infrastructure étant fournie sans aucune configuration spéciale, l'IaaS, en tant que cadriciel, exige des compétences et du temps supplémentaires de la part de l'équipe d'ingénierie pour configurer et maintenir sa plateforme. Tout au long de ces sections, nous passerons en revue différentes infrastructures courantes que les fournisseurs IaaS grand public prennent habituellement en charge afin que nous puissions déterminer la meilleure approche pour maintenir nos applications infonuagiques.

Service de stockage

Un service de stockage (storage service) est l'un des composants d'infrastructure de base qu'un fournisseur de services infonuagiques fournirait pour permettre à l'utilisateur et à l'application de lire, d'écrire et d'accéder au stockage. Ces services sont des services de stockage élastiques, et le mot élastique est utilisé tout au long du chapitre pour indiquer un nombre illimité de ressources auxquelles l'utilisateur peut accéder auprès du fournisseur de services infonuagiques. Certains composants courants de l'application qui peuvent nécessiter un accès au stockage sont les données analytiques, les informations de journalisation, les données d'application, les images et les vidéos. Le stockage requis pour ces composants peut augmenter avec le temps à mesure que l'application fonctionne, de sorte que les utilisateurs doivent comprendre le type de service de stockage qu'ils choisissent pour leur application. Il est également courant que l'utilisateur puisse choisir plus d'un service à utiliser dans son application. Il existe plusieurs types de services de stockage que l'utilisateur peut choisir, selon le fournisseur de services infonuagiques. Par exemple, Microsoft Azure permet aux utilisateurs de créer un compte de stockage qui leur permet d'utiliser le stockage d'objets binaires comme expliqué dans le paragraphe suivant, de monter des systèmes de fichiers distants basés sur Azure sur leur machine locale, de créer des tables de bases de données orientées colonne, ou de créer une file d'attente pour recevoir des données en continu d'un capteur. Cependant, il existe trois types de services courants que tous les fournisseurs de services infonuagiques proposent :

  • Le premier, le stockage de fichiers (file storage), gère les données sous forme de fichiers. C'est le service de stockage le plus courant parmi les nouveaux utilisateurs, car c'est le concept le plus facile à comprendre. La plupart des utilisateurs qui utilisent des ordinateurs quotidiennement sont familiers avec les fichiers et la façon dont ils sont stockés dans leur environnement local. Cependant, comme les fichiers ont tendance à augmenter en taille et que leur format peut devenir compliqué, le stockage de fichiers devient plus difficile à gérer à mesure que l'application fonctionne et se développe dans l'environnement infonuagique. La structure du système de fichiers peut également être reportée sur chaque fichier stocké dans ce service. Certaines métadonnées de fichier courantes qui sont gérées et suivies par le fournisseur de services infonuagiques sont le nom du fichier, la taille du fichier, l'horodatage et les permissions.
  • Le second, le stockage d'objets (object storage) (ou stockage de blobs), gère les données sous forme de blobs, chaque blob représentant n'importe quel format de données, comme un fichier dans un système de fichiers local. Un blob peut contenir n'importe quel type de données, comme une petite valeur, un document, une image, une vidéo ou une collection de ceux-ci. Les fournisseurs de services infonuagiques permettent l'accès aux informations stockées et à leurs métadonnées associées via une API/SDK ou via des liens web directs dans le cas d'images par exemple. Les métadonnées courantes incluent le nom, la taille, l'horodatage et les balises personnalisées. Dans certains cas, cette approche aide à gérer le stockage des éléments et les rend également accessibles à toute personne ayant accès à ceux-ci dans le nuage, ce qui n'est pas possible lors du stockage d'éléments de données dans un système de fichiers local. Ce service est couramment utilisé par les applications grand public et leur permet d'accéder et de récupérer des éléments de données en tant qu'objets en utilisant leurs noms et leurs balises.
  • Le troisième, le stockage par blocs (block storage), gère les données sous forme de blocs ou de plages physiques de stockage dans le périphérique physique (tel qu'un disque dur (hard disk drive) [HDD] ou Non-Volatile Memory Express [NVMe]). Chaque adresse de bloc peut varier de quelques kilo-octets à plusieurs méga-octets. Étant donné que ce service peut fournir un moyen à l'utilisateur d'accéder directement aux données en utilisant une adresse physique, il n'a pas besoin de gérer l'ensemble des objets de données. L'utilisation la plus courante de ce service serait une application système telle qu'un système d'exploitation ou une base de données où ils ont besoin d'accéder aux fichiers beaucoup plus rapidement, et ils peuvent suivre et gérer la façon dont les données sont modifiées.

Pour accéder aux services de stockage depuis l'application, le développeur aurait plusieurs façons d'accéder aux données. La Figure 13.2 montre une vue simple des différents modèles d'accès sur la façon dont l'utilisateur et l'application peuvent accéder au service de stockage.

Graphique montrant comment l'administrateur, le développeur et l'utilisateur accèdent à la passerelle API du nuage via la console/terminal, l'application, la console de contrôleur d'interface utilisateur web, puis à l'authentification/autorisation, au point d'accès au stockage et à l'interface de service, et au périphérique de données.
Figure 13.2 Comme le montre le diagramme, les utilisateurs et les applications peuvent accéder au service de stockage via différents modèles, y compris l'interface en ligne de commande (command line interface (CLI)). (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La plupart des fournisseurs de services infonuagiques fourniront différents outils pour prendre en charge les différents environnements que l'utilisateur peut utiliser pour accéder à son infrastructure et à ses services. Le service de stockage sera généralement fourni comme un emplacement dans le nuage auquel l'utilisateur peut accéder. Si l'utilisateur est un développeur, il peut accéder directement au stockage via son code en utilisant un kit de développement logiciel (software development kit (SDK)), qui est utilisé pour accéder au stockage nécessaire pour lire, écrire et stocker des données. Ce kit est généralement fourni par le fournisseur de services infonuagiques et fonctionne avec différents langages de programmation. Certaines applications exécutées dans l'environnement infonuagique utilisent également ce SDK pour écrire des données opérationnelles, telles que des journaux, ou consommer différentes configurations qui ont été stockées dans l'environnement infonuagique. Si un utilisateur est un administrateur infonuagique, il peut également accéder au service de stockage via un terminal informatique en utilisant l'interface en ligne de commande (CLI). Il s'agit également d'un outil fourni par le fournisseur de services infonuagiques, et cet outil permettra aux utilisateurs d'accéder au service de stockage et de gérer leurs données. Enfin, l'utilisateur peut également accéder au service de stockage via la console d'interface web via son navigateur. Ce faisant, l'utilisateur peut accéder à ses données de manière interactive via son navigateur. Généralement, les ressources infonuagiques sont disponibles soit via une interface de portail infonuagique, un SDK accessible par programmation, soit une CLI qui permet aux utilisateurs d'invoquer des constructions SDK en ligne de commande. La Figure 13.3 montre l'interface web d'un conteneur de compte de stockage Azure (alias blob) accessible via la console web du service de stockage d'objets Azure. Sur le nuage Amazon AWS, les blobs peuvent être créés comme des compartiments au sein de la solution de stockage simple (S3).

Capture d'écran de l'interface web d'un conteneur de compte de stockage Azure (VBlobs) accessible via la console web du service de stockage d'objets Azure.
Figure 13.3 Cette image de la console web du service de stockage d'objets Azure fournit un exemple supplémentaire de l'interface web utilisée pour stocker des conteneurs de données (c'est-à-dire des blobs) dans Azure au sein d'un compte de stockage. (Utilisé avec l'autorisation de Microsoft)

Un autre composant important du service de stockage infonuagique est le point d'accès au stockage (storage access point). Le point d'accès est l'un des composants critiques de l'architecture infonuagique qui minimisera la latence avec laquelle l'utilisateur peut consommer les données. En fonction de l'emplacement de l'utilisateur, le fournisseur de services infonuagiques peut fournir le point d'accès disponible le plus proche de l'emplacement de l'utilisateur pour éliminer les longues latences d'E/S. Cependant, c'est aussi l'un des problèmes clés de l'exploitation du service de stockage lorsque l'application est mise à l'échelle. Selon le fournisseur de services infonuagiques, il existe un nombre fixe de points d'accès dans une zone pour chaque compte à consommer. Habituellement, cela ne poserait pas de problème pour une application à petites ou moyennes performances. Cependant, pour les applications en temps réel et à haute performance, cette restriction peut devenir un goulot d'étranglement pour le bon fonctionnement de l'application. Ce problème peut être résolu lorsque l'utilisateur passe à une solution de nuage hybride (hybrid cloud) où il peut dépenser un peu plus au départ pour payer la sauvegarde des périphériques de données et du matériel qui peuvent être situés dans sa zone locale.

Services de calcul

Le service de calcul (compute service) offre à l'utilisateur la possibilité d'accéder à un environnement de calcul privé et constitue un autre composant d'infrastructure de base qu'un fournisseur de services infonuagiques devrait fournir. C'est également l'une des premières choses que l'utilisateur essaiera lorsqu'il commencera à utiliser les services infonuagiques. Cela offrira une expérience similaire à un service de calcul à distance qu'un utilisateur peut expérimenter dans son environnement local. L'utilisateur peut accéder à cet environnement pour développer ou exécuter toute tâche qu'il ne peut pas exécuter dans son environnement local. Les performances de ce service peuvent varier en fonction de la demande de l'utilisateur, ou elles peuvent être basées sur la façon dont l'application et les tâches sont requises pendant l'exécution. En fonction des spécifications du matériel informatique, du moment où elles doivent être exécutées et de la façon dont elles évoluent en fonction des demandes de l'application, l'utilisateur peut choisir parmi différents services. Voici trois services de calcul courants que l'utilisateur peut trouver chez un fournisseur de services infonuagiques :

  • Un service de calcul virtuel (virtual compute service (VCS)), qui permet à l'utilisateur de demander un environnement pour effectuer certaines tâches, puis de l'arrêter pour libérer la ressource au fournisseur de services infonuagiques. Selon le moment où il a été demandé et la durée pendant laquelle l'utilisateur le maintient en fonctionnement, le prix de ce service varie.
  • Un calcul ponctuel/non urgent (spot/not urgent compute), qui permet à l'utilisateur d'effectuer une tâche tout en maintenant les coûts bas en permettant au fournisseur de services infonuagiques d'exécuter la tâche sans urgence lorsque le moment est opportun et rentable.
  • Un service de calcul virtuel fonctionnel et sans serveur (virtual functional and serverless compute service), qui est une application exécutée dans l'environnement de calcul, est exécutée comme une fonction, puis arrêtée lorsque la tâche est terminée. L'utilisateur sera facturé en fonction du nombre de tâches ou de requêtes que le service effectue. Étant donné que ce service nécessite un service dorsal différent du fournisseur de services infonuagiques pour fonctionner, le coût par unité de temps pour ce service sera plus élevé que pour les autres services. Ce service est courant pour les applications d'architecture de microservices infonuagiques où l'utilisateur peut héberger différents composants et fonctions de son application en tant que composants distincts. Cela permettra à chaque composant d'être mis à l'échelle indépendamment et d'éviter un goulot d'étranglement pour une seule grande instance d'une application nécessitant une maintenance.

Comme pour le service de stockage, l'utilisateur peut avoir plusieurs façons d'accéder au service de calcul. Cependant, comme l'utilisateur doit interagir avec le service de calcul pour accomplir une tâche, il y accède généralement par deux canaux principaux : la CLI et la console de contrôleur d'interface utilisateur web. La Figure 13.4 montre comment les différents rôles d'utilisateurs peuvent accéder au service de calcul.

Graphique montrant comment l'administrateur/développeur et l'utilisateur accèdent à la passerelle API du nuage via la console/terminal ou la console de contrôleur d'interface utilisateur web, et puis à l'authentification/autorisation, au point d'accès au calcul et à l'interface de service de calcul virtuel, et à l'infrastructure virtuelle.
Figure 13.4 Le modèle d'accès pour un service de calcul peut différer selon le rôle de l'utilisateur. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Il est à noter que nous ignorons le modèle d'accès où l'utilisateur utilise un environnement de développement intégré (IDE) local pour accéder à l'environnement de calcul ou lorsque l'utilisateur accède à l'IDE hébergé dans l'environnement virtuel. Dans les deux cas, l'utilisateur doit configurer l'environnement de calcul différemment pour contourner les outils et interfaces fournis.

Un autre défi dans le service de calcul, similaire au service de stockage, est le nombre limité de points d'accès dans une zone ou un compte infonuagique que l'utilisateur peut utiliser. Cependant, ce n'est pas un défi aussi important que le calcul de stockage, car la plupart des tâches de calcul peuvent être planifiées, et il est plus facile de fournir un service de calcul minimal et de fonctionner avec des performances minimales qui fournissent un accès au stockage avec une latence d'E/S minimale. La latence d'E/S élevée peut détruire l'expérience utilisateur et peut se produire de manière imprévisible.

Services d'applications web et mobiles

Parmi toutes les applications et charges de travail dans le nuage, deux charges de travail courantes ont émergé ces dernières années. Ce sont les charges de travail web et mobiles où l'utilisateur souhaite fournir un accès en temps réel à tous les utilisateurs du monde entier. C'est l'une des raisons les plus critiques pour lesquelles l'utilisateur souhaite passer à l'environnement infonuagique, car le coût de mise à l'échelle de l'infrastructure mondiale est extrêmement élevé.

Un réseau de diffusion de contenu (content delivery network (CDN)) est une capacité infonuagique importante qui accélère l'accès aux charges de travail web et mobiles à l'échelle mondiale. Un CDN est un réseau de serveurs et d'infrastructures réseau associées qui est réparti dans le monde entier et permet l'accès aux charges de travail web et mobiles de n'importe où. Il est configuré pour prioriser et mettre en cache les données et contenus courants (par exemple, les vidéos) dans différentes zones géographiques afin d'augmenter les vitesses d'accès et de traitement des applications mobiles et web dans le réseau mondial, ce qui améliore l'expérience utilisateur et réduit les coûts énergétiques. Les services de streaming à la demande (par exemple, Netflix, Hulu, Tubi) utilisent des CDN pour diriger les utilisateurs vers le serveur le plus proche (c'est-à-dire un serveur de périphérie de réseau situé en bordure du réseau, plus proche de leur emplacement) à partir duquel ils peuvent diffuser leurs films. Les clients/applications web fournis par ces fournisseurs permettent le streaming adaptatif dynamique sur le Web (via le protocole web HTTP) pour assurer un streaming de contenu multimédia de haute qualité sur Internet, livré à partir des serveurs CDN. La Figure 13.5 montre une architecture de haut niveau de la configuration d'un CDN sur Azure Cloud Service.

Illustration d'utilisateurs accédant au serveur Edge depuis le serveur d'origine.
Figure 13.5 Le réseau de diffusion de contenu de Microsoft Learn sur Azure Cloud Service est configuré en utilisant une architecture de haut niveau. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

En dehors de l'infrastructure, le fournisseur de services infonuagiques fournit également d'autres modèles et services courants que la plupart des applications web et mobiles doivent utiliser pour offrir une expérience optimale au consommateur final. Ces modèles et services sont pré-implémentés et optimisés par le fournisseur de services infonuagiques et s'intègrent facilement aux services de calcul et de stockage où l'application s'exécute. Voici deux composants infonuagiques courants pour le web et le mobile :

  • Le composant qui stocke et gère les informations sensibles de manière sécurisée tout en permettant à l'application d'être mise à l'échelle et déployée dans différents environnements sur le nuage est la gestion des secrets et des configurations (secret and configuration management). Différents environnements nécessiteront différentes configurations et détails secrets, tels que l'accès à la base de données ou les paramètres linguistiques. La meilleure pratique pour gérer des configurations environnementales et des secrets complexes est d'utiliser un service infonuagique global pour injecter ces détails pendant l'exécution afin que le code de l'application puisse être exempt d'implémentation personnalisée et que le déploiement de l'application et la gestion de versions soient beaucoup plus simples. La plupart des fournisseurs de services infonuagiques permettront à l'utilisateur de gérer ses configurations et secrets personnalisés et de les mettre à jour pendant l'exécution de l'application.
  • Le composant qui permet aux développeurs de centraliser toutes les données de journalisation et de fournir une vue complète de tous les événements se produisant avec une application à tout moment est la gestion de la journalisation et de la surveillance (logging and monitoring management). À mesure que l'application se développe et s'adapte dans différents environnements, la capacité du développeur à connaître et à comprendre le fonctionnement de son application devient de plus en plus importante. La capacité de l'administrateur à identifier et à atténuer le problème pendant l'exécution est une exigence essentielle pour toute application basée sur le nuage. Pour cette raison, la plupart des fournisseurs de services infonuagiques fournissent des services de journalisation et de surveillance conjointement avec le service de calcul afin qu'ils puissent centraliser toutes les données de journalisation et fournir une vue complète de tous les événements qui se produisent avec l'application à tout moment. L'utilisateur peut tirer parti de ce service pour obtenir certaines capacités de surveillance prêtes à l'emploi lorsqu'il déploie son application dans l'environnement infonuagique. Cependant, en fonction des différentes applications et exigences, l'utilisateur peut étendre ces capacités en ajoutant une logique de journalisation personnalisée ou des configurations de notification pour répondre à ses besoins. La Figure 13.6 montre un tableau de bord de surveillance simple sur Azure Cloud Service.
Capture d'écran d'un tableau de bord de surveillance simple sur Azure Cloud Service.
Figure 13.6 Cette image fournit un exemple de tableau de bord de surveillance simple sur Azure Cloud Service. (Utilisé avec l'autorisation de Microsoft)

Services de gestion de conteneurs

Ces dernières années, les services de gestion de conteneurs (container management services), qui encapsulent une application avec les bibliothèques de système d'exploitation nécessaires à son fonctionnement, sont devenus l'une des innovations clés qui ont transformé l'utilisation des infrastructures infonuagiques. En un mot, le conteneur est un moyen d'encapsuler une application avec toute bibliothèque de système d'exploitation requise pour que l'application fonctionne. En utilisant un conteneur, le développeur ne se soucie pas de l'inadéquation environnementale entre l'environnement où l'application a été développée et l'environnement où l'application est exécutée. Ce conteneur peut être exécuté sur n'importe quel noyau Linux qui prend en charge l'exécution des conteneurs. La Figure 13.7 montre comment un conteneur s'exécute dans un environnement de calcul ordinaire. Il est également important de souligner que la technologie des conteneurs est différente de la technologie de virtualisation utilisée dans les machines virtuelles.

Illustration d'un conteneur avec le code d'application lié par une flèche vers le bas à la bibliothèque système, liée par une flèche vers le bas au noyau du système d'exploitation et au matériel (ces 2 éléments sont en dehors du conteneur).
Figure 13.7 Ce diagramme montre la vue de haut niveau du fonctionnement d'un conteneur dans un environnement de calcul ordinaire. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Dans l'environnement infonuagique, le service de gestion de conteneurs permet à l'utilisateur de déployer, d'exploiter et de mettre à l'échelle toute application conteneurisée. Il comprend également plusieurs composants nécessaires qui aident l'utilisateur à mieux gérer son application conteneurisée, tels que les suivants :

  • Le registre de conteneurs (container registry (CR)), ou le registre où l'utilisateur peut gérer les versions de chaque image de conteneur qu'il a déployée dans l'environnement infonuagique. L'utilisateur peut généralement gérer le conteneur en utilisant des métadonnées d'image telles que l'espace de noms, le nom de l'image ou les balises d'image.
  • L'image de conteneur de base (base container image), qui est la couche fondamentale d'un conteneur fournie par le fournisseur de services infonuagiques pour créer une application. L'image est généralement à jour avec des correctifs de sécurité et des packages qui permettent à l'utilisateur de mettre à jour son application avec la dernière mise à jour de sécurité.
  • L'environnement Kubernetes, ou service Kubernetes (K8S), qui est le système d'orchestration de conteneurs le plus populaire. Il s'agit d'un service géré qui est généralement fourni par le fournisseur de services infonuagiques pour permettre à l'utilisateur de mettre à l'échelle son application conteneurisée dans un environnement Kubernetes. L'environnement K8S est l'un des systèmes clés pour exécuter un environnement de nuage hybride (hybrid cloud) où l'utilisateur peut exécuter des applications à partir de son environnement local et infonuagique.

La Figure 13.8 montre un flux de travail simple pour déployer une application conteneurisée dans l'environnement Azure Cloud. L'architecture d'une solution de nuage hybride nécessite une solide expertise technique en développement d'applications et en applications conteneurisées, ainsi qu'une connaissance approfondie des solutions infonuagiques. Les détails sur la manière de le faire correctement ne seront pas abordés dans cette section. Cependant, la solution hybride devrait être l'objectif de tout utilisateur dans son parcours de migration de son application vers le nuage.

Boîtes connectées par des flèches : Créer un registre de conteneurs Azure (ACR) ; Créer un cluster Azure Kubernetes Services (AKS) et l'attacher à ACR ; Construire des images Docker et les publier dans le registre ACR ; Mettre à jour le manifeste Kubernetes (K8) ; Déployer l'application.
Figure 13.8 Sur Azure, K8S peut faire partie d'un flux de travail simple de déploiement d'applications conteneurisées. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Concepts en pratique

Conteneurs et machines virtuelles

Pour le déploiement, les organisations peuvent utiliser des conteneurs ou des machines virtuelles. Comment décider quelle technologie est la plus appropriée ? Les conteneurs offrent une plus grande extensibilité et sont pratiques si vous travaillez avec plusieurs environnements et que vous souhaitez empaqueter et exécuter vos applications de manière prévisible avec une répétition d'un environnement à l'autre. Les machines virtuelles (VM) offrent un meilleur contrôle de l'environnement et sont pratiques si vous avez besoin d'utiliser la même machine physique pour installer plus d'un système d'exploitation, ainsi que pour créer plus d'un environnement. Une autre considération est la vitesse de développement logiciel. Il est plus rapide et plus facile de construire et de tester de nouvelles fonctionnalités sur des conteneurs par rapport aux machines virtuelles. Cependant, les machines virtuelles offrent une meilleure sécurité. Bien qu'il y ait beaucoup à considérer lors du choix entre les conteneurs et les machines virtuelles, les deux technologies offrent des avantages importants, fournissant aux organisations des ressources critiques pour le déploiement.

Services de gestion de bases de données

Aujourd'hui, la base de données ou tout système de gestion de données est le cœur de toute application. Cependant, la gestion d'une base de données est généralement une tâche difficile car les données peuvent devenir surdimensionnées tant en taille qu'en complexité. Pour cette raison, la plupart des fournisseurs de services infonuagiques proposent plusieurs services de bases de données gérées pour toute application qui s'exécute à l'intérieur et à l'extérieur de l'environnement infonuagique. Il existe deux services de gestion de bases de données populaires :

  • Un service de base de données relationnelle (relational database service (RDS)), dans lequel la relation entre les données est strictement gérée. Les données peuvent être gérées selon un schéma de données prédéfini. C'est le type de base de données le plus courant que la plupart des développeurs connaissent. Quelques exemples populaires de ce type de base de données sont Oracle DB, MySQL ou PostgreSQL.
  • Une base de données NoSQL (NoSQL database), dans laquelle la relation entre les données n'est pas strictement gérée. Les données peuvent être gérées sous forme de paires clé/valeur. Ce type de base de données est devenu populaire ces dernières années avec les applications de surveillance où les données doivent être écrites et capturées rapidement. Quelques exemples populaires de ce type de base de données sont MongoDB Atlas et Cassandra DB.

Le modèle d'accès pour ces services est similaire à la façon dont toute application accède à toute base de données gérée. Différentes méthodes d'authentification et d'autorisation sécurisées peuvent être configurées via la CLI ou la console web par l'utilisateur et l'application peut accéder à la base de données depuis l'intérieur ou l'extérieur de l'environnement infonuagique.