Récemment, j'ai eu l'occasion d'interviewer Oren Eini, PDG et fondateur d'Hibernating Rhinos qui fournit RavenDB, un NoSQL open source orienté document conçu spécialement pour la plate-forme .NET/Windows.
Oren a plus de 20 ans d'expérience dans le monde du développement avec un fort accent sur l'écosystème Microsoft et .NET. Reconnu comme l'un des professionnels les plus précieux de Microsoft depuis 2007, Oren est également l'auteur de "DSLs in Boo:Domain Specific Languages in .NET". Il prend fréquemment la parole lors de conférences de l'industrie telles que DevTeach, JAOO, QCon, Oredev, NDC, Yow! et Progressive.NET.
Vous pouvez lire l'intégralité de l'interview ci-dessous :
Le principal problème, je crois, est simplement la taille même des données. Je ne parle pas nécessairement du Big Data et des complexités de la gestion d'un ensemble de données mesuré en centaines de téraoctets. Je parle du nombre de bases de données et de silos de données que vous avez dans une organisation. Étant donné que tout est numérique, vous disposez de fonctionnalités critiques pour l'entreprise qui résident dans une feuille de calcul Excel sur un lecteur partagé et de données historiques sur les achats des clients sur un serveur sur lequel personne ne veut s'approcher de peur d'en accepter la propriété.
Le simple fait de déterminer ce que sait l'organisation dans son ensemble peut être une tâche complexe. Les données qui passent entre les mailles du filet sont malheureusement courantes.
Les tentatives de création d'un référentiel centralisé pour l'ensemble de l'entreprise sont également vouées à l'échec. Différentes parties de l'entreprise ont des idées très différentes sur ce qui semble évident. Par exemple, le service Facturation a une notion très différente de ce qu'est un client que le service Marketing. Essayer d'adapter les données à un moule commun ne rend pas service à tout le monde.
La première étape consiste à définir, au niveau organisationnel, la propriété des données et les règles de responsabilité. Au niveau le plus élémentaire, la facturation possède le concept de tout ce qu'un client est dans un statut de paiement en retard et le marketing possède les intérêts d'un client. L'idée n'est pas de créer des silos d'informations dans l'organisation mais d'avoir une reconnaissance explicite des différents besoins. Une fois cela fait, vous pouvez définir le flux de données approprié dans l'organisation.
Le service de facturation mettra sa vision d'un client à la disposition du reste de l'organisation tout en conservant la liberté de modifier la façon dont elle est façonnée au sein du service.
J'utilise les services de facturation et de marketing et la notion de client comme exemple pour pouvoir parler d'abord de l'entreprise, ce qui est important. Pour le déplacer de manière un peu plus technique, on parle de contrats de services et de flux de données. Je vais vous renvoyer au mandat de Bezos et à la façon dont il a transformé Amazon. L'idée est simple :au lieu de traiter l'ensemble de l'organisation comme un tout unique, ce qui est presque impossible au-delà d'une certaine taille, traitez-la comme un groupe d'organisations coopérantes qui ont des frontières très claires entre elles.
Une fois que vous avez ces limites et que vous avez une bonne idée du flux de données dans l'organisation, vous pouvez faire venir vos plombiers et faire des choses comme rediriger le flux de données vers un emplacement central pour analyse.
Avoir de telles interfaces publiées aide beaucoup lorsque vient le temps de changer le comportement de certaines choses. Tant que le comportement externe est le même, nous sommes libres de modifier la façon dont nous le traitons.
Dans l'ensemble, la raison la plus courante du manque de sécurité dans les bases de données NoSQL est la négligence de l'opérateur. Je veux clairement séparer ici deux questions distinctes. Nous avons des bases de données NoSQL telles que Redis, dont le modèle de sécurité consiste explicitement à s'exécuter dans un environnement de confiance. Il existe quelques fonctionnalités de sécurité rudimentaires pour Redis, mais l'hypothèse générale est qu'elles ne sont destinées qu'à servir de troisième ou quatrième ligne de défense.
D'autres bases de données NoSQL, telles que MongoDB, devraient fonctionner sur des réseaux hostiles (c'est-à-dire Internet). Cependant, il est facile de configurer MongoDB sans aucune sécurité. À première vue, MongoDB est livré dans une configuration sécurisée, ce qui lui permet d'écouter uniquement la machine locale.
La toute première chose que vous trouverez en essayant de vous connecter à MongoDB à distance est un guide qui explique comment activer l'accès à distance à MongoDB, sans aucune sécurité.
Dans une certaine mesure, il s'agit d'une négligence de l'opérateur. Mais étant donné le grand nombre de bases de données MongoDB qui sont laissées ouvertes, je pense que cela coupe les cheveux. En Chine, une base de données MongoDB ouverte contenait plus de 200 millions de CV n'attendant que quelqu'un pour espionner ; une base de données mal configurée a exposé les portes dérobées de la Russie à plus de 2 000 entreprises.
Avec la sécurité, vous n'avez pas de seconde chance.
RavenDB, en revanche, refusera simplement de s'exécuter dans une configuration vulnérable. Vous pouvez exécuter RavenDB sans sécurité sur la machine locale, mais si vous essayez d'exposer la base de données à Internet sans les protections appropriées, la base de données renverra une erreur expliquant comment vous devez la configurer correctement.
Nous comblons le maximum de lacunes en supposant que la plupart des gens effectueront le minimum de travail requis et nous nous assurons que lorsque cela se produit, l'état final est bon, nous avons donc ce qu'il vous faut.
RavenDB fonctionne dans les systèmes de production depuis plus d'une décennie. Certaines des fonctionnalités les plus puissantes que nous avons remontent à notre version originale. La capacité à réagir dynamiquement à l'environnement opérationnel est la plus évidente. RavenDB analyse en permanence ce qui se passe (requêtes entrantes, charge du serveur, etc.) et réagit en modifiant l'allocation des ressources, les structures internes, etc. L'idée est qu'au lieu d'avoir un DBA à plein temps pour garder votre base de données, votre base de données peut gérer ses propres affaires.
Lorsque nous avons commencé à travailler sur RavenDB, nous voulions une base de données qui ait tous les avantages d'une base de données relationnelle (rapide, ACID, fiable) mais aucun des inconvénients (schéma rigide, maintenance continue, grande complexité).
Quand nous avons commencé, je n'avais aucune idée de l'ampleur de la tâche. Au cours des 10 dernières années, nous avons acquis une grande expérience dans la création d'une base de données qui peut fonctionner, sans que vous y prêtiez beaucoup d'attention. Nous avons conçu RavenDB pour nous faciliter la mise en œuvre des choses en mettant l'accent sur les performances. Un benchmark récent sur une machine Raspberry Pi (25 $, 1 GHz, 1 Go de RAM) nous a cadencé à plus de 5 000 écritures par seconde. Sur du matériel standard, nous pouvons atteindre plus de 100 000 écritures par seconde et plus de 1 000 000 de lectures par seconde.
Tout cela se trouve sur un seul nœud, mais RavenDB a été une base de données distribuée dès le départ. Cela signifie que vous pouvez configurer un cluster en quelques minutes (et le faire de manière sécurisée, bien sûr) et disposer d'un système hautement disponible et robuste.
Nous proposons des fonctionnalités uniques qui ne sont pas disponibles ailleurs. ETL est intégré à RavenDB et est largement utilisé par nos clients pour permettre un flux de données riche. Vous n'avez pas besoin d'assembler une solution à partir de pièces disparates, tout est là dans la boîte et ça marche.
La fonctionnalité d'abonnement est celle dont je suis particulièrement fier. Il vous permet d'effectuer une requête en cours. La base de données vous donnera initialement tous les résultats correspondant à votre requête. Étant donné que vous êtes toujours abonné à cette requête, votre base de données enverra tous les nouveaux documents correspondant à votre requête au fur et à mesure qu'ils seront saisis ou mis à jour pour répondre à cette requête. Cela vous permet de créer facilement des processus métier et des systèmes backend robustes.
Nous avons concentré beaucoup d'efforts pour faire de RavenDB une base de données multi-modèle capable de gérer des documents, des valeurs-clés, des données binaires, des compteurs distribués et des requêtes graphiques.
Vous allez voir beaucoup plus d'attention sur les bases de données multi-modèles. Au lieu de devoir déployer une solution dédiée pour chaque type de données que vous souhaitez et de gérer l'intégration complexe entre chacune des pièces, le marché évolue vers une solution intégrée qui peut offrir une suite complète d'options dans un seul boîtier.
Le cloud continuera d'être plus important, mais je ne serais pas pressé de dire au revoir aux systèmes sur site et distribués. Nous voyons beaucoup de nos clients effectuer des traitements en périphérie et sur des systèmes occasionnellement connectés. Je pense que vous verrez un changement d'orientation, où les centres de données du passé passeraient au cloud, mais une grande partie du traitement réel serait distribué à la périphérie et sur les appareils mobiles. Cela nécessite une manière différente de penser à la distribution des données et à la façon de pousser les données vers le cloud et d'extraire les données du cloud.
L'accent sera beaucoup plus mis sur le type de traitement de données distribué qui était autrefois la gamme exclusive des systèmes haut de gamme.
Il sera certainement très intéressant de voir comment le paysage change et comment nous construisons les outils et les méthodologies pour gérer la complexité et les fonctionnalités sans cesse croissantes.
