Donnez du pouvoir à l'analyse de données évolutive partout grâce à une architecture cloud-native

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 de besoin métier — et ce, à grande échelle, avec une haute concurrence, performance, efficacité et disponibilité.

Des milliers d'entreprises dans des secteurs allant des services financiers et de l'assurance à la fabrication et à la santé constatent qu'elles ont besoin de cloud public et privé, hybride et de périphérie pour répondre au mieux à leurs besoins de gestion et d'analyse de données. Il n'est donc pas surprenant que le concept de cloud distribué fasse partie de la maturation du cloud. Apporter des entrepôts de données, des lacs de données et des analyses avancées à une architecture de cloud distribué est la direction que prennent les marchés. Étendre cette architecture pour englober des services de gestion et d'analyse de données de niveau supérieur mène naturellement à l'idée d'un cloud de données distribué. Au sein d'un cloud de données distribué, les entrepôts de données d'entreprise ne serviront pas seulement à fournir des analyses à quelques centaines d'analystes métier ou de data scientists dans une entreprise, mais pourront finalement alimenter des applications analytiques en temps réel utilisées directement par les clients finaux d'une entreprise, qui se comptent en dizaines de milliers. Les données seront immédiatement accessibles — et produiront des insights — n'importe où.

Voir aussi : Tendances d'adoption du cloud 2021 amplifiées en 2022

Explorer la destination

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

Pour être plus précis, une technologie de gestion et d'analyse de données cloud-native devrait afficher cinq traits clés pour s'aligner sur le plan du cloud de données distribué :

• Un runtime agnostique de plateforme permettant le provisionnement de données et d'analyses n'importe où
• Une expérience utilisateur commune n'importe où
• Des fonctionnalités communes de sécurité et de gouvernance sur toute cible de déploiement
• Efficacité des coûts et de la technologie n'importe où, minimisant les ressources et permettant une forte gestion des coûts (FinOps) et des garde-fous de dépenses
• Un plan de contrôle unique, reliant tous les déploiements : cloud public, sur site et en périphérie réseau

Déployable au point de besoin n'importe où, un entrepôt de données cloud-native pleinement réalisé suivant ce modèle abstrait également la complexité de l'infrastructure cloud, sur site et en périphérie réseau pour les utilisateurs finaux. Le but est de les libérer des détails d'infrastructure et de leur permettre de se concentrer sur la génération de valeur à partir de l'analyse et la gestion des données tout en conservant la puissance native du cloud.

Choisir le bon guide

Comment atteindre cette destination ? Kubernetes, l'outil open source d'orchestration de conteneurs, fournit le chemin le plus populaire vers les opérations cloud-native. Bien 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 environ une décennie que les conteneurs ont été largement mis en œuvre pour rendre le développement d'applications plus facile, plus portable et plus efficace en 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. Bien que d'autres options existent, le projet open source Kubernetes de Google, maintenant maintenu par la Cloud Native Computing Foundation, s'est imposé 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 de standards ouverts.

C'est bien pour les applications. Mais qu'en est-il du monde des données ? La même orchestration de conteneurs fondamentale est requise pour que les entrepôts de données cloud-native offrent élasticité et flexibilité de déploiement sur les clouds publics et privés, la périphérie réseau, le cloud hybride et les clouds entièrement distribués.

La réarchitecture cloud-native pour les applications web à échelle horizontale est courante, mais les bases de données ont mostly just been « liftées-et-déplacées » dans le monde cloud-native. Plonger une base de données dans un conteneur lui permet de s'exécuter dans une infrastructure moderne, mais n'offre pas une expérience qui démontre tous les avantages du cloud. Le logiciel ignore largement qu'il s'exécute dans un environnement conteneurisé, et des opérations telles que la gestion de clusters élastiques doivent être maladroitement gérées de l'extérieur de la base de données à la main en utilisant des Operators et en bidouillant des Helm charts. Des fonctionnalités telles que permettre à plusieurs clusters de calcul élastiques à la demande de partager les mêmes données sous-jacentes dans un stockage objet sont souvent indisponibles. Les utilisateurs cherchant à obtenir de la valeur métier d'un entrepôt de données cloud élastique ne veulent pas savoir sur les Helm charts, pods, nœuds ou fichiers de configuration. Ils veulent juste provisionner des entrepôts de données, gérer des clusters élastiques et obtenir des insights 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 DBAs et utilisateurs finaux est la réponse.

De cette manière, différents utilisateurs peuvent être affectés pour exécuter des charges de travail sur différents clusters de calcul, et le cluster de calcul en cours d'utilisation peut être modifié à l'exécution via SQL, sous réserve des autorisations. Les clusters peuvent être configurés pour se suspendre 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 quand nécessaire, un pour l'intelligence d'affaires (BI) ad hoc et plusieurs clusters de data science. Les clusters de calcul peuvent être étendus en ligne pendant les périodes de forte utilisation ou arrêtés pendant les périodes calmes pour économiser de l'argent. Les clusters peuvent être créés pour exécuter des tâches de reporting 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 de 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éplication à faible coût qui reçoit le trafic de réplication d'un entrepôt de données principal, lequel peut ensuite être mis à l'échelle à la demande lorsque la réplique doit être utilisée.

Ce type d'élasticité est mis en œuvre non seulement en s'intégrant profondément avec Kubernetes, mais en utilisant le SQL lui-même comme « interface utilisateur » pour créer, suspendre, reprendre et gérer les clusters au lieu d'outils de développeur. Kubernetes est la source de vérité faisant autorité pour l'état de tous les clusters. Les vues système affichant l'état des clusters tirent leurs données de Kubernetes en utilisant ses API. Lorsque des instructions SQL de gestion de cluster sont saisies, l'entrepôt de données cloud-native contacte Kubernetes pour changer l'état désiré d'une instance ; Kubernetes implémente alors les modifications nécessaires. Si un nœud du cluster devient défaillant, Kubernetes en met un autre 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, pilotées entièrement par SQL.

À mesure que plus de données sont générées et que 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'enfonce de plus en plus dans un cloud particulier. Des risques systémiques peuvent survenir dans ce cloud unique qui présente une exposition trop importante pour l'infrastructure informatique critique dans des secteurs fortement réglementés comme les services financiers et l'assurance. Architecturer avec Kubernetes n'est pas le seul concept de base qui donne vie à un entrepôt de données cloud-native pleinement réalisé. Ce n'est pas le seul composant architectural aligné avec le modèle de cloud de données distribué. Mais c'est la pièce maîtresse indispensable qui rend l'analyse de données exceptionnellement flexible, s'exécutant n'importe où au point de besoin métier — et ce, à grande échelle, avec une haute concurrence, performance, efficacité et disponibilité. L'avantage est que des milliers d'utilisateurs dans une entreprise donnée, à travers différentes lignes métier 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 quasi temps réel.