Le chemin natif du cloud vers les données n'importe où

L'architecture avec Kubernetes est la pièce maîtresse indispensable qui rend l'analyse de données exceptionnellement flexible, s'exécutant n'importe où au point où l'entreprise en a besoin, et ce à grande échelle et avec une simultanéité, des performances, une efficacité et une disponibilité élevées.

Des milliers d'entreprises dans des secteurs allant des services financiers et de l'assurance à la fabrication et aux soins de santé constatent qu'elles ont besoin de déploiements de cloud public et privé, hybrides et de périphérie pour répondre au mieux à leurs besoins en matière de gestion et d'analyse des données. Il n'est donc pas surprenant que le concept de cloud distribué fasse partie de la maturation du cloud. Amener les entrepôts de données, les lacs de données et les analyses avancées à une architecture cloud distribuée est la direction que prennent les marchés. L'extension de cette architecture pour englober des services de gestion et d'analyse de données de niveau supérieur conduit naturellement à l'idée d'un cloud de données distribuées . Au sein d'un cloud de données distribué, les entrepôts de données d'entreprise ne seront pas seulement utilisés pour fournir des analyses à quelques centaines d'analystes commerciaux ou de scientifiques des données dans une entreprise, mais pourront en fin de compte alimenter des applications analytiques en temps réel qui sont utilisées directement par la fin d'une entreprise. clients qui se comptent par dizaines de milliers. Les données seront immédiatement accessibles et fourniront des informations, où que vous soyez.

Voir aussi : Les tendances d'adoption du cloud en 2021 s'amplifient en 2022

Explorer la destination

Cloud-native est un terme souvent utilisé, mais il a un sens réel lorsque l'architecture logicielle est conçue à partir de zéro pour tirer parti des avantages du cloud distribué. Un entrepôt de données cloud natif entièrement réalisé devrait logiquement tirer parti d'une architecture de cloud de données distribuée. Dans les termes les plus larges, cela apporte l'analyse aux données où qu'elles se trouvent (et non l'inverse), atténue le risque de concentration, augmente considérablement l'efficacité et inaugure la modernisation pour des dépenses contrôlées et un avantage concurrentiel.

Pour mettre un point plus précis, une technologie de gestion et d'analyse de données native dans le cloud doit afficher cinq caractéristiques clés pour s'aligner sur le modèle de cloud de données distribuées :

• Un environnement d'exécution indépendant de la plate-forme permettant de fournir des données et des analyses n'importe où
• Une expérience utilisateur commune partout
• Fonctionnalités de sécurité et de gouvernance communes sur n'importe quelle cible de déploiement
• Efficacité des coûts et de la technologie partout, minimisant les ressources et permettant une solide gestion des coûts (FinOps) et des barrières de sécurité
• Un plan de contrôle unique, reliant tous les déploiements, cloud public, sur site et à la périphérie du réseau

Déployable partout où vous en avez besoin, un entrepôt de données cloud natif entièrement réalisé suivant ce modèle éliminera également la complexité de l'infrastructure cloud, sur site et en périphérie du réseau pour les utilisateurs finaux. Le but est de les libérer des détails de l'infrastructure et de leur permettre de se concentrer sur la création de valeur à partir de l'analyse et de la gestion des données tout en continuant à transmettre la puissance native du cloud.

Choisir le bon guide

Alors, comment cette destination est-elle atteinte ? Kubernetes, l'outil d'orchestration de conteneurs open source, fournit le chemin le plus populaire vers les opérations cloud natives. Alors que l'idée de partitionner les charges de travail sous Unix existe depuis les années 1970, ce n'est qu'il y a une dizaine d'années que les conteneurs ont été largement mis en œuvre pour rendre le développement d'applications plus facile, plus portable et efficace dans l'utilisation des ressources. Mais déployer des centaines ou des milliers d'applications sur une vaste architecture de microservices s'est avéré extrêmement délicat. Alors que d'autres options existent, le projet open source Kubernetes de Google, désormais géré par la Cloud Native Computing Foundation, a pris de l'importance pour résoudre l'orchestration d'applications de microservices, permettant aux applications de s'exécuter sur une infrastructure générique, d'être surveillées et gérées de manière standard, et d'être authentifiées à l'aide normes ouvertes.

C'est tant mieux pour les applications. Mais qu'en est-il du monde des données ? La même orchestration de conteneurs de base est requise pour les entrepôts de données cloud natifs afin d'offrir élasticité et flexibilité de déploiement sur les clouds publics et privés, la périphérie du réseau, les clouds hybrides et entièrement distribués.

La réarchitecture native du cloud pour les applications Web évolutives est monnaie courante, mais les bases de données viennent pour la plupart d'être "levées et déplacées" dans le monde du cloud natif. Le placement d'une base de données dans un conteneur lui permet de fonctionner dans une infrastructure moderne, mais il n'offre pas une expérience qui démontre tous les avantages du cloud. Le logiciel ignore en grande partie le fait qu'il s'exécute dans un environnement de conteneurs et que des opérations telles que la gestion de clusters élastiques doivent être maladroitement gérées manuellement depuis l'extérieur de la base de données à l'aide d'opérateurs et de hacks Helm charts. Des fonctionnalités telles que l'autorisation de plusieurs clusters de calcul élastiques à la demande pour partager les mêmes données sous-jacentes dans le stockage d'objets sont souvent indisponibles. Les utilisateurs qui cherchent à obtenir une valeur commerciale à partir d'un entrepôt de données élastique basé sur le cloud ne veulent pas connaître les graphiques, les pods, les nœuds ou les fichiers de configuration Helm. Ils souhaitent simplement provisionner des entrepôts de données, gérer des clusters élastiques et obtenir des informations à partir de leurs données.

Fournir une interface SQL sur Kubernetes pour provisionner plusieurs clusters élastiques à la demande et masquer les complexités de Kubernetes aux DBA et aux utilisateurs finaux est la solution.

De cette manière, différents utilisateurs peuvent être affectés à l'exécution de charges de travail sur différents clusters de calcul, et le cluster de calcul utilisé peut être modifié lors de l'exécution via SQL, sous réserve d'autorisation. Les clusters peuvent être configurés pour s'arrêter automatiquement après une période d'inactivité et redémarrer à la demande. Par exemple, un cluster de calcul distinct pourrait être créé pour exécuter des processus ETL en cas de besoin, un pour l'informatique décisionnelle (BI) ad hoc et plusieurs clusters de science des données. Les clusters de calcul peuvent être étendus en ligne pendant les périodes d'utilisation intensive ou désactivés pendant les périodes calmes pour économiser de l'argent. Des clusters peuvent être créés pour exécuter des tâches de génération de rapports par lots quotidiennes, hebdomadaires ou mensuelles qui ne sont actives que pendant ces périodes. La taille des nœuds dans le cluster de calcul, ainsi que le nombre de nœuds, sont contrôlables dans ce modèle, et des limites sur la consommation de ressources peuvent être établies au niveau de l'instance pour la prévisibilité. De même, il est possible de configurer un système de réplica à faible coût qui reçoit le trafic de réplication d'une instance d'entrepôt de données principal, qui peut ensuite être mis à l'échelle à la demande lorsque le réplica doit être utilisé.

Ce type d'élasticité est mis en œuvre non seulement en s'intégrant profondément à Kubernetes, mais en utilisant SQL lui-même comme "interface utilisateur" pour créer, suspendre, reprendre et gérer des clusters au lieu d'outils de développement. Kubernetes est la source de vérité faisant autorité pour l'état de tous les clusters. Les vues système montrant l'état des clusters tirent leurs données de Kubernetes à l'aide de ses API. Lorsque des instructions SQL de gestion de cluster sont saisies, l'entrepôt de données cloud natif contacte Kubernetes pour modifier l'état souhaité d'une instance ; Kubernetes implémente ensuite les modifications nécessaires. Si un nœud du cluster devient défectueux, Kubernetes mettra un remplacement en ligne.

Cela représente une relation unique, de l'intérieur vers l'extérieur avec Kubernetes :plutôt que Kubernetes soit l'« interface utilisateur » pour piloter l'état du cluster, la base de données elle-même, qui est gérée par Kubernetes, devient l'interface utilisateur. Cette architecture crée une relation symbiotique qui offre une expérience cloud unique et pleinement réalisée. La puissance et la flexibilité multiplateforme de Kubernetes deviennent disponibles pour un entrepôt de données, entièrement piloté par SQL.

Au fur et à mesure que de plus en plus de données sont générées et que de plus en plus de cas d'utilisation sont déployés, il est facile pour les entreprises d'entrer dans un cercle vicieux où leur écosystème s'enracine de plus en plus dans un cloud particulier. Des risques systémiques peuvent survenir dans ce cloud unique qui présente une trop grande exposition pour l'infrastructure informatique critique dans des secteurs fortement réglementés comme les services financiers et l'assurance. L'architecture avec Kubernetes n'est pas le seul concept de base qui donne vie à un entrepôt de données cloud natif entièrement réalisé. Ce n'est pas le seul composant architectural aligné sur le modèle de nuage de données distribuées. Mais c'est la pièce maîtresse indispensable qui rend l'analyse des données exceptionnellement flexible, s'exécutant n'importe où au point où l'entreprise en a besoin, et ce à grande échelle et avec une simultanéité, des performances, une efficacité et une disponibilité élevées. Le résultat est que des milliers d'utilisateurs dans une entreprise donnée, dans différents secteurs d'activité et régions géographiques, peuvent prendre des décisions extrêmement rapides et générer de la valeur à partir d'analyses en mouvement en temps quasi réel.