Migration Big Data et Data Lake vers le Cloud

Est-il impératif de suivre tendance et de migrer ses données, workflow et infrastructure vers l’un des Cloud providers tels que GCP, AWS ou Azure ? Lors de la Strata Data Conference à New-York, un accent général a été mis sur le transfert des solutions Big Data des clients vers le Cloud. Voyons ce qui a été abordé dans les discussions de chaque fournisseur et ce qu’il faut considérer avant de faire sa migration.

Contexte et cycles de hype

Avant de plonger dans les promesses des vendeurs de Cloud et leurs pièges, je vais partager un peu le contexte dans lequelle cet article a été rédigé.

Depuis la fusion de Hortonworks et de Cloudera, peut-être même un peu plus tôt, le Big Data traditionnel on-premise connait un engouement à la baisse. Les entreprises ont commencé leurs Data Lake et leurs plates-formes analytiques et, vers 2015, le battage médiatique était au plus haut. La plupart des acteurs ont réalisé les coûts opérationnels inclus avec les technologies distribuées et ont commencé à chercher des moyens de les alléger pour se concentrer sur leur cœur de métier.

Les services Cloud ont commencé à être populaire et à faire parler d’eux dès le Big Data, mais ont d’abord été principalement conçus pour l’informatique à la demande et les applications simples et hautement disponibles (par exemple, les sites Web). Alors que le Big Data on-premise, en particulier Hadoop et les Data Lakes, est passé à l’étape de la “désillusion” principalement en raison des coûts opérationnels surdimentionnés, les fournisseurs de Cloud ont commencé à ajouter des services gérés Big Data à leur catalogue.

Ces deux facteurs, la chute du on-premise en raison de la complexité de l’infrastructure et de l’apparence des services gérés dand le Cloud, ont conduit à la tendance actuelle. La Strata Data Conference a débordé de discussions sur la migration d’une plateforme on-premise vers le Cloud et d’autres présentations de fonctionnalités basées sur le Cloud, tandis que le Big Data traditionnel était à peine couvert. En fait, la seule présentation Apache Hadoop à laquelle j’ai assisté a commencé sa première diapositive avec le titre “is hadoop dead”.

Les promesses du Cloud

Alors, que peuvent apporter les services Cloud à votre organisation ? Vous quelques uns des arguments de ventes servis par les éditeurs de solutions Cloud et leurs intégrateurs.

Élasticité de l’infrastructure : faites évoluer votre infrastructure en l’augmentant et en la réduisant pour l’adapter à vos besoins. Une nouvelle source de données alimente votre Data Lake et nécessite un stockage supplémentaire ? Pas de problème, S3/GC Storage/ADLS vous couvrent. Un nouveau cas d’usage intensif en calcul est apparu ? Provisionnez des instances GCP/EC2/Azure VMs en quelques secondes. Pour encore plus de flexibilité, utilisez un cluster kubernetes entièrement géré. Concentrez-vous uniquement sur ce qui compte et laissez le reste à votre fournisseur de Cloud.

Maintenance et mises à niveau : travaillez toujours avec les infrastructure et les logiciels les plus récents et les plus efficaces. Aucun temps d’arrêt requis pour la maintenance matérielle ou les mises à jour logicielles. Les correctifs de sécurité sont appliqués dès leur sortie et de nouvelles fonctionnalités sont régulièrement ajoutées au catalogue. Concentrez-vous uniquement sur ce qui compte et laissez le reste à votre fournisseur de Cloud.

Support expert : chaque service disponible est prêt à l’emploi, mais si vous avez besoin d’aide pour en tirer le meilleur parti, appelez un expert spécialement formé pour vous accompagner. Tout comme avec les plateformes, les fournisseurs de Cloud ont une équipe disponible et prête à vous aider à tout moment de la journée, de la nuit et des week-ends. Et comme toujours, ne payez que ce que vous utilisez. Concentrez-vous uniquement sur ce qui compte et laissez le reste à votre fournisseur de Cloud.

Support tiers : la plupart des leaders de produits technologiques spécialisés sont déjà intégrés aux plateformes, et les autres sont en cours d’accostage. Vous recherchez une plateforme d’analyse unifiée ? Toutes vos appliances sont unifiés sur une seule plateforme. Concentrez-vous uniquement sur ce qui compte et laissez la gestion à votre fournisseur de solutions.

Outils opérationnels : déployez, coordonnez, surveillez et automatisez votre infrastructure et vos applications via une seule CLI. Pour la reprise après sinistre, choisissez un plan multi-région. Pour planifier des tâches et des jobs, utilisez Azure Scheduler/Google Cloud Scheduler/AWS Batch. Si une fonctionnalité n’est pas encore disponible, vous pouvez l’implémenter grâce aux commandes gcloud/az/aws2. Concentrez-vous uniquement sur ce qui compte et assurez-vous que ce qui n’est pas encore disponible soit aussi simple que possible.

Bien que j’ai été un peu dramatique avec la formulation, ce sont quelques-unes des raisons pour lesquelles il vous sera proposé de migrer de votre plateforme historique vers le Cloud.

Réalité

Au cours de ma vie professionnelle, on m’a demandé de déployer et migrer des infrastructures Big Data vers le Cloud. Certains des avantages énumérés ci-dessus se sont révélé appropriés tandis que d’autres ne se sont pas déroulés comme prévu. Bien que j’ai principalement travaillé avec Microsoft Azure, je pense que les déclarations suivantes sont valables pour les autres fournisseurs de Cloud.

Élasticité de l’infrastructure : bien sûr, si vous utilisez des services managés. Ils sont par définition gérés par le fournisseur de cloud, et on s’attend à ce qu’ils puissent augmenter ou réduire l’échelle de votre infrastructure virtuelle en fonction de votre charge actuelle. Mais tous les cas d’usage ne sont pas adaptés aux services managés. De plus, certaines offres ne gèrent pas la mise à l’échelle automatique ou même la mise à l’échelle tout court. Par exemple, les migrations initiales de solutions Hadoop ont tendance à utiliser une approche lift-and-shift, utilisant le fournisseur de cloud uniquement comme un IaaS. Le stockage et le calcul sont directement liés aux machines virtuelles, et bien que la montée en puissance puisse être plus facile car il n’y a pas de problèmes matériels, la réduction des resources est aussi complexe que sur du on-premise. Autre exemple, la plupart des plateformes Big Data que j’ai rencontrées ont une charge de travail de calcul assez linéaire. Les infrastructures réservées ont tendance à coûter moins cher que celles à la demande. Il est donc souvent plus rentable d’utiliser une infrastructure réservée dédiée que son homologue géré.

Maintenance et mises à jour : cela est principalement vrai pour les infrastructures. La plupart des organisations avec lesquelles j’ai travaillé ont des équipes dédiées à ces tâches et sont souvent en retard par rapport aux versions matérielles et logicielles du Cloud. Gardez à l’esprit que les logiciels basés sur le Cloud sont cependant verrouillés sur quelques versions, et leur fin de prise en charge est parfois plus restrictive que le fournisseur natif. Certaines images personnalisées d’un de mes clients ont vu leur support d’infrastructure rejeté à cause d’eux.

Support expert : le support du fournisseur Cloud n’est pas tellement différent que celui mise en place pour une infrastructure sur site. Vous avez toujours besoin d’une équipe interne d’experts pour administrer le service Cloud que vous utilisez. Sur des plates-formes polyvalentes complexes comme celles-ci, il n’y a pas d’expert omniscient, même sur le Cloud.

Support tiers : les fournisseurs natifs spécialisés qui ont déjà intégré leurs offres avec les principaux fournisseurs de Cloud sont encore peu nombreux. Ceux qui sont disponibles sur les trois environnement encore moins. Mais la tendance est bel et bien là, et la situation pourrait devenir vraie dans un proche avenir. Pour l’instant cependant, vérifiez vos solutions et leurs intégrations avant de passer au Cloud, car cela peut être un facteur décisif.

Outils opérationnels : les fonctionnalités les plus avancées de la stack du Cloud. Depuis leur tout début, lorsque le DevOps était la principale utilisation des services Cloud, les fournisseurs ont perfectionné leur catalogue opérationnel. Maintenant que des plateformes plus complexes et des architectures distribuées cherchent à migrer vers le Cloud, ces outils ont été adaptés pour répondre également à leurs besoins. Bien que tout ne soit pas encore prêt, la plupart des tâches administratives peuvent être effectuées via l’un de leurs services. La CLI, pour Azure au moins, n’est cependant pas aussi complète qu’elle devrait l’être, et vous devrez souvent intervenir à l’échelle de chaque service individuel.

Avec le recul, le Cloud est en fait une bonne perspective pour votre hébergement informatique, mais pas pour les raisons les plus médiatisées. Le coût de l’infrastructure et la facilité de maintenance et d’approvisionnement associés à la juste utilisation d’outils adaptés à chaque usage sont les raisons les plus courantes pour lesquelles les entreprises se tournent vers le Cloud. Ces objetifs ne sont atteints qu’avec une préparation minutieuse, une bonne équipe d’administration Coud et des cas d’usage appropriés. Sinon, les résultats de la transition risque de n’être finalement pas plus pertinents que ceux des situations initiales. La richesse des outils d’exploitation est cependant un avantage instantané, presque entièrement prêt, qui ne se retrouve pas sur les architectures hétérogènes on-premise.

Autres considérations

Il y a d’autres aspects du Cloud à prendre en compte lorsque vous envisagez de migrer une architecture Big Data entière vers l’une des trois principales solutions.

Une idée fausse est que les outils offerts par les fournisseurs de Cloud sont conçus pour fonctionner les uns avec les autres, contrairement aux projets open source individuels comme ceux de la fondation Apache (ASF). Sachez que de nombreux services Cloud implémentent en fait un projet open source. Dataproc Component Gateway de Google est en fait Apache Knox, et la plupart des services AWS sont basés sur des projets open source Apache. Apache YARN et Kubernetes sont les principaux des outils d’orchestration pour vos tâches distribuées, Apache Spark est le moteur de calcul principal, et vous pouvez trouver d’autres solutions comme Apache Kafka derrière les services Cloud. Dans l’ensemble, les services Cloud ne sont pas garantis de fonctionner ensemble. Planifiez les fonctionnalités que vous allez utiliser avant de migrer et vérifiez leur compatibilité les unes avec les autres.

Les services Cloud ne sont donc pas toujours compatibles entre eux, et ils le sont encore moins avec d’autres composants externes. C’est par conception un anti-modèle que celui d’effectuer des tâches inter-cloud. Pour tirer parti des services multi-fournisseurs, il est recommandé de disposer d’une solution de gouvernance et de respecter la localité du Cloud (Cloud locality). Soyez également prudent lorsque vous intégrez des services on-premise à des services Cloud. Un exemple concret que je peux partager est l’outil de synchronisation AD d’Azure entre un AD local et son homologue géré dans Azure. Il a pour l’instant quelques fonctionnalités manquantes et une utilisation restrictive, bien qu’il s’agisse de deux produits Microsoft. La sécurité interne est particulièrement affectée par la compatibilité entre le Cloud et le on-premise. La plupart des fournisseurs ont désormais des fonctionnalités de type bring-your-own-key, mais assurez-vous de vérifier vos exigences de sécurité et qu’elles soient prises en charge par votre fournisseur de Cloud.

Bien que les services on-premise comportent plusieurs restrictions, les services Cloud présentent également de nouveaux problèmes. Par exemple, le modèle de cohérence S3 ne garantit pas à une lecture l’obtention du dernier état d’une donnée. Une conception supplémentaire doit être mise en œuvre pour obtenir une cohérence en lecture, comme l’écriture d’un fichier de journal des transactions avec des privilèges d’écriture verrouillés. Comme S3 est la solution de stockage principale sur AWS, des outils tiers sont parfois nécessaires pour couvrir des fonctionnalités absentes.

Comme illustré par le point précédent, l’utilisation des services Cloud implique une dépendance envers les solutions d’un fournisseur. Disons par exemple que vous avez choisi AWS pour S3 et EMR. Vous souhaitez utiliser un broker de message pour alimenter vos travaux EMR ? Utilisez soit SQS/SNS (alias [Apache ActiveMQ](https://activemq .apache.org/)), Kinesis (alias Apache Kafka), ou peut-être même ElastiCache (alias Redis). Pas de flexibilité pour utiliser RabbitMQ ou ZeroMQ nativement. AWS possède toujours la pile la plus complète, ces restrictions sont donc encore plus fortes sur Azure et Google Cloud.

Conclusion

La Strata Data Conference à New-York était très orientée entreprises et décideurs. Elle a fourni une vue intéressante de la tendance perçue dans le paysage du Big Data. Alors, devriez-vous migrer vos Big Data vers le Cloud ?

Premièrement, c’est un changement qui se produira éventuellement. Tout comme le Big Data, les technologies Cloud sont assez complexes et il faudra du temps pour y adapter vos équipes techniques et utilisateurs finaux. Il est préférable de commencer tôt avec des projets de faible importance pour comprendre les enjeux et acquérir les compétences adéquates avant que d’autres projets critiques n’apparaissent.
Deuxièmement, les plateformes Big Data hétérogènes avec un mélange de plusieurs solutions de fournisseurs ont créé un écosystème assez complexe. Donner un peu d’ordre à cet environnement en le plaçant dans une seule entité opérationnelle est une bonne chose.
Enfin, certains cas d’usage du Big Data sont mieux servis dans le Cloud. La séparation du calcul et du stockage offre un moyen plus flexible de gérer des tâches ponctuelles, comme les charges initiales. Il existe d’autres conceptions uniques que le Cloud permet de réaliser.

Les services Cloud ne sont cependant pas adaptés à tous les cas d’usages. Les éléments critiques en terme de sécurité devraient par exemple être conservés sur du on-premise. De plus, les fonctionnalités du Cloud ne sont pas encore toutes prêtes, et leur compatibilité les unes avec les autres et avec les composants externes fait encore extrêmement défaut.

Dans l’ensemble, je suggère d’essayer quelques solutions Cloud avec quelques projets sélectionnés pour apprendre les technologies, et de garder votre DataLake existant sur votre plateforme on-premise dans un premier temps.

Partagez cet article