Le nouveau cloud privé vu par un architecte

Cet article a été initialement publié sur .

Pendant quelques années, le terme « cloud privé » avait une connotation négative. Mais comme nous le savons, la technologie est plus une roue qu'une flèche, et c'est exactement ce qui se passe : le cloud privé fait l'objet d'une attention considérable et tout cela est positif. Les statistiques sont claires : l'enquête 2023 de Forrester sur le cloud d'infrastructure a révélé que 79 % des 1 300 décideurs d'entreprise qui ont répondu ont déclaré qu'ils mettaient en œuvre des clouds privés. 94 % des responsables informatiques ont participé à un effort de rapatriement. Le vénérable IDC a constaté que 80 % des entreprises ont rapatrié une partie ou la totalité de leurs données dans l’année suivant leur transfert vers le cloud. Autant dire que le complexe industriel du cloud n’a « rien à voir ici… »

Les raisons sont diverses et nous allons les détailler, mais plus important encore, quelle est la bonne architecture à adopter ? Quels sont les premiers principes d'ingénierie du cloud privé ? Et enfin, comment concevoir pour répondre aux exigences de l'infrastructure de données de l'IA ?

Pourquoi le rapatriement vers le cloud privé

La principale raison pour laquelle les entreprises rapatrient est le coût. Elles économisent jusqu'à 70 % en rapatriant. Cela a été prouvé publiquement par des entreprises aussi diverses que , et .

La prévisibilité est un aspect connexe, mais pas identique. Les clouds privés offrent moins d’élasticité, mais une plus grande prévisibilité (nous abordons ci-dessous quelques astuces pour améliorer l’élasticité). Pour la plupart des DSI qui comprennent leurs charges de travail, ce compromis en vaut la peine. Pour les directeurs financiers, c’est un choix encore plus simple.

Les problèmes de sécurité viennent en troisième position. Cela ne veut pas dire que le cloud public est intrinsèquement peu sûr, ce n'est pas le cas. Cela signifie simplement que les RSSI ne font pas entièrement confiance à leurs partenaires de cloud public (en fait, la plupart des fournisseurs de cloud se réservent le droit d'examiner vos besoins) sur ce front. Les enjeux ne font qu'augmenter à l'ère de l'IA.

Dans le même ordre d'idées, le contrôle est au cœur de la liste de tous les DSI. Grâce aux économies de coûts, à la prévisibilité et à la sécurité, vous avez non seulement un contrôle total sur votre infrastructure de données IA, mais ces données sont également à portée de toutes vos applications, ce qui vous permet d'héberger vos modèles sur une infrastructure de données IA où vous et votre équipe pouvez définir des normes de sécurité en fonction de vos exigences de sécurité uniques, y compris l'accès physique.

La maturité est également un critère important. Le cloud moderne est un modèle d’exploitation, pas un lieu. Ce modèle, autrefois l’apanage exclusif des principaux clouds publics, est désormais omniprésent, de la périphérie au cœur. La conteneurisation, l’orchestration, les microservices, l’infrastructure définie par logiciel et les API RESTful sont des procédures d’exploitation standard. Peu importe où vous les exécutez, et si cela n’a pas d’importance, pourquoi payeriez-vous deux à trois fois plus cher ?

Les réglementations jouent également un rôle, notamment au fur et à mesure de leur évolution. Certaines architectures, certaines zones géographiques, certains scénarios de déploiement (militaires/renseignements) n'exigeaient pas de cloud privé au départ, mais c'est désormais le cas. Là encore, les raisons sont différentes, mais l’effet est le même. Le cloud privé est de nouveau à la mode. La question est : qu’est-ce qui a changé ces dernières années ?

Le modèle de conception préféré du cloud privé est le lac de données moderne

Comme indiqué ci-dessus, le cloud privé, comme le cloud public, fonctionne sur le modèle d'exploitation du cloud. Le cloud de périphérie fonctionne sur le modèle d'exploitation du cloud. La colocation fonctionne sur le modèle d'exploitation du cloud.

Ce modèle d'exploitation définit une certaine architecture et, à maintes reprises, cette architecture rend possible le data lake moderne. Il existe bien sûr d'autres architectures, mais l'utilisation du cloud privé pour créer votre data lake moderne permet aux organisations de ne payer que pour ce dont elles ont besoin. Lorsque leur activité se développe, la mise à l'échelle est aussi simple que l'ajout de ressources supplémentaires à un cluster. Une refonte n'est pas nécessaire. est pris en charge. —pris en charge. Analyse des journaux/analyse des menaces —pris en charge. — soutenu.

Un lac de données moderne est à moitié entrepôt de données et à moitié lac de données et utilise le stockage d'objets pour tout. La couche de stockage d'objets est définie par logiciel, évolutive, native du cloud et performante. Les performances sont réglables via la sélection de , qui sont facilement disponibles dans le commerce auprès de fournisseurs tels que Supermicro, Dell et HPE.

L'utilisation du stockage d'objets avec le lac de données est standard, son utilisation avec l'entrepôt de données est nouvelle, rendue possible par les formats de table ouverts (OTF) comme Apache Iceberg, Apache Hudi et Delta Lake. Il existe de nombreux détails sur cette architecture qui dépassent le cadre de cet article. Pour cela, je vous recommande de lire l'intégralité de Keith Pijanowski . Voici l'architecture :

Cette architecture est conçue pour offrir les éléments suivants, qui constituent tous des principes de fonctionnement de base du cloud et, par extension, des principes fondamentaux du cloud privé :

Hautes performances : alors que le cloud privé peut être conçu pour la capacité, le cloud privé moderne cherche à offrir des performances à grande échelle. Cette architecture privilégie les outils qui mettent l'accent sur la vitesse et l'efficacité. Comme le dit Jeff Bezos, qui veut payer plus et attendre plus longtemps pour l'obtenir ? Les mêmes principes s'appliquent ici : qui veut un cloud plus lent ?

Calcul et stockage découplés : la dissociation de ces composants offre une flexibilité et une évolutivité accrues, permettant à votre infrastructure, vos services et vos outils choisis d'exceller dans leurs domaines d'expertise respectifs.

Normes ouvertes : les normes ouvertes encouragent non seulement l'interopérabilité, mais elles assurent également la pérennité de vos investissements. Cela comprend non seulement les solutions open source, mais aussi les formats de table ouverts, comme nous le verrons. Ne créez pas de cloud privé avec un dispositif de stockage pour ces raisons (et parce qu'ils ne seront jamais natifs du cloud).

Compatibilité avec les API RESTful : l'interconnectivité est indispensable. Vos outils doivent partager un langage commun, S3 servant de lingua franca pour le stockage cloud. Pour cette raison, ne construisez pas votre cloud privé avec une solution centrée sur POSIX, même si elle prétend prendre en charge S3. Optez pour la vraie solution.

Piloté par logiciel/Infrastructure en tant que code : automatisez et laissez Kubernetes s'occuper d'orchestrer votre infrastructure, vous permettant ainsi d'abstraire les complexités de la gestion manuelle et d'assurer une évolutivité rapide et efficace.

Sécurité et conformité renforcées : les clouds privés offrent une infrastructure dédiée et un meilleur contrôle des données, ainsi que des mesures de sécurité renforcées. Cela est particulièrement avantageux pour les secteurs qui traitent des informations sensibles, comme la finance et la santé.

Conformité réglementaire : cette architecture peut prendre en charge la conformité réglementaire en fournissant des paramètres de sécurité personnalisables et des contrôles d'audit pour répondre à des normes sectorielles spécifiques.

Mettre votre cloud privé en jeu

Nous avons vu un certain nombre d'approches pour mettre en place un cloud privé. Toutes peuvent fonctionner. Cela dépend vraiment de l'entreprise et du cas d'utilisation.

• Un modèle hybride à durée limitée où certaines données et applications restent dans le cloud public tandis que le cloud privé est hydraté.
• Rapatriement complet du cloud public vers un cloud privé.
• Création d'un cloud privé sur un nouveau site. Cette solution est particulièrement populaire lorsque les entreprises mettent en production leurs expériences d'IA.
• Rapatriement des données de votre infrastructure de cloud public vers un déploiement de cloud privé existant. Bien que cette approche soit économique, elle présente certains inconvénients.
• La catégorie « autre » (bursting et tables externes).

Approche hybride à durée limitée : l'approche hybride à durée limitée transforme essentiellement le cloud public en stockage à froid et développe votre empreinte de cloud privé sur une certaine période (des mois/trimestres, pas des années). Cela implique l'achat et la configuration de votre infrastructure et de votre pile logicielle sur le cloud privé. Ensuite, vous orientez votre pipeline de données vers le cloud privé, et non vers le cloud public. Il peut y avoir une période pendant laquelle vous pouvez faire les deux. L'objectif, cependant, est d'utiliser le cloud public comme stockage à froid hiérarchisé et le cloud privé comme stockage à chaud. Au fil du temps, le cloud public passe du froid au gel tandis que le cloud privé devient le type de stockage principal et dominant.

C'est ce qu'a fait un acteur majeur de la cybersécurité. Il a commencé par mettre en place un cloud privé en collaboration avec MinIO et Equinix, puis a orienté dans cette direction le flux de données de 250 tebibytes (Tio) par jour. Étant donné que les analyses de logs ont une fonction de dégradation élevée en termes de valeur opérationnelle, il n'a pas fallu longtemps pour que le nouveau cloud privé devienne la principale source de données de chasse aux menaces. Ce cloud privé a atteint près d'un exaoctet (et franchira bientôt ce seuil) et la décision de déplacer ces charges de travail (en fait le cœur de métier) vers un cloud privé (avec des dépenses d'exploitation et non des dépenses d'investissement) a amélioré la marge brute de l'entreprise de plus de 2 %. En conséquence, cette entreprise a un multiple de valorisation qui fait l'envie de ses pairs.

Rapatriement complet : il y a des moments où conserver les applications et les données sur le cloud public et privé n’est pas une option. Dans ces cas-là, vous devez rompre avec votre fournisseur de cloud. C’est difficile, et même avec l’élimination des frais de sortie, ils rendent la situation pénible (les petits caractères indiquent essentiellement que tout doit disparaître pour obtenir un allègement des frais de sortie). C’est tout à fait faisable ; cela demande juste un peu plus de planification et un peu plus de frictions commerciales. Dans ce cas, provisionnez votre cloud colo ou privé et votre pile d’applications. Ensuite, sauvegardez le camion de données ou louez le réseau pour acheminer les données vers votre infrastructure de données de cloud privé. À ce stade, vous êtes libre, mais comptez payer le double pendant un mois ou deux si vous êtes du genre ceinture et bretelles. L’une des principales sociétés de streaming a adopté cette approche lorsqu’elle a quitté le cloud public. Elle a transféré un demi-exaoctet dans le nouveau cloud privé, y compris tous les films, émissions, documentaires, etc. Le processus a pris environ les trois quarts. Le gain a cependant été énorme et la complexité a été considérablement réduite pour l’équipe qui gère le service. Ils ont également profité de l'avantage supplémentaire d'un joli pop dans « « — une mesure clé dans l’espace.

Cloud privé Greenfield :

Il s’agit d’une proposition assez simple et elle implique généralement tout ce qui est nouveau. Le projet est nouveau, les données du projet seront nouvelles (ou presque) ou générées à partir d’une source qui arrive en ligne (comme une usine de fabrication géante ou un nouveau service de vidéo à la demande dans le cloud). Ici, vous dimensionnez la charge de travail — vous pouvez même la tester sur le cloud public — mais l’idée est qu’elle s’exécutera, dès le départ, sur le cloud privé. Nous le voyons assez fréquemment avec l’infrastructure de données d’IA. Les premières expériences se déroulent dans le cloud public. Les données ne sont pas si importantes. La disponibilité du GPU est assez bonne. Néanmoins, l’entreprise sait que la charge de travail doit être sur le cloud privé pour la production — à la fois pour l’échelle, mais aussi pour la sécurité, la confidentialité et le contrôle. L’un des principaux constructeurs automobiles au monde a récemment fait pivoter son initiative de conduite entièrement autonome d’un système basé sur des règles vers un système basé sur le comportement des conducteurs réels.

Ce comportement est « appris » à partir de millions et de millions de vidéos et de fichiers journaux provenant de ses véhicules. Bons conducteurs, mauvais conducteurs, conducteurs moyens. Pas seulement à partir de la vidéo, mais des autres éléments de télémétrie de la voiture tels que le freinage, l’accélération, le couple de direction, etc. L’approche ML basée sur des règles était à l’échelle des pétaoctets ; la vidéo est à l’échelle des exaoctets. L’entreprise ne partage ces données avec personne (en fait, deux des clouds publics ont des initiatives concurrentes). Cette charge de travail d’IA – plus de 300 serveurs – a toujours été une initiative de cloud privé.

Cloud privé Brownfield :

Soyons honnêtes : nous voyons cela, mais nous n'aimons pas ça. Cela inclut essayer d'exécuter des charges de travail hautes performances sur des disques durs pour superposer MinIO (réseau de stockage/stockage en réseau).

Cela fonctionne, mais c'est rarement la solution optimale. C'est économique (vous réutilisez le matériel), c'est peu contraignant (pas d'achat), mais c'est rarement performant. Néanmoins, nous l'incluons ici pour être complet. Cela soulève un point important. Lorsque vous concevez votre cloud privé, dans l'un des scénarios, prévoyez l'hétérogénéité. C'est une garantie et franchement, cela devrait faire partie du plan. Dans l'un des scénarios ci-dessus, la moitié du matériel provient de Supermicro. L'autre moitié de Dell. À mesure que le monde évolue et que de nouvelles technologies deviennent disponibles, votre logiciel ne devrait pas s'en soucier.

Les autres :

Il existe deux autres scénarios moins fréquents, mais qui devraient être pris en compte. L’un est l’approche hybride en mode rafale et l’autre l’approche des tables externes. Les deux sont liées à l’option hybride, mais peuvent ne pas être limitées dans le temps. Dans l’approche hybride en mode rafale, vous maintenez un cloud privé tout en le concevant pour qu’il s’étende de manière transparente, ou « éclate », dans le cloud public pour plus de flexibilité. Cette stratégie est souvent adoptée pour tirer parti de la capacité GPU supplémentaire ou pour utiliser des services cloud spécifiques. Dans ce modèle, certaines tâches sont temporairement transférées vers le cloud public pour traitement. Une fois l’analyse terminée, les résultats sont renvoyés vers le cloud privé, et les ressources du cloud public sont ensuite mises hors service. Nous avons un client majeur du secteur des services financiers qui effectue ces calculs de risque de crédit et de risque de marché. Il utilise le cloud public pour certaines opérations de calcul et le combine avec un lac de données de cloud privé qui utilise MinIO et Dremio. La beauté du modèle d’exploitation cloud est que l’architecture doit prendre en charge les opérations dans les deux endroits. Il s’agit en fait d’une voie à double sens.

À un moment donné, c'était une voie à sens unique, mais le monde a changé et les entreprises ont désormais la possibilité de faire des choix. Avec l'option des tables externes, les organisations peuvent toujours bénéficier des principes du modèle d'exploitation cloud en intégrant leurs entrepôts de données cloud existants, tels que Snowflake et SQL Server, à un lac de données construit sur le cloud privé. Cette configuration hybride permet aux entreprises de bénéficier des performances, de la sécurité des données et de la conception standard ouverte d'un lac de données moderne tout en capitalisant sur les investissements existants dans l'infrastructure cloud. Tous les principaux fournisseurs de bases de données proposent désormais la prise en charge des tables externes. Cette fonctionnalité permet aux utilisateurs d'interroger les données dans le stockage d'objets où qu'elles se trouvent, comme s'il s'agissait d'une table ordinaire dans la base de données, sans les tracas de la migration. Vos données restent dans le cloud privé, mais sont mises à disposition partout où elles sont nécessaires.

Réflexions finales et conseils

Nous avons été témoins de nombreux rapatriements/nouvelles versions de cloud privé au fil des ans. Une chose qui surprend les équipes est la nécessité de gérer à nouveau le matériel. Dans le cloud, c'est transparent. Les ingénieurs DevOps et de fiabilité du site n'interagissent avec l'infrastructure qu'au niveau de l'API. Si une machine virtuelle ne fonctionne pas correctement, nous la fermons et en la remplaçons par une nouvelle. Malheureusement, dans le nouveau cloud privé, plutôt que de simplement mettre au rebut le matériel et d'en acheter un nouveau, nous devons faire fonctionner le matériel existant.

La gestion de l'infrastructure est une chose. Elle fait partie du métier. Elle ne doit pas être effrayante, mais elle doit être planifiée. Il faut délimiter les responsabilités entre l'ingénierie logicielle/DevOps et l'ingénieur du centre de données. Ce PME (expert en la matière) dans les centres de données doit connaître les tenants et aboutissants de tout le matériel. Il sera responsable de tout ce qui concerne le matériel, y compris les pannes, les remplacements et toute maintenance.

Le logiciel est ici important. C'est pourquoi MinIO a intégré l'observabilité dans sa console globale. Dans le monde du cloud privé, vous devez exécuter des logiciels intelligents et du matériel stupide. Mais ce logiciel doit supporter la charge opérationnelle de cette manne économique. Les spécialistes du matériel ne pouvaient tout simplement pas créer la couche d'observabilité, MinIO a dû le faire. Si vous êtes une organisation qui déploie une fois par semaine, cela signifie que chaque déploiement est probablement un spectacle. En effet, avec des déploiements peu fréquents, il est difficile de prévoir et de corriger les bugs. Lorsque les déploiements ne se déroulent pas comme prévu, tout le monde doit se mobiliser. En général, le déroulement se présente comme suit :

• Concevez pour déployer votre application dans une configuration distribuée
• Testez-le dans votre environnement local
• Valider davantage dans un environnement Dev et Stage
• Ajoutez la surveillance, les métriques, le traçage et la modification
• Déployer des environnements sur site, hybrides et cloud

Lorsque ces principes CI/CD sont appliqués dans la pratique, un ingénieur de centre de données performant travaillant en étroite collaboration avec un autre ingénieur DevOps/SRE performant peut facilement gérer plus de 5 000 nœuds dans un cloud privé ou une installation de colocation. Nous avons des clients qui font exactement cela. Une fois que vous avez suivi les principes de base CI/CD, presque tout peut et doit être automatisé et les ingénieurs du centre de données et DevOps se concentreront uniquement sur les tâches qui ne peuvent pas être automatisées. Enfin, au cas où vous l'auriez manqué, les colos sont synonymes de notre définition du cloud privé.

La colocation offre un compromis entre une infrastructure entièrement sur site et le cloud public, offrant les avantages des deux mondes. Avec un accès à un réseau de premier ordre et une proximité avec les fournisseurs de cloud public, les colocations facilitent les connexions à faible latence et les configurations de cloud hybride, permettant un transfert et un traitement efficaces des données. Cette flexibilité et ce potentiel de déploiement réussi de cloud hybride sont essentiels pour les entreprises qui souhaitent optimiser leurs opérations et conserver un avantage concurrentiel. Pour en savoir plus sur le fonctionnement de ce système, consultez notre .