Depuis juillet 2020, Mark Porter est le chief technology officer de l’éditeur de base de données NoSQL MongoDB. Lors d’un récent passage à Paris, ce vétéran de l’industrie IT, passé par Oracle, AWS et la Nasa, nous a exposé sa vision du secteur des bases de données et du futur de la technologie MongoDB. Selon lui, la database doit prendre en charge l’analytique et le search et toute la plomberie de synchronisation avec les mobiles en réinventant ainsi le 3ème niveau des architectures à 3 niveaux.
LMI : Mark Porter, vous êtes impliqués depuis plus de 30 dans l’ingénierie informatique et les bases de données, vous avez travaillé pour Oracle, la Nasa, AWS, Grab… Comment décririez-vous les forces en présence aujourd’hui dans le secteur des bases de données ?
Mark Porter : Les développeurs ont toujours constitué une force très puissante dans l’industrie des bases de données. Cependant, pendant longtemps, c’étaient en fait les cadres exécutifs, les directions, qui prenaient les décisions pour leurs entreprises. Je pense que c’est terminé. Avec l’avènement du NoSQL au début des années 2000, les développeurs ont commencé à décider des technologies qu’ils voulaient utiliser, sans tenir compte des contrats que les dirigeants négociaient de leur côté. Et cela s’est avéré positif pour les entreprises que ce soit des experts qui prennent ces décisions. Maintenant, bien sûr, elles doivent choisir des technologies sécurisées, qui sont stables, au bon prix et dans le cadre de contrats bien négociés. Et donc, lorsque, nous en tant que fournisseur, les rencontrons, il y a ces deux dynamiques. Mais typiquement, de plus en plus, nous constatons que tout commence avec les développeurs, puis nos équipes commerciales travaillent avec l’entreprise à mesure que des cas d’usage sont mis en production avec nos solutions.
Et en termes de technologies utilisées, entre NoSQL et SGBD traditionnels ?
Je constate de façon générale que les gens optimisent pour que le développement soit prévisible et agréable. Cela signifie qu’ils cherchent à développer des architectures basées sur les microservices dans lesquelles les données sont protégées via des API. Ils ne construisent plus de bases des données monolithiques gigantesques basées sur des SGBDR avec 23 000 tables pour une seule application. Plus personne ne fait cela. Les délais de déploiement des projets ne se comptent plus en mois ou en trimestres, mais en jours, tout au plus en quelques semaines. Il faut donc faire en sorte que les choses soient simples pour chaque situation et complexes dans leur ensemble. Le travail de chaque développeur doit être simple, il doit pouvoir utiliser des technologies comme MongoDB, ou comme Confluent ou comme Databricks, qui leur permettent de faire leur travail facilement. Plus personne ne s’engage dans des technologies relationnelles complexes car le marché n’a plus de patience pour ces déploiements. Je parlais récemment avec le CTO d’une entreprise ayant une équipe d’ingénierie de 75 000 personnes. Il me disait que l’âge de ses développeurs sur les systèmes relationnels s’élevait de près d’un an chaque année et que les personnes recrutées à la fin de leurs études universitaires ne souhaitaient plus apprendre ces technologies. Mon fils est à l’université ; dans une assemblée où se trouvaient une trentaine d’étudiants, il a demandé combien d’entre eux utilisaient MongoDB, 18 ont levé la main. Je trouve particulièrement enthousiasmante cette montée en puissance de la technologie moderne au sein des effectifs.
Quels sont les points forts de MongoDB par rapport à ses concurrents ?
MongoDB est choisi pour les mêmes raisons que celles qui ont conduit nos fondateurs à créer la société en 2006 et 2007. L’une d’elles est la flexibilité du modèle orienté document. Et ce modèle n’existe dans aucune autre base de données bien que d’autres databases prennent en charge le format JSON et que certaines supportent même une fausse API MongoDB, aucune d’entre elle ne supporte la flexibilité sous-jacente du modèle document. Vous pouvez développer des applications plus rapidement en utilisant ce modèle. La deuxième technologie pour laquelle MongoDB est retenue, ce sont nos drivers avec lesquels vous pouvez développer dans le langage de votre choix. Nous supportons 14 langages différents et vous pouvez développer dans votre langage natif. Vous n’avez pas à assembler des chaînes de SQL ensemble, ce qui n’est pas naturel. C’est amusant. Cela a été développé en 2007, 2008, 2009 par MongoDB et ce sont toujours les raisons pour lesquels notre database est choisie aujourd’hui. Nous sommes également hautement disponible par défaut. Vous mettez en place MongoDB, vous avez trois noeuds, ils basculent quand quelque chose ne va pas dans le cloud ou sur site. Aucune autre base de données n’est hautement disponible par défaut. Cela se fait à travers un service cloud managé. C’est pour ces raisons que l’on nous choisit face à nos concurrents.
Sur quels critères les clients portent-ils leur choix sur l’une des versions du produit, Community, Enterprise, Atlas ?
De nombreux clients choisissent la version Community parce qu’elle est très facile d’accès. En 16 ans d’existence, il y a eu 240 millions de téléchargement. L’an dernier, ce logiciel open source a été téléchargé 100 millions de fois. En mars, nous avons eu 12 millions de téléchargements. Quand vous faites le calcul, cela signifie que non seulement les gens téléchargent MongoDB à un rythme insensé, mais aussi que le rythme de ce téléchargement progresse fortement et nous en sommes ravis. De toute évidence, des gens utilisent MongoDB Community et nous ne le savons même pas. Nous ne savons pas qui télécharge notre logiciel. Mais ensuite, ils décident de passer à un environnement de production et ils veulent utiliser MongoDB Enterprise, soit chez un fournisseur de services cloud, soit sur site. Et c’est alors qu’ils découvrent tout l’intérêt d’un service géré avec la version Atlas. Et s’ils veulent l’option serverless dans laquelle ils n’ont pas à spécifier le serveur utilisé, nous le proposons maintenant. Et il reste toujours possible de spécifier un choix dédié. J’aime à penser que nous avons quatre choix. Community, Enterprise Advanced qui a toutes les fonctionnalités de backup et de sécurité et tout ce que l’on attend d’une version Entreprise, mais dans une version on-premise, ou bien toutes ces mêmes fonctionnalités avec une capacité serverless, ou encore la même chose et plus, disponible dans notre capacité Atlas avec des fonctionnalités analytiques et de search, etc. C’est comme un menu à la carte dans lequel vous choisissez.
Toutes les fonctionnalités de MongoDB seront-elles disponibles en mode serverless ?
Oui. Pour l’instant, le serverless est en bêta et au fil du temps, les différentes fonctionnalités que l’on trouve dans le service cloud MongoDB seront de plus en plus disponibles en serverless. Sa disponibilité générale interviendra dans le futur à mesure que nous consoliderons le produit. Nous pensons que le serverless constitue le futur. Il y aura toujours des gens qui voudront provisionner leurs propres machines et d’autres qui ne le voudront pas. Et nous allons offrir ces deux façons de consommer MongoDB.
Est-ce que les fonctions serverless ne sont pas réservées à des workloads spécifiques ?
Actuellement, nous voyons que le serverless est utilisé pour certaines charges de travail, par exemple un workload qui transmet des données toutes les deux ou trois minutes ou bien, une charge de travail qui va être exécutée une fois par semaine, ou encore un workload qui peut prendre de l’ampleur ou se réduire de manière imprévisible et pour lequel on ne voudra pas payer pour le serveur. De plus en plus, nous pensons que les entreprises vont commencer à utiliser le serverless pour leurs applications de façon générale également. L’avenir est donc prometteur pour les deux types de mise en oeuvre. Pour certaines bases de données, on veut des capacités garanties, et pour d’autres, les capacités pourront monter en puissance et redescendre. Nous allons observer les clients et travailler avec eux pour déterminer ce qu’ils veulent.
En dehors du serverless, quelles sont les récentes et prochaines évolutions fonctionnelles de MongoDB ?
Parmi les plus récentes, il y a la capacité à traiter des séries temporelles au sein de la même base de données en même temps que les autres données. Il n’y a pas besoin d’un data store distinct. Lors d’une de ses récentes conférences, AWS a mentionné qu’ils avaient quelque chose comme 17 bases de données. Nous sommes catégoriquement opposés à cette approche. Nous croyons que, même s’il est bien de donner à chacun ses propres outils, cela ne fait que créer une charge avec le besoin de relier entre elles toutes ces bases de données. Et, au lieu de faire cela, nous pensons que nous pouvons tout réunir au sein d’une expérience agréable. Nous offrons aussi des capacités de traitement en colonnes pour les séries temporelles et nous allons continuer à offrir de plus en plus de capacités analytiques dans notre base de données principale. L’autre direction que nous prenons, et que nous continuons à améliorer version après version, c’est le search. Sur les appareils mobiles que nous avons tous sur nous, chaque application a une barre de recherche. Et donc, plutôt que d’obliger les gens à s’occuper de la recherche, de l’analytique et de la synchronisation avec les mobiles et à faire toute cette plomberie, nous prenons en charge le gros du travail indifférencié pour nos clients. Et nous pensons que c’est dans cette direction que va aller le marché des bases de données. Nous nous sommes dit, comment l’évolution va-t-elle se faire ? Dans les années 1980, ce qui remonte à loin pour beaucoup de vos lecteurs, nous avions une architecture à trois niveaux avec des applications clientes, des serveurs back-end et une base de données au 3e niveau. Ce que nous faisons, c’est renforcer l’importance de ce 3ème niveau qui ne peut plus être seulement persistant. Ce 3ème niveau doit prendre en charge les fonctions de recherche, l’analytique, il doit faire tout cela à la fois. La seule chose qui différenciait vraiment ce 3ème niveau dans les années 80 et 90, c’était qu’il ne pouvait jamais tomber. Et nous apportons ces engagements SLA d’entreprise à l’ensemble de ce 3ème niveau. Et pour être très direct, il n’est pas possible que chaque entreprise puisse créer la plomberie entre toutes les composantes de ce 3ème niveau tout en ayant ces 99,99 ou 99,999% de disponibilité et de fiabilité que nous pouvons fournir. Donc, c’est vraiment là que nous voyons le marché aller, c’est dans le développement de ce 3ème niveau pour qu’il devienne tellement plus que ce qu’il n’a jamais été.
Quels sont les principaux défis à relever pour les CIO, les CTO et les développeurs actuellement ?
Il est surprenant de constater que les problèmes auxquels font face les CIO et CTO en ce moment sont principalement d’ordre culturel. Il s’agit de s’adapter à un nouvel environnement de travail où les gens travaillent à distance et où les équipes doivent évoluer plus rapidement qu’elles ne l’ont jamais fait. Elles doivent être capables d’adopter de nouvelles technologies en toute sécurité psychologique. C’est pourquoi, quand je parle à des CTO et des CIO, ce n’est pas seulement de transformation digitale, mais aussi de la transformation culturelle qui consiste à communiquer avec leurs équipes, avec franchise, en fonction du contexte, et à créer une sécurité psychologique. Il y a cette phrase que les gens utilisent sur le fait d’accepter l’échec (« embrace failure »). Je ne sais pas ce qu’il en est en général, mais si en tant que cadre dirigeant, j’expliquais à mon conseil d’administration que j’ai « accepté l’échec », ils me répondraient probablement « d’accepter »… un autre emploi. Je n’accepte pas l’échec, j’accepte l’expérimentation. Et donc, ce que je fais et ce que je dis aux autres CIO et CTO c’est, qu’avant de démarrer un nouveau projet, ils doivent dire quels seront les résultats possibles de ce projet et ce qu’ils apprendront de positif et de négatif sur chaque type d’expérimentation. En s’y prenant ainsi, cela devient plus sûr pour eux d’essayer une nouvelle technologie, un nouveau passage à l’échelle. C’est ça le vrai problème que je vois et il ne s’agit pas de technologie. Si nous nous occupons bien des équipes, franchement, la technologie suit. Et je sais que c’est un peu surprenant de confier cela à un magazine IT. C’est avec cela que je vois les CTO et CIO se débattre aujourd’hui. C’est un changement culturel.
Cela m’amène à vous demander quels sont les outils collaboratifs utilisés au sein des équipes R&D de MongoDB ?
Nous pensons que les gens doivent pouvoir proposer des choses dans les documents. Je crois qu’Amazon parle de « writing ». Nous parlons de « writing ». Ecrire, c’est la meilleure façon de concrétiser la réflexion critique et ensuite, d’autres personnes peuvent examiner ce qui a été écrit. Et il y a tellement d’excellents outils mis à disposition par les fournisseurs de services cloud pour l’écriture collaborative et le développement collaboratif. Et lorsque vous les associez à des systèmes comme Jira et autres, vous pouvez constituer une équipe sans savoir en réalité où chacun se trouve. Et quand vous associez cela à des tableaux blancs au bureau qui s’interfacent directement avec Zoom, on ne parle plus de gens qui travaillent à distance. Nous unifions le terrain de jeu entre tous les écrans. J’interdis le fait de parler de personnes se trouvant sur place ou à distance. Nous intervenons tous sur le même terrain. Nous utilisons Slack, G Docs, tous ces outils. Et l’idée, c’est que chacun puisse contribuer à égalité et on peut utiliser les outils numériques pour le faire. Aussi, lorsque quelqu’un prend la parole dans une salle, nous disons souvent : « oh, oh, laissez l’écran parler en premier ». Et cela permet à tout le monde d’avoir la parole dans la salle.
Est-ce que toutes les applications sont éligibles pour s’exécuter sur une base de donnés managées comme MongoDB Atlas ?
La réponse est catégoriquement oui. MongoDB est approprié pour toutes les applications opérationnelles ou analytiques qu’il s’agisse d’un nouveau développement, d’une application disruptive ou d’une application qui transforme une infrastructure existante. Nous avons des clients dans chacune de ces catégories. Bien sûr, MongoDB fait partie des acteurs qui ont émergé, nous sommes le premier éditeur de base de données à être entré en bourse en 25 ans [ndlr : en octobre 2017]. C’est donc une question que l’on me pose toujours, quelles sont les applications pour lesquelles MongoDB est parfait ? Applications opérationnelles ou combinant opérationnel et analytique, absolument.
Un mot sur le recrutement chez MongoDB ?
J’ai récemment recruté d’éminents ingénieurs de sociétés telles qu’Amazon, Microsoft [SQL Server] ou Alibaba. Et la raison pour laquelle ces personnes décident de partir pour rejoindre MongoDB, c’est quelles voient, exactement comme je l’ai vu moi-même, les opportunités qu’offre MongoDB, parce que nous n’avons pas de technologie héritée, parce que notre technologie est ouverte et parce que nous possédons la pile technologique complète. Nous avons la capacité à produire la structure de données pour les terminaux et les applications que personne d’autre dans l’industrie ne peut produire. Je sais que c’est une déclaration très arrogante et très étendue. Mais je vous le dis, je ne serai pas chez MongoDB si je ne le croyais pas. De même que ces ingénieurs dont je vous parle, qui sont littéralement des ingénieurs phares de l’industrie, ne viendraient pas chez MongoDB s’ils ne croyaient pas également que c’est vrai.