Nous sommes allés à MongoDB World 2022, pour que vous n'ayez pas à le faire !

J'ai assisté à MongoDB World 2022 la semaine dernière grâce à un parrainage de Linode. Dans cet article, je décrirai mon séjour ainsi que des extraits de code sur lesquels je travaille en vue d'un prochain tutoriel. J'ai également créé une vidéo récapitulant mon séjour à MongoDB World.

Mon résumé en 240 caractères :

MongoDB World m'a convaincu que je devais utiliser MongoDB plus souvent. Le public cible était probablement plus les managers que les développeurs car la plupart des conférences (y compris la mienne) n'allaient pas dans la profondeur technique que les développeurs apprécient souvent. Je recommande d'y assister !

Localisation : New York City

L'emplacement du Javits Center était parfait et le lieu magnifique. Pour une conférence, une ville comme NYC est exactement le type d'énergie dont vous avez besoin. Il se passe tellement de choses à l'extérieur que cela se répercute naturellement sur la conférence.

Note : 9/10

Discours d'ouverture

Pour lancer l'événement, nous avons entendu le PDG de MongoDB, Dev Ittycheria. Si je n'avais entendu que le discours de Dev, j'aurais été convaincu d'utiliser MongoDB beaucoup plus souvent. Dev a renforcé l'idée que MongoDB existe pour aider les équipes à produire plus avec moins, et cela s'est avéré vrai pendant toute la durée de la conférence.

Dev a été rapidement suivi par un autre présentateur qui a vraiment pompé l'énergie de la salle. Le sentiment était palpable. Dev est revenu sur scène pour redonner l'énergie nécessaire juste avant le début des sessions en petits groupes.

Nous avons également eu quelques démonstrations en direct au cours de la conférence, qui ont mis en évidence certaines des merveilles de MongoDB. Comme vous pouvez l'imaginer, les démonstrations en direct sont souvent la recette d'un désastre, mais celles-ci se sont déroulées sans problème, pour autant que je puisse en juger.

Dans l'après-midi du premier jour, le directeur technique Mark Porter a donné l'une des meilleures conférences sur la technologie que j'aie jamais vues en personne. Il est clair qu'il est d'abord un enseignant et ensuite un directeur technique. L'ambiance qu'il dégageait était celle d'un instructeur de camp de surf, tandis que ses compétences étaient celles d'un professionnel chevronné des bases de données, capable de tourner en rond, techniquement parlant, autour de la grande majorité des directeurs techniques. Si je n'avais assisté qu'à une seule conférence pendant toute la durée de l'événement, ce serait celle de Mark.

J'étais très enthousiaste à l'idée d'entendre l'orateur principal du dernier jour : Ray Kurzweil. Ray est un futurologue accompli qui a fait de brillantes prédictions au cours de sa carrière. Il a également écrit quelques livres à succès et donné de nombreuses conférences au fil des ans.

À MongoDB World, Ray a réitéré beaucoup de choses que je l'ai entendu dire au fil des ans. Rétrospectivement, ce n'est pas très surprenant, mais cela m'a amené à la conclusion que Ray aurait dû être interviewé par des personnes comme Dev ou Mark afin de créer une conversation dynamique pour le discours de clôture.

Note : 7/10

Sessions en petits groupes

Les sessions en petits groupes ont fourni des aperçus intéressants des divers outils et techniques que les équipes utilisent pour exploiter MongoDB dans leurs organisations.

Voici quelques sujets que j'ai trouvés très intéressants :

• Royaume
• MongoDB sans serveur (Atlas Serverless)
• Séries chronologiques

Royaume

Realm semble être une offre très convaincante pour permettre aux appareils mobiles et à l'IOT de synchroniser les données avec un cluster MongoDB géré (comme Atlas ou Linode Managed Databases).

Le problème avec les données en périphérie est que la base de données locale/sur appareil est souvent désynchronisée avec la base de données dans le nuage. À première vue, ce problème peut sembler insignifiant, mais dès que l'on passe à une échelle supérieure, par exemple 100 000 appareils mobiles, il peut prendre de l'ampleur.

Je ne l'ai pas encore testé, mais la session à laquelle j'ai assisté a fait de MongoDB's Realm la solution parfaite pour les différents problèmes liés à la synchronisation des bases de données d'un bout à l'autre du monde.

Quelques avantages clés de Realm :

• Conçu pour la synchronisation dynamique des données avec MongoDB
• Remplacement de SQLite/Core Data
• Faible encombrement des appareils
• API multiplateformes (Kotlin, Swift, JavaScript, etc.)
• Aide à traiter les problèmes de connexion sur les appareils mobiles/IoT.

Pour en savoir plus, cliquez ici.

MongoDB sans serveur

Le terme serverless est un peu idiot si vous voulez mon avis, car j'ai tendance à penser que serverless est un "hébergement à échelle gérée". Indépendamment du nom, le serverless est là pour rester et je suis tout à fait pour.

Serverless est le processus de mise à l'échelle de vos ressources informatiques pour répondre à la demande, quelle qu'en soit l'ampleur. L'ampleur de la demande est souvent sujette à débat, mais la réduction à zéro permet souvent d'économiser beaucoup en termes de ressources et souvent d'argent et de sens.

Présentons un scénario qui permet de mettre en évidence les avantages de l'approche sans serveur :

Scénario sans serveur : Un site web suit les statistiques, en temps réel, lors d'événements sportifs.

Lors d'un événement sportif : L'application web dispose d'un grand nombre de données de suivi des activités ; l'application web a un trafic variable en fonction du nombre de supporters, de l'heure de la journée, de l'avancement de la saison, etc.

Lorsqu'il n'y a pas d'événement sportif : L'application web ne fait aucun suivi d'activité ; l'application web n'a aucun trafic la plupart du temps ; l'application web, en théorie, pourrait être complètement désactivée sans que personne ne le sache.

Quel que soit le temps écoulé entre les événements, ce qui précède est presque toujours vrai. La variabilité du fonctionnement de ce site web théorique est un exemple spectaculaire de la raison d'être de serverless : Une seconde, vous avez 100 000 requêtes, la suivante huit requêtes. La seconde d'après, c'est 250 000 demandes, la suivante 76. Serverless est conçu pour gérer ces scénarios avec grâce et une latence incroyable.

Bases de données sans serveur : Le rêve insaisissable

Le scénario ci-dessus fonctionne bien avec les applications web sans serveur, mais qu'en est-il également d'une base de données sans serveur ?

Les applications web modernes, sans serveur ou non, ont besoin de pouvoir accéder aux données avec une latence aussi faible que possible. Si la base de données est sans serveur, cela signifie qu'elle peut être mise à l'échelle jusqu'à zéro instance en cours d'exécution ou simplement que la base de données peut être essentiellement désactivée. Ainsi, si la base de données est désactivée, il y aura un délai pour la réactiver ; ce qui rend le serverless sur la couche base de données traditionnellement très difficile à réaliser.

Le problème de la mise à l'échelle ou de la réduction des bases de données est lié à la taille des données ; plus de données signifie qu'il faudra plus de temps pour activer ou désactiver une base de données. Historiquement, il est beaucoup plus facile et sans friction de laisser vos services de base de données fonctionner en permanence tandis que votre application peut être sans serveur (ou non) grâce à Kubernetes et à diverses implémentations de Docker.

Je n'ai pas encore vu d'alternative SQL sans serveur qui soit à la hauteur de ce que fait Atlas Serverless, et ce n'est pas un mince exploit de la part de l'équipe MongoDB. C'est formidable de les voir être les pionniers des bases de données sans serveur.

Ce que je n'ai pas vu, c'est la prise en charge de MongoDB open-source sans serveur. C'est peut-être aussi à venir.

Sans serveur : Vitesse, coût et friction

Plus vite je peux déployer des applications, plus vite je peux apprendre ce qui fonctionne et ce qui ne fonctionne pas. Le serverless permet de réaliser ce type de tests avec une augmentation minimale des coûts. Je dirais que c'est l'un des plus grands avantages de l'utilisation de serverless.

Si votre application ne fonctionne pas, laissez-la en place, mais sans aucune ressource en cours d'exécution. Dès les premiers signes de trafic, adaptez votre application à la demande. Réduisez l'échelle lorsque la demande s'estompe. Cette méthode s'aligne parfaitement sur les tests de publicité A/B, de sorte que votre application ne fonctionne que lorsqu'elle en a besoin, et non pas en permanence.

Si votre application fonctionne et fonctionne bien, les frais généraux liés au maintien de la charge continue sont retirés à votre équipe par divers services gérés. Cela signifie qu'une petite équipe peut gérer une quantité incroyable de charge avec très peu (voire pas du tout) de travail supplémentaire.

Tout cela pour dire que le serverless augmente l'efficacité des équipes tout en réduisant le coût global nécessaire pour gérer les exigences de la demande pour cette application.

Serverless n'est pas une solution parfaite pour tout, mais c'est certainement ce qui résout tant de problèmes avec des équipes aux ressources limitées.

Séries temporelles sur MongoDB

MongoDB (au moins à partir de la version 5) prend en charge des fonctions intégrées pour l'analyse des séries temporelles. Si vous n'êtes pas familier avec la création de données de séries temporelles, il s'agit simplement d'ajouter une sorte d'horodatage à chaque ligne de votre collection de base de données (table).

L'analyse des séries temporelles est idéale pour :

• Améliorer les décisions financières qui nécessitent des prévisions de ventes, de demande de produits, d'estimations de trafic, etc.
• Achat d'actions, d'obligations, etc.
• Suivi des capteurs et des appareils IoT au fil du temps.
• Mesures de performance (telles que les performances du site web, la publicité, etc.)

Il y a certainement beaucoup plus d'applications pour ce type d'analyse, mais comme nous le voyons, l'utilisation de données de séries temporelles est essentielle pour de nombreux rôles dans une organisation. MongoDB facilite grandement cette analyse. Je reviendrai plus en détail sur l'analyse des séries temporelles avec MongoDB à l'avenir, mais pour l'instant, voici un exemple rapide d'utilisation de MongoDB avec le paquetage Python pymongo :

1. Initialiser le client MongoDB

import os
from pymongo import MongoClient

# this assumes you have a running MongoDB cluster/instance
mongodb_un = os.envion.get("MONGODB_USERNAME")
mongodb_pw = os.envion.get("MONGODB_PASSWORD")
mongodb_host = "localhost"
mongodb_port = 27017
db_url =  f"mongodb://{mongodb_un}:{mongodb_pw}@{mongodb_host}:{mongodb_port}"
client =  MongoClient(db_url)

2. Créer la collection de séries temporelles

# create/select a database
db = client.business

# create time series collection
db.create_collection(
    "rating_over_time",
    timeseries = {
        "timeField": "timestamp",
        "metaField": "metadata",
        "granularity": "seconds"
    }
)

3. Ajouter des données de séries temporelles fictives

from datetime import datetime, timedelta
from random import randint

# Insert a lot of fake time series data
names = ['Kitchen','Animal','State', 'Tastey', 'Big','City','Fish', 'Pizza','Goat', 'Salty','Sandwich','Lazy', 'Fun']
company_type = ['LLC','Inc','Company','Corporation']
company_cuisine = ['Pizza', 'Bar Food', 'Fast Food', 'Italian', 'Mexican', 'American', 'Sushi Bar', 'Vegetarian']
_count = randint(0, 10_001)
for x in range(1, _count):
    now = datetime.now()
    delta = now + timedelta(days=randint(0, 2), minutes=randint(0, 60), seconds=randint(0, 60))
    if randint(0, 1) == 1:
        # randomly vary the direction of the timestamp
        delta = now - timedelta(days=randint(0, 2), minutes=randint(0, 60), seconds=randint(0, 60))
    random_company_index = randint(0, (len(company_cuisine)-1))
    business = {
        "metadata": {
            'cuisine' : company_cuisine[random_company_index],
            'name' : names[randint(0, (len(names)-1))] + ' ' + names[randint(0, (len(names)-1))]  + ' ' + company_type[randint(0, (len(company_type)-1))],
        },
        'rating' : randint(1, 5),
        "timestamp":  delta
    }
    #Step 3: Insert business object directly into MongoDB via insert_one
    result=db[db_name].insert_one(business)

4. Effectuer les agrégations de séries temporelles

# run an aggregation
list(db.rating_over_time.aggregate([
{"$unwind": "$metadata"}, 
{"$project": {
    "date": {
      "$dateToParts": { "date": "$timestamp" }
    },
    "rating": 1,
    "cuisine": "$metadata.cuisine",
  }
},
    
{
  "$group": {
    "_id": {
     "cuisine": "$cuisine",
      "month": "$date.month",
      "day": "$date.day",
      "year": "$date.year",
    },
    "avgRating": { "$avg": "$rating" }
  }
}
]))

Il en résulte que :

[{'_id': {'cuisine': 'American', 'month': 6, 'day': 16, 'year': 2022},
  'avgRating': 2.75},
 {'_id': {'cuisine': 'Italian', 'month': 6, 'day': 12, 'year': 2022},
  'avgRating': 3.0},
 {'_id': {'cuisine': 'American', 'month': 6, 'day': 14, 'year': 2022},
  'avgRating': 3.0655737704918034},
 {'_id': {'cuisine': 'Pizza', 'month': 6, 'day': 15, 'year': 2022},
  'avgRating': 3.0508474576271185},
]

Les données ci-dessus proviennent de mes propres expériences avec Python et MongoDB, mais elles ont été largement inspirées par une session sur l'utilisation de l'analyse des séries temporelles de MongoDB pour automatiser l'achat d'actions sur la base de prix historiques. L'exposé n'était pas une plongée en profondeur sur le plan technique car, comme vous pouvez le voir ci-dessus, il n'était pas nécessaire de le faire ! MongoDB semble certainement réduire la friction pour réaliser des choses étonnantes.

Révision

Dans l'ensemble, les sessions en petits groupes manquaient de la profondeur technique que j'apprécie vraiment en tant que développeur, mais c'était logique. La plupart des sessions duraient moins d'une heure et souvent 30 minutes. Il est difficile d'entrer dans les détails techniques en si peu de temps avec un public aussi varié.

Le contenu des sessions auxquelles j'ai assisté était généralement remarquable, avec quelques ratés ici et là.

Note : 8/10

Pavillon des partenaires

Le pavillon des partenaires était rempli d'entreprises qui offrent des services connexes aux entreprises qui peuvent (ou non) utiliser MongoDB dans leurs activités. Les personnes qui travaillent sur ces stands sont souvent des commerciaux qui ciblent les décideurs de leur organisation.

J'ai eu la chance de rencontrer d'autres membres des équipes de Linode et d'Akamai et d'entrer en contact avec eux. En bref, c'était formidable de communiquer avec eux, car la plupart de nos communications se font par Internet, comme, j'imagine, un grand nombre de leurs clients. Je suis certainement partial, mais je trouve l'équipe Linode/Akamai incroyablement accessible, ouverte et plus que disposée à réfléchir à toutes sortes d'idées.

Quelques entreprises clés avec lesquelles j'ai pu discuter :

• HashiCorp : En discutant avec les créateurs de Terraform (entre autres), j'ai été ravi d'entendre leur engagement à rendre DevOps meilleur et plus facile pour un plus grand nombre de personnes. Certes, j'aime beaucoup utiliser Terraform dans son état actuel, mais l'avenir semble prometteur. Il faudra peut-être que j'aille voir les prochains événements HashiConf !
• Vercel : Les créateurs de Next.js ont été très présents lors de la keynote en raison de leur intégration récemment annoncée avec Atlas. En temps voulu, je passerai plus de temps avec leur plateforme ainsi qu'avec Next.js !
• Université MongoDB : Il est clair que l'éducation occupe une place importante dans la stratégie de MongoDB, ce qui m'enthousiasme au plus haut point pour l'avenir de l'éducation : accessible et axée sur des compétences demandées, pratiques et commercialisables.
• Datadog : Qui rend l'analyse des logs cool ? Datadog. J'ai été entraîné dans une démo et je suis très heureux de l'avoir fait. Il faut absolument que j'en apprenne plus sur cette société.

Notations générales

Notes principales (discutées ci-dessus) : 7/10

• Quelques grands orateurs et des orateurs médiocres

Sessions en petits groupes (discutées plus haut) : 8/10

• Dans l'ensemble, les sessions ont été excellentes, mais elles ont manqué de la profondeur technique que j'apprécie en tant que développeur.

Tutoriels : 6/10

• Lors de la principale réunion à laquelle j'ai assisté, il y a eu des problèmes de wifi. Pourquoi pas des sauvegardes Ethernet câblées ?
• L'orateur a très bien traité les questions, mais le contenu a fini par être un peu trop lent.

Nourriture : 3/10

• Des hot-dogs le deuxième jour ? Vraiment ?
• Des pizzas extraordinaires à trois rues de la conférence.

Familial : 3/10

• Si vous avez des enfants de moins de 5 ans, c'est un 0/10.
• En dehors des destinations touristiques populaires, il n'y a pas grand-chose à faire pour les jeunes enfants.
• New York est bondée, bruyante, les piétons marchent de manière agressive et les véhicules sont très agressifs.
• Oui, je vis dans une petite ville près d'Austin, au Texas. Nous avons beaucoup d'espace, ce qui n'est pas le cas de New York.

Localisation : 9/10

• D'un point de vue professionnel, un événement à New York est incroyable. Il y a beaucoup de nourriture, de restaurants, de bars, de lieux, etc. qui permettent de se divertir et de se connecter avec d'autres professionnels.
• L'énergie de NYC est sans commune mesure avec celle de la plupart des autres villes du monde ; il y a toujours quelque chose de construit ou de reconstruit, les gens sont toujours dehors, il y a presque toujours quelque chose de bon à manger.
• Il est étonnant de constater qu'il faut plus de deux heures pour parcourir 15 miles à New York. Pour certains, cela pourrait faire baisser la note de l'endroit à 3/10.
• Si je n'avais pas été sponsorisée pour y participer, la note serait de 2/10 (haha !) en raison du coût élevé de tout ce qui se fait à New York.

Hôtels : 5/10

• Cher pour une chambre minuscule.
• En revanche, le buffet du petit-déjeuner de mon hôtel était excellent et j'ai entendu la même chose dans d'autres hôtels.
• Beaucoup de choix.

Aéroport : 3/10

• Évitez à tout prix le terminal 8 de JFK. Il est délabré et les options en matière de nourriture et de souvenirs sont médiocres.
• Le départ de l'aéroport offre de nombreuses possibilités et toutes sont relativement rapides.
• Si j'atterrissais au bon terminal, cela pourrait faire grimper la note à 6/10.

Transport : 7/10

• Uber/Lyft/taxis/etc. sont omniprésents.
• Le coût du transport est élevé lorsque vous devez le prendre.
• Le transport depuis et vers l'aéroport a coûté près d'un quart du prix de mes billets d'avion.
• New York est très accessible à pied et il est donc facile de s'y déplacer.

Collations de la conférence : 6/10

• De bons choix, mais trop peu nombreux

Sélection des boissons de la conférence : 5/10

• Il s'agit essentiellement des trois grands produits Coke.

Café de la conférence : 8/10

• Le café local était solide, mais j'adore le café noir fraîchement préparé, quel que soit l'endroit où il se trouve.

Participation de l'entreprise : 6/10

• Je dirais que 20 entreprises se sont présentées ; je m'attendais à ce qu'il y en ait plus.

Le sac à dos : 3/10

• Une chasse au trésor pour des cadeaux ? C'est mignon, mais non merci.

Conférence Divertissement : 8/10

• Il y avait des comédiens jouant en duel au piano dans le pavillon. Ils étaient géniaux.
• Il semble qu'il y ait eu des concours de jeux, mais ils semblaient limités à quelques participants à la fois.
• L'animateur du salon IDEA était formidable.
• L'après-fête s'est déroulée dans la bonne humeur pour ceux qui y ont participé.

Accessibilité auditive :

• Au moins trois interprètes ASL étaient présents lors des événements, le cas échéant.
• Je ne peux pas me prononcer sur la qualité, mais il me semble qu'ils étaient excellents.

Accessibilité visuelle : N/A

• Je n'ai pas cherché ni vu de soutien pour les malvoyants.

Naturellement, l'expérience de chacun peut varier considérablement, il faut donc prendre ce qui précède avec un grain de sel salt.

Note globale : 8/10

MongoDB World m'a convaincu que je devais passer 10x-100x plus de temps à utiliser MongoDB. Ce n'est pas rien, car je dois une grande partie de ma carrière à SQL et aux outils qui s'y intègrent.

J'ai apprécié MongoDB World dans son ensemble et, si vous en avez la possibilité, vous pourriez envisager d'y participer en 2023. Si vous êtes pressé par le temps, je pense que vous pouvez obtenir beaucoup en participant seulement au Jour 1. Si vous y assistez, vous pourrez toujours regarder les sessions à la demande après la fin de l'événement (jusqu'à 30 jours, je crois). Les jours 2 et 3 ont été très animés, mais le nombre de participants a commencé à diminuer dans l'après-midi du jour 2.

Je pense qu'il est difficile pour les conférences de répondre à tous les niveaux d'expertise technique, mais je pense que MongoDB World a fait un excellent travail dans ce sens. De nombreux présentateurs se sont rendus disponibles après les sessions pour des discussions plus approfondies, ce qui était très agréable à voir. La plupart des présentations auxquelles j'ai assisté étaient toutes professionnelles et bien exécutées, comme on pouvait s'y attendre. Les participants semblaient réellement intéressés par les contacts et l'apprentissage de ce que font les autres dans ce domaine.

Le centre de conférence Javits à New York était incroyable et donnait une impression de grandeur à l'ensemble de l'événement. La grandeur du centre de conférence a vraiment mis en évidence le caractère pathétique de ma minuscule chambre d'hôtel.

L'absence de nourriture à la conférence a été compensée par le fait que la ville de New York offre certains des meilleurs plats du monde à presque tous les coins de rue. Si vous êtes gourmand, vous pouvez vous rendre à l'heure du déjeuner à Hudson Yards ou à Time Square. Et comme dans toute bonne conférence, le café coulait à flots !

Si vous envisagez d'emmener votre famille à la conférence, vous devriez peut-être y réfléchir à deux fois, car il n'y a pas grand-chose que les jeunes enfants (5 ans et moins) puissent faire pendant que vous êtes occupés à l'événement.

Pour moi, l'objectif de cet événement est d'apprendre aux participants comment utiliser au mieux MongoDB dans leur entreprise. Pour cela, je pense qu'ils ont totalement réussi et je suis absolument convaincu par MongoDB. N'oublions pas que SQL est apparu pour la première fois en 1974 alors que la première version de MongoDB date de 2009. La différence à cet âge est évidente avec l'approche moderne de MongoDB pour résoudre les problèmes modernes auxquels sont confrontées les organisations et les projets de type "cloud-first". Le simple fait que cette conférence existe témoigne de leur dévouement à pousser l'enveloppe vers l'avant et à nous emmener tous avec eux.

Pour MongoDB World 2023, nous pourrons peut-être nous rencontrer.

Santé !

Justin Mitchel
Enseignant et fondateur
CodingForEntrepreneurs.com