Dans la chronique précédente Hadoop dans le Cloud de cette série sur le Big Data dans le Cloud, nous avons défini le Cloud clairement. A titre de rappel, le Cloud Computing se définit simultanément sur deux axes : un axe économique et un axe technique. Sur le plan économique, le Cloud Computing c’est de la location (ou leasing) des ressources informatiques sous forme de service et sous la base d’une facturation à l’usage. Sur le plan technique, le Cloud c’est de la virtualisation de l’excédent de ressources informatiques d’un fournisseur IT. Dans cette chronique, nous allons continuer notre périple sur la transition du Big Data vers le Cloud. Plus concrètement, nous allons parler des modes de déploiement des technologies Big Data pour vos projets. Avant d’entrer dans le vif du sujet, vous devez savoir que pour déployer toute la stack technologique nécessaire pour valoriser vos données, vous avez le choix entre 2 modèles : le modèle de déploiement on Premise et le modèle de déploiement as a Service. Que ce soit l’un ou l’autre, la manière de mettre à disposition les logiciels et le matériel informatique aux mains des employés pour valoriser vos données aura un impact conséquent sur le budget de l’entreprise, et son niveau de contrôle sur son actif le plus précieux actuellement : la data.
Le modèle de déploiement On Premise
Avant l’avènement du Cloud, le mode de déploiement des logiciels et du matériel informatique était par définition le modèle On premise. Dans ce modèle (encore appelé modèle de déploiement on Site), le fournisseur IT (par exemple Dell, Microsoft, OVH) cède les droits d’exploitation de son produit (une ressource informatique telle qu’un logiciel ou un serveur) à l’entreprise qui l’acquiert sur une période donnée (sur 1 an, 2 ans, 3 ans par exemple) et facturent cette location ou cession sous forme d’une licence renouvelée généralement annuellement.
Caractéristiques du modèle de déploiement On Premise
#Caractéristique 1
Dans ce modèle, le client signe un contrat de licence logiciel ou contrat de leasing logiciel (Software licence agreement) qui indique les clauses régissant la cession du logiciel. Ce contrat peut prendre la forme d’un contrat papier daté et signé par les deux parties, mais dans la plupart du temps, c’est la forme d’une interface logicielle dans laquelle l’utilisateur coche un bouton radio indiquant qu’il a lu et accepte les conditions d’exploitation du logiciel.
Cette distinction entre vente et cession de logiciel, bien qu’elle passe inaperçue est très importante ! En effet, en cédant l’exploitation du SGBD plutôt qu’en le vendant, l’éditeur continue de conserver la propriété du logiciel, mais l’exploitation ainsi que tous les coûts qui s’en dégagent reviennent maintenant de la responsabilité de l’entreprise. En d’autres termes, le fournisseur n’a aucune obligation en dehors de celle de s’assurer que son logiciel ou matériel fonctionne normalement. Le fournisseur est également dégagé de toute responsabilité quant aux conséquences qu’engendrerait l’exploitation de son logiciel. C’est à l’entreprise de s’assurer du fonctionnement du logiciel, de mettre en place le processus, le management et les ressources humaines nécessaires pour faire fonctionner le logiciel et garantir les niveaux d’exigences (par exemple le niveau de disponibilité) qu’elle attend. Les éditeurs ou fournisseurs peuvent fournir du support pour faciliter ou accompagner l’entreprise dans l’exploitation de son logiciel, mais celui-ci est souvent offert comme service séparé et facturé différemment. Le transfert de responsabilité de garantie de niveau de service, du fournisseur vers le client est la première caractéristique principale du modèle de déploiement on Premise.
#Caractéristique 2
La deuxième caractéristique de ce modèle de déploiement est que le matériel informatique et les logiciels sont installés directement dans les locaux de l’entreprise. Chaque ordinateur correspond à un usage précis et n’est affecté qu’à cet usage. Cela signifie que pour n utilisateurs, il faut acquérir et déployer n PC. Les licences d’un logiciel sont vendues séparément pour chaque poste ou pour chaque utilisateur. Ainsi, si vous avez 10 postes, en faisant l’hypothèse fort probable que chaque poste est affecté un utilisateur unique, alors vous devrez acquérir un pack de 10 licences logicielles. Les licences attribuées aux utilisateurs sont dans la plupart du temps nominatives. Les logiciels sont offerts sous forme de CD ou de coffret avec leur clé de licence (et le nom de session de son utilisateur) rattaché dessus. Les licences ne peuvent donc pas être attribuées à d’autres utilisateurs le plus souvent, qui viendrait d’intégrer l’entreprise par exemple. Ceci signifie que la licence soit utilisée ou pas, elle est une charge fixe pour l’entreprise.
Comme vous pouvez vous en douter, le principal inconvénient de ce modèle de déploiement est qu’il génère un Coût Total de Possession (TCO) très important. L’entreprise peut rapidement se retrouver avec un parc informatique surdimensionné qui ne lui servira plus à grand chose (mais qui continuera à lui coûter de l’argent puisque les licences sont des coûts fixes sur toute une période du contrat) une fois que le projet pour lequel il a été acquis sera terminé. De plus, étant donné que c’est à l’entreprise d’assurer elle-même l’exploitation des ressources informatiques qu’elle acquiert, elle doit mettre en place les processus métiers et le management nécessaires pour le recrutement du personnel IT qualifié qui administrera ces ressources, la gestion de leur plan de carrière, les cotisations sociales, les salaires, bref, mettre en place des processus IT qui ne sont pas des processus qui sont au coeur du métier ou de l’activité principale de l’entreprise.
En partie, ce sont toutes les frustrations causées par ces problématiques qui ont motivé la création et l’adoption du second modèle de déploiement IT, le modèle de déploiement as a Service.
Déployer Hadoop et les technologies du Big Data On Premise
Pour déployer Hadoop ou n’importe quelle technologie Big Data selon le modèle On Premise, il existe deux moyens. Soit vous utilisez une distribution libre, soit alors vous faites l’acquisition d’une distribution commerciale.
Utilisation d’une distribution open source d’Hadoop
dans cette option, vous téléchargez simplement une distribution open source d’Hadoop librement, ensuite vous l’installez sur vos serveurs, et voilà ! Vous commencez à l’exploiter immédiatement pour vos projets. Vous n’avez aucun frais de licences logiciels. La distribution est dite « libre » ou « open source » parce qu’elle est développée et maintenue par une communauté active de développeurs physiquement distants les uns des autres mais fédérés par des organisations telle que la fondation Apache, GitHub, Hacker News, Stack Overflow ou encore la Free Software Foundation. Le logiciel est distribué sous un type de licence particulier appelée licence libre ou licence GNU GPL. Cette licence autorise n’importe qui à utiliser le logiciel (même commercialement), à modifier son code source et à le redistribuer librement. Le terme « distribution » ou « release » est utilisée pour faire référence à une version logicielle complètement développée. A ce jour, l’organisation qui fédère les développements de quasiment toutes les technologies du Big Data est la fondation Apache : https://hadoop.apache.org/ Il vous suffit d’aller sur ce site et télécharger la dernière release du logiciel Big Data dont vous avez besoin pour votre projet. Pour plus de détails sur les technologies qui composent l’écosystème Big Data, nous vous recommandons notre livre numérique gratuit « Initiation à l’écosystème Hadoop« .
Utilisation d’une distribution commerciale d’Hadoop
Le principal avantage de l’utilisation d’une distribution libre des technologies Big Data on Premise est l’absence des frais de licences. En effet, la distribution libre ne vous coûte pas un centime et vous bénéficiez gratuitement du haut niveau de réactivité des communautés open source en matière de correction de bug ou d’amélioration de la qualité des logiciels. Malheureusement, le problème avec ce modèle est que le grand nombre de communauté engendre souvent une multiplicité de licences et de versions de logiciels parfois incompatibles entre elles qui deviennent très vite difficiles à suivre. En entreprise, on a besoin d’une feuille de route, on a besoin de maîtriser les technologies qui forment le système d’information. Bref, on fonctionne sur la base d’une politique de gouvernance IT. Les releases en open source n’évoluent pas forcément selon une feuille de route commune à l’ensemble des communautés. Vous pouvez donc rapidement vous retrouver avec plusieurs releases du même logiciel développées par des communautés différentes. De plus, le plus souvent, les communautés de développement logiciel open source offrent peu ou pas du tout de support, d’accompagnement, ni de documentation sur l’utilisation des technologies qu’elles produisent ; elles se concentrent plus sur le développement que sur la rédaction de texte ou de tutoriels, faisant ainsi l’hypothèse que l’utilisateur de leur logiciel a le même profil que celui des personnes des communautés. Résultat, le logiciel open source est en général souvent moins convivial et moins exploitable. Ne perdez pas de vue que pour de nombreuses entreprises, le développement logiciel n’est pas leur cœur de métier. Elles ont donc rarement le profil en interne pour leur permettre d’exploiter ces technologies open source. En résumé, bien que l’open source soit libre, elle peut finalement s’avérer plus difficile à exploiter. Pour toutes ces raisons, les entreprises ont besoin de technologies dont l’évolution est plus maîtrisée, le code plus sécurisé, l’utilisation plus conviviale, le support plus développé et les compétences plus disponibles. C’est ce qui justifie l’utilisation d’une distribution commerciale d’Hadoop ou des technologies Big Data.
Ici, l’idée consiste à acquérir la solution technologique d’un éditeur logiciel. Bien évidemment, l’acquisition va se faire en mode on Premise, c’es-à-dire par cession des droits d’exploitation de la solution Big Data de l’éditeur. Les 2 avantages principaux de cette option sont la garantie de la fiabilité du logiciel et le support apportés par l’éditeur. Bien évidemment, les points faibles de cette option restent ceux du modèle de déploiement on Premise. Notez qu’il existe plusieurs types d’offres commerciales en matière de technologies Big Data ; certains éditeurs choisissent de concentrer leurs efforts de commercialisation sur une release open source précise d’Hadoop. Nous pensons notamment à Cloudera, Hortonworks et MapR, avec respectivement leur solutions CDH (Cloudera Distribution including Apache Hadoop), HDP (Hortonworks Data Platform) et MCP (MapR Converged Data Platform). Nous avons rédigé la chronique suivante pour vous aider à choisir laquelle de ces solutions choisir spécifiquement pour votre projet. Consultez-le en allant sur le lien suivant : https://www.data-transitionnumerique.com/cloudera-cdh-hortonworks-hdp-mapr-cdp-5-criteres-pour-choisir-votre-distribution-hadoop/
D’autres éditeurs ont plutôt choisi de développer leur solution autour d’Hadoop et de l’y intégrer horizontalement (Dataiku, Microsoft PowerPivot, Alteryx, Data Robot, etc.) ou verticalement. C’est l’exemple des solutions comme SAS HPA, IBM Big Insights, Dell EMC Pivotal Big Data Suite. Pour plus de détails sur ces offres, nous vous recommandons l’ouvrage « Maîtrisez l’utilisation des technologies Hadoop« .
ATTENTION !!!!
Lorsqu’un éditeur fait le choix de l’intégration verticale à Hadoop, généralement, il entre en partenariat avec l’un des éditeurs des distributions Hadoop. Ainsi, une solution intégrée verticalement à Hadoop est compatible soit à la distribution CDH de Cloudera, soit à la distribution HDP d’Hortonworks ou soit à la distribution CDP de MapR. Après, rien n’empêche l’éditeur d’entrer en partenariat avec les éditeurs des trois solutions ou de choisir les composants Hadoop qui vont constituer son offre directement depuis Apache. Reférez-vous à l’ouvrage « Maîtrisez l’utilisation des technologies Hadoop » pour plus de détails sur ces stratégies d’intégration.
Le modèle de déploiement as a Service
Le coût du matériel informatique a considérablement baissé. Il est passé en 1978 de 450 euros pour 1 GHz de processeur à 43 euros en 1985, à 2,5 euros en 1995. Aujourd’hui il est à moins d’1 euro. Cette baisse est intervenue au même moment qu’apparaissait un nouveau modèle de facturation des solutions logicielles, le modèle « Pay as you Go« , dans lequel le paiement annuel de licences d’utilisation d’un logiciel déployé sur les machines du client était remplacé par le paiement à l’usage d’un logiciel centralisé, et opéré directement par son éditeur. C’est ainsi que le Cloud est né que le modèle de déploiement as a Service a connu son essor. Concrètement, dans ce modèle de déploiement, la ressource informatique (logiciel ou hardware) est hébergé par l’éditeur et offert aux clients sous forme de service Cloud. Conformément aux principes d’exposition d’un logiciel que nous vous avons présentés dans la première chronique de la série, ce service cloud est exposé aux clients sous forme de service Web, leur accès est contrôlé par une API et leur exploitation fait l’objet d’une facturation fonction du volume de ressources utilisées, par exemple le nombre de requêtes HTTPS adressées à l’API par minute, le nombre de connexions par seconde, le nombre de commandes enregistrées par jour…etc. L’entreprise cliente s’abonne au service sans engagement (en théorie) et paye à l’usage. Elle peut se désabonner à tout moment si elle le souhaite, payant ainsi uniquement l’usage qu’elle a fait du logiciel. Ainsi, on passe d’un modèle essentiellement On Premise où le logiciel était installé directement chez le client et facturé à l’accès pour un modèle dématérialisé où le logiciel est hébergé par l’éditeur, utilisé sous forme de service et facturé à l’usage.
L’essor véritable du modèle de déploiement as a Service ne vient pas de la baisse des coûts informatiques, mais de la virtualisation. La virtualisation a permis d’optimiser l’usage des ressources informatiques en les partageant simultanément entre plusieurs utilisateurs, ce qui était impossible auparavant puisque chaque machine correspondait obligatoirement à une machine physique identifiée et réservée à un usage exclusif. Les licences étaient le plus souvent nominatives et affectées exclusivement à des utilisateurs précis. Le Modèle de déploiement as a service change la donne et transforme la consommation des ressources informatiques en l’accès à un vaste pool IT complètement facturé à l’usage. Les logiciels ne sont plus facturés par utilisateur mais par usage, sur la base de consommation globale du service cloud en fonction d’une métrique (par exemple, facturation globale en fonction du nombre de Go de stockage utilisé). Grâce à ce modèle de déploiement, les éditeurs peuvent transformer leurs applications du livrable On premise en services Web, mises à disposition de leurs utilisateurs au travers de terminaux connectés à Internet, selon la taxonomie IaaS, PaaS ou SaaS (cf. https://www.data-transitionnumerique.com/hadoop-dans-le-cloud/).
A la différence du modèle On Premise qui impliquait un transfert ou une cession des droits d’exploitation des ressources sur une durée fixe, dans le modèle as a service, il n’y’a aucun transfert de droit, l’éditeur conserve son produit, l’héberge et l’administre lui-même dans ses locaux. Par contre, il a maintenant la responsabilité d’assurer et de garantir le niveau de service attendu par l’entreprise. Le contrat signé n’est plus un contrat de leasing – software agreement, mais un Accord de niveau de Service (SLA – Service Level Agreement). Le SLA est un contrat, un document légal qui mentionne les niveaux de service ou les garanties de performance négociées entre le fournisseur et l’entreprise par rapport à sa solution. Ces garanties peuvent porter sur le niveau de disponibilité de sa solution, la restauration des données, la protection, les temps moyens de latence, la couverture juridique des données, etc. Comme tout document légal, le but est de protéger les deux parties en cas de conflits sur la gestion des niveaux de services. Les niveaux de service dans un SLA sont généralement définis définis par des indicateurs de performance (comme le nombre de pannes annuels, la latence moyenne sur 6 mois, etc.) et c’est un niveau attendu de ces indicateurs qui est négocié entre l’entreprise et le fournisseur. Le fournisseur garantit à l’entreprise que sa solution sera disponible à la métrique de l’indicateur négocié. Techniquement, la métrique utilisée pour mesurer les indicateurs qui quantifient les niveaux de service négociées par le client et le fournisseur dans un SLA s’exprime formellement en termes de nombre de « nines » (nombre de neuf), qui est le nombre de fois que le nombre 9 apparaît dans l’indicateur. Par exemple, supposons que l’indicateur négocié par le client et le fournisseur pour la solution dans le SLA est le niveau disponibilité (Availability) de la solution dans le temps. 3 « nines » signifie que le fournisseur devra garantir que sa solution sera disponible à 99,9% de temps dans l’année (c’est-à-dire une durée de défaillance maximale de 1 minute 44 secondes par jour). Ainsi, avec le SLA, l’entreprise a maintenant plus de contrôle sur la performance de ses ressources informatiques que dans le modèle de déploiement on Premise où elle devait elle-même recruter et gérer le personnel nécessaire pour obtenir les performances qu’elle attendait. Elle peut désormais louer les logiciels au moment où elle a le plus besoin sans se soucier de leur maintenance.
Intérêts du modèle de déploiement as a Service
Entre autre le retour sur investissement, le paiement de licence à l’usage du modèle de déploiement as a Service permet de couvrir les pics d’activité périodiques. En On Premise, les licences sont nominatives et tarifiées sur une durée fixe. Le modèle as a Service transforme les coûts IT d’une charge fixe à une charge variable, ce qui est plus intéressant car l’activité d’une entreprise est généralement cyclique et passe par des saisons de pic et des saisons de creux. L’entreprise peut louer temporairement des ressources pour gérer les pics de charge qui surviennent lors des périodes estivales comme les fêtes de fin d’année, une application qui va être mise en ligne pour soutenir une opération promotionnelle (Exemple : accès gratuit à toutes ressources documentaires de l’entreprise pendant 15 jours), une analyse métier réalisée tous les lundis, etc.
Autre intérêt, le modèle de facturation à la demande ou à l’usage diminue sensiblement le coût total de possession (CTO) tout en améliorant la disponibilité du logiciel, sa performance et sa sécurité, ce qui permet à l’entreprise de se concentrer uniquement sur ses activités métier. En effet, dans les autres modèles de facturation, l’installation On premise du logiciel entraîne automatiquement des tâches d’administration que l’entreprise doit rajouter comme activité supplémentaire. Or celles-ci sont des activités supports et n’apportent pas nécessairement une plus-value sur les profits de l’entreprise. Avec le modèle de facturation à l’usage, l’administration, la sécurité, le maintien de la performance et de la disponibilité du logiciel sont assurés par l’éditeur et y sont des processus métiers, non pas des processus supports ; ce qui assure automatiquement un service de qualité supérieure que lorsque celles-ci sont réalisées en interne. De plus, comme l’activité de l’entreprise passe par des phases de pic et de creux, celle-ci bénéficie de la flexibilité et de la prédictibilité nécessaires pour maximiser ses investissements.
Par contre, il faut faire attention ! Malgré les nombreux avantages alléchants du modèle de déploiement à l’usage du Cloud, cette option peut revenir à terme bien plus cher que si l’entreprise favorise l’utilisation des licences On premise ! De plus, l’utilisation de services web implique automatiquement le déplacement des données et leur hébergement chez le fournisseur, ce qui pose désormais de sérieux problèmes géo-stratégiques. Par exemple, l’Etat américain dispose d’une loi appelée le Patriot Act (et récemment il a introduit récemment la Cloud Act) qui l’autorise en cas de nécessité à investiguer les données hébergées dans le Cloud des entreprises américaines, indépendamment de la localisation de leurs data centers dans le monde. Il faut donc bien évaluer la maturité et la position du fournisseur Cloud sur ces sujets.
Déployer Hadoop et les technologies du Big Data en as a Service
Pour déployer Hadoop ou n’importe quelle technologie Big Data selon le modèle as a Service, vous devez simplement faire appel à un fournisseur Cloud qui met à disposition des instances de service Hadoop et vous acquérez le nombre d’instances dont vous avez besoin pour votre projet. Une instance de service Hadoop est la combinaison d’une instance de machine virtuelles et d’une distribution Hadoop (open source ou commerciale). Elle peut aussi être une combinaison des composants spécifiques d’Hadoop directement installés sur ces instances. Par exemple, vous pouvez acheter des instances Spark, qui correspondent à des instances de machine virtuelles avec des configurations précises sur lesquelles sont installées Spark, des instances Storm, des instances HBase, etc. Ces instances sont automatiquement organisées en cluster complet (Nœuds de données et nœud de référence), scalable, et tolérant aux pannes par le fournisseur Cloud, ce qui vous évite de vous préoccuper de la mise en place, et de la mise en service du cluster Hadoop vous-même. Ce cluster peut s’approvisionner automatiquement en ressources si la charge de travail venait à dépasser la capacité de calcul du cluster. L’équation suivante récapitule la composition d’une instance de service Hadoop.
Instance Hadoop = Instance de machine virtuelles à redimensionnement automatique + distribution/composant Hadoop + Object Store (optionnel)
Facturation de l’instance Hadoop = ressources des instances utilisées par période + composant Hadoop souscrit + volume de stockage souscrit (cas où il y’a eu souscription à un Object Store) ou Volume de débit de données transférées (cas où il n’y’a pas eu souscription à un Object Store)
ATTENTION !!! Par défaut, l’utilisation des instances de service Hadoop se fait sans persistance des données et celles-ci (les données) sont supprimées après le traitement. Chez la majorité des fournisseurs, le stockage fait l’objet d’une tarification séparée. Renseignez-vous directement auprès de votre fournisseur.
Actuellement, 3 acteurs majeurs fournissent les technologies Big Data selon le modèle as a Service : Amazon avec son offre Amazon EMR, Microsoft avec son offre Azure HDInsights et OVH. Reférez-vous au lien suivant pour des détails complets sur chacune de leur offre.
https://www.data-transitionnumerique.com/bigdata-dans-le-cloud-amazon-emr-vs-microsoft-azure-hdinsight/
Voilà ! Nous sommes arrivés au terme de cette chronique. Nous espérons que vous avez compris les modèles de déploiement des solutions technologiques en Big Data et que vous saurez les évaluer en fonction de la situation qui prévaut chez vous ou chez votre client. Si vous avez des questions par rapport à cette chronique, n’hésitez pas à nous les poser à contact@data-transitionnumerique.com.
Aussi, n’hésitez pas à diffuser cette chronique en la repartageant sur vos réseaux respectifs. Si vous souhaitez approfondir les sujets du déploiement du Big Data, nous vous recommandons notre second ouvrage :
