Comment vous prémunir contre un enfermement propriétaire, ou lock-in ? Cédrick Lunven, Developer Advocate chez DataStax, éditeur qui assure la distribution et le soutien d’une version pour l’entreprise de Apache Cassandra, livre son point de vue technique.
La sélection d’une plateforme pour votre application peut sembler extrêmement simple au premier abord. C’est pourtant d’elle que dépendent vos futures options de développement. Il arrive aussi que le choix d’un prestataire de services Cloud, d’un système d’exploitation ou d’un langage de programmation ne fasse pas forcément l’unanimité au sein d’une entreprise.
Afin de remédier à de telles situations, de nombreuses équipes de développement se penchent sur les containérisations et les microservices. Grâce aux conteneurs, il devient plus facile de déployer un logiciel, de supprimer des éléments superflus et de réduire la taille des livrables à leur strict minimum. La mise en place des conteneurs permet ainsi d’accroître la productivité des développeurs. Près de 57 % des personnes interrogées par 451 Research ont en effet cité la productivité des développeurs comme l’une des motivations fondamentales de l’adoption des conteneurs.
D’autre part, les microservices décomposent les applications en éléments élémentaires qui remplissent des tâches spécifiques. En utilisant ces composants plus agiles, il est possible de procéder plus facilement au scale-up ou au scale-down des applications. L’association des conteneurs et des microservices est cruciale pour les entreprises qui souhaitent se développer très rapidement en vue de répondre aux pics de demande des clients qui exigent un service immédiat.
Stratégies de Cloud hybride et multi-Cloud avec des conteneurs
Parallèlement à cette tendance en matière de développement d’applications, le rôle des infrastructures se modifie. De plus en plus d’entreprises adoptent en effet des stratégies de Cloud hybride et multi-Cloud afin de faire face à l’évolution de la demande que connaît le secteur informatique. Gartner avait déjà estimé que près de 70 % des entreprises adopteraient une stratégie multi-cloud d’ici à 2019, contre 10 % seulement en 2016.
Forrester Consulting a constaté une tendance comparable en 2018 : près de 60 % des entreprises ont déjà développé des applications de production sur le cloud public, principalement poussées par des raisons de performance commerciale et d’efficacité opérationnelle. Cette évolution rapide est dirigée par les développeurs qui souhaitent atteindre une plus grande flexibilité dans l’exécution et le déploiement de leurs applications.
Aujourd’hui, ce passage au Cloud hybride et au multi-Cloud est également motivé par la peur d’un lock-in (ou enfermement propriétaire). Tandis que les services de Cloud publics peuvent proposer une disponibilité de calcul, de stockage et de services considérable en un clin d’œil, de nombreux acteurs du secteur informatique se gardent bien, pour ainsi dire, de mettre tous leurs œufs dans le même panier. Pour les personnes qui s’appuient de façon excessive sur certains services spécifiques, il peut être dangereux de ne recourir qu’à un seul Cloud public. Ces services risquent en effet d’être modifiés ou supprimés à l’avenir. De même, les entreprises du secteur de la vente au détail et du commerce en ligne se méfient des services de Cloud publics proposés par l’un des principaux distributeurs à l’échelle internationale.
Les conteneurs ont été présentés comme un moyen d’éviter un tel lock-in. En isolant les composants des applications de l’infrastructure matérielle sous-jacente, toute image de conteneur devrait être à même de fonctionner sur n’importe quel service Cloud. Il s’agit de l’une des raisons qui expliquent la croissance de Docker, d’abord, mais aussi de Kubernetes, la plateforme open source de gestion de conteneurs et d’orchestration commercialisée par Google en 2014 et désormais développée par la Cloud Native Computing Foundation (CNCF).
Kubernetes propose une méthode efficace d’exploitation des conteneurs à grande échelle en automatisant de nombreuses étapes de gestion relatives à l’exploitation des clusters. En simplifiant l’orchestration des clusters et des pods de conteneurs, Kubernetes a rendu les applications basées sur les conteneurs plus faciles à exploiter et à gérer dans le temps. Elle a également relevé certains défis liés à la scalabilité des applications en vue de répondre à l’évolution de la demande, y compris dans des environnements hybrides ou multi-Cloud.
Plus important encore, divers Cloud publics supportent désormais Kubernetes et proposent également des services d’infogérance Kubernetes, ce qui facilite à la fois son déploiement et son abandon si vous décidez de changer de plateforme. En théorie, cette ubiquité est l’un des éléments qui permettent d’éviter un lock-in. Vous n’êtes pas satisfait de votre fournisseur de Cloud public actuel ? Il vous suffit de déplacer ces conteneurs chez un autre fournisseur, ou de travailler avec un autre service qui s’en occupera pour vous.
Ubiquité du service contre autonomie des données
Cependant, les conteneurs ne représentent que l’un des aspects de la plupart des applications modernes. Alors que de nombreux services peuvent exploiter des conteneurs, ils sont souvent sans état et ne sont pas utilisés pour le stockage et l’analyse des données. Plus les applications vivent, plus elles créent des données qui, au fil du temps, doivent être stockées et gérées.
Afin que l’application soit véritablement autonome, il est capital d’examiner dans le même temps les conteneurs et les données. Si vos conteneurs sont portables mais que vos données ne le sont pas, vous serez bloqué chez un fournisseur spécifique pour ce volet de votre application. De même, si vous êtes lié aux outils d’analyse ou de stockage des données d’un fournisseur de cloud public, il vous sera plus difficile de le quitter en cas de besoin.
Pour éviter une telle situation, il est essentiel d’examiner vos besoins en matière de gestion, de stockage et d’analyse des données. Allez-vous procéder à de l’Analytics à partir des données créées par vos applications ? Si oui, à quelle échéance après la création des données ? Votre objectif est-il d‘étudier des tendances historiques ou de prendre des décisions analytiques immédiatement ?
Pour certaines applications, une analyse historique, à froid, des informations stockées dans un data lake peut s’avérer suffisante. Cependant, pour la plupart des applications actuelles, les données doivent être utilisées dès leur création. Pour le commerce en ligne et les entreprises de vente au détail, les changements, tels que la personnalisation et la recommandation de produits, doivent intervenir au plus près de l’intervention client afin d’avoir une chance de réussir. S’il est intéressant d’obtenir une bonne recommandation après coup, cela n’aura sans doute pas d’incidence en termes de comportement par rapport à une réponse personnalisée donnée en temps réel.
De même, l’Analytics peut être basée sur différents modes de stockage des données. Les bases de données relationnelles, NoSQL et graphiques proposent diverses méthodes de traitement des données et d’obtention de renseignements à partir du volume considérable d’informations généré par les applications. Face à toute cette gamme d’options disponibles, il convient d’étudier comment ces différents modèles et bases de données peuvent être mis en œuvre parallèlement à votre application basée sur un conteneur ou directement en tant que conteneurs.
Si votre application repose sur une fonctionnalité précise de stockage ou d’analyse des données basée sur un service de Cloud public spécifique, vous devrez opter à terme pour ce service, que vous utilisiez des conteneurs ou non. Cette situation crée un élément de lock-in. Pour contourner ce problème, vos couches de données doivent pouvoir fonctionner à partir de différents sites ou fournisseurs cloud, à l’instar des conteneurs. Vous devez disposer d’une flexibilité suffisante pour déplacer des données depuis ou vers différents Cloud, lorsque vous le souhaitez, sans que cela ne modifie votre application.
Cette question comporte deux aspects. Premièrement, cette approche sans Cloud signifie que vous pouvez migrer entre l’infrastructure interne d’un centre de données et un fournisseur de cloud public, ou utiliser plusieurs services de Cloud publics si nécessaire. L’approche d’une « base de donnée Active Everywhere » devrait impliquer la même base de données ou le même service Cloud sur chaque plateforme. C’est le cas notamment d’Apache Cassandra, qui peut fonctionner sur divers Clouds ou dans des environnements hybrides. La nature distribuée de bases NoSQL masterless permet le déploiement de nœuds d’un même cluster sur différents Cloud et/ou sites. La réplication bidirectionnelle des données est assurée de manière transparente, et cela, même avec les bandes passantes faibles (WAN). Il n’est plus nécessaire de déplacer la donnée, elle est disponible au plus près des applications sur chaque Cloud et/ou sur site.
Cette approche permet de garantir que les données ne sont pas enfermées sur un Cloud spécifique, tout en bénéficiant également des avantages du Cloud en matière de performance.
L’autre possibilité consiste ici à utiliser plusieurs services Cloud afin de bénéficier de l’ensemble d’entre eux. Dans ce cas, le fait de disposer d’une base de données capable de fournir une seule structure de données sur différents Clouds vous permet de tirer parti des services spécifiques de chaque plateforme cloud. Par exemple, il pourrait être envisageable d’utiliser Azure IoT pour ingérer des données, puis décider d’utiliser Google Cloud Machine Learning pour traiter les données, et enfin stocker ces modèles et rapports sur AWS S3. Chacune de ces plateformes peut atteindre ses objectifs au sein d’une même application, tout en conservant son indépendance.
Conteneurs, données et échelle
Bien que les technologies de conteneurisation soient reines pour les composants sans état (dits stateless), leur transposition sur des applications nécessitant une persistance des données est possible mais moins évidente. L’accès aux volumes de stockage pourrait d’une part ralentir le système mais ce sont surtout la disponibilité et la consistance de la donnée en environnement distribué qui freinent la scalabilité dynamique (scale-up / scale-down).
Pour éviter ce phénomène de lock-in, sans recourir à la conteneurisation encore fragile, il est possible de se retourner vers les bases de données de type NoSQL : nativement pensées pour le Cloud et ses contraintes en terme résilience (commodity hardware), ces solutions peuvent être déployées chez tous les fournisseurs de Cloud et constituent une couche de données commune et cohérente entre plusieurs Cloud (multi-Cloud).
Les conteneurs représentent un excellent moyen de fournir des applications évolutives, capables de s’adapter à la demande des utilisateurs plus rapidement et plus efficacement que les infrastructures traditionnelles. Pour autant, l’adoption de conteneurs ne peut vous prémunir, à elle seule, contre un lock-in. Il convient également que vous analysiez l’ensemble de vos besoins applicatifs au fil du temps, depuis les conteneurs jusqu’à la gestion de données, en passant par l’Analytics et le stockage, puis que vous recherchiez comment exploiter ces différents éléments de façon indépendante. En faisant preuve d’anticipation, les développeurs peuvent aider leur entreprise à adopter de meilleures stratégies Cloud hybrides qui garantissent une certaine autonomie des données, empêchent les lock-ins et répondent aux besoins de « l’économie de l’immédiateté » dans laquelle l’ensemble des entreprises sont contraintes d’opérer.
