Siamo andati al MongoDB World 2022, così non dovrete farlo anche voi!

La scorsa settimana ho partecipato al MongoDB World 2022 grazie a una sponsorizzazione di Linode. In questo articolo, descriverò il mio tempo trascorso lì insieme ad alcuni frammenti di codice su cui sto lavorando per un prossimo tutorial. Ho anche creato un video che riassume il mio tempo al MongoDB World.

Il mio riassunto in 240 caratteri:

Il MongoDB World mi ha convinto a usare MongoDB più spesso. Il pubblico di riferimento era probabilmente quello dei manager e non quello degli sviluppatori, dato che la maggior parte degli interventi (compreso il mio) non è stata approfondita dal punto di vista tecnico come spesso piace agli sviluppatori. Consiglio di partecipare!

Posizione: New York City

La posizione del Javits Center era perfetta e la sede splendida. Per una conferenza, una città come NYC è esattamente il tipo di energia di cui si ha bisogno. C'è così tanto movimento all'esterno che si ripercuote naturalmente sulla conferenza.

Valutazione: 9/10

Le conferenze

Per dare il via all'evento, abbiamo ascoltato il CEO di MongoDB Dev Ittycheria. Se avessi ascoltato solo il keynote di Dev, mi sarei convinto a usare MongoDB molto più spesso. Dev ha rafforzato l'idea che MongoDB esiste per aiutare i team a ottenere di più con meno e, durante la mia permanenza alla conferenza, questo è apparso vero.

Dev è stato rapidamente seguito da un altro presentatore che ha davvero risucchiato l'energia dalla sala. La sensazione era palpabile. Dev è tornato sul palco per dare un po' di energia necessaria prima dell'inizio delle sessioni di breakout.

Durante il keynote ci sono state anche alcune dimostrazioni dal vivo che hanno evidenziato alcune delle meraviglie di MongoDB. Come si può immaginare, le dimostrazioni dal vivo sono spesso una ricetta per il disastro, ma queste si sono svolte senza problemi per quanto ho potuto vedere.

Nel pomeriggio del primo giorno, il CTO Mark Porter ha tenuto uno dei migliori keynote tecnologici che abbia mai visto di persona. È chiaro che è prima un insegnante e poi un CTO. La sua atmosfera era quella di un istruttore di surf camp, mentre le sue competenze sono quelle di un professionista esperto di database che può girare intorno, dal punto di vista tecnico, alla stragrande maggioranza dei CTO in circolazione. Se avessi assistito a un solo intervento per tutto il tempo, sarebbe stato quello di Mark.

Ero davvero entusiasta di ascoltare il relatore dell'ultimo giorno: Ray Kurzweil. Ray è un affermato futurista e ha fatto alcune brillanti previsioni nel corso della sua carriera. Ha anche scritto alcuni libri best-seller e tenuto numerose conferenze nel corso degli anni.

Al MongoDB World, Ray ha ribadito molte delle cose che gli ho sentito dire nel corso degli anni. In retrospettiva, questo non mi sorprende più di tanto, ma mi ha portato alla conclusione che Ray avrebbe dovuto essere intervistato da personaggi del calibro di Dev o Mark per fornire una conversazione dinamica per il keynote conclusivo.

Valutazione: 7/10

Sessioni di approfondimento

Le sessioni di breakout hanno fornito interessanti panoramiche dei vari strumenti e tecniche con cui i team sfruttano MongoDB nelle loro organizzazioni.

Ecco alcuni argomenti che ho trovato molto interessanti:

• Regno
• MongoDB senza server (Atlas Serverless)
• Serie temporale

Regno

Realm sembra essere un'offerta molto interessante per consentire ai dispositivi mobili e IOT di sincronizzare i dati con un cluster MongoDB gestito (come Atlas o Linode Managed Databases).

La sfida dei dati on the edge consiste nel garantire che il database locale/sui dispositivi sia spesso non sincronizzato con il database nel cloud. A prima vista, questo può sembrare un problema banale, ma quando si raggiunge una scala, ad esempio 100.000 dispositivi mobili, il problema può diventare grave.

Non l'ho ancora testato, ma la sessione a cui ho partecipato ha fatto sì che Realm di MongoDB sia la soluzione perfetta per i vari problemi legati alla sincronizzazione dei database edge-to-cloud.

Alcuni vantaggi chiave di Realm:

• Realizzato per la sincronizzazione dinamica dei dati con MongoDB
• Sostituzione di SQLite/Core Data
• Ingombro ridotto sui dispositivi
• API multipiattaforma (Kotlin, Swift, JavaScript, ecc.)
• Aiuta a gestire i problemi di connessione sui dispositivi mobili/IoT

Per saperne di più, cliccate qui.

MongoDB senza server

Il termine serverless è un po' sciocco, se lo chiedete a me, perché tendo a pensare a serverless come "managed scale hosting". Indipendentemente dal nome, serverless è qui per restare e io sono a favore.

Serverless è il processo di scalare le risorse di calcolo per soddisfare la domanda, sia essa grande o piccola. Il quanto grande è spesso oggetto di discussione, ma scalare fino a zero spesso consente di risparmiare molto in termini di risorse e spesso di dollari e senso.

Vediamo uno scenario che aiuta a evidenziare i vantaggi di serverless:

Scenario serverless: Un sito web tiene traccia delle statistiche, in tempo reale, durante gli eventi sportivi.

Quando si svolge un evento sportivo: L'applicazione web ha molti dati di monitoraggio delle attività; l'applicazione web ha un traffico variabile in base al numero di tifosi, all'ora del giorno, al momento della stagione, ecc.

Quando non è in corso un evento sportivo: L'applicazione web non tiene traccia delle attività; l'applicazione web ha un traffico nullo per la maggior parte del tempo; l'applicazione web, in teoria, potrebbe essere completamente spenta e nessuno lo saprebbe.

Indipendentemente dal tempo che intercorre tra un evento e l'altro, quanto sopra è quasi sempre vero. La variabilità del funzionamento di questo sito web teorico è un esempio drammatico del perché serverless è fantastico: Un secondo prima ci sono 100.000 richieste, quello dopo sono otto. Un secondo dopo ci sono 250.000 richieste, quello dopo ancora 76. Serverless è progettato per gestire questi scenari con grazia e una latenza incredibile.

Database senza server: Il sogno sfuggente

Lo scenario sopra descritto funziona bene con le applicazioni web serverless, ma che dire di un database serverless?

Le moderne applicazioni web, serverless o meno, devono poter accedere ai dati con una latenza il più possibile ridotta. Se il database è serverless, ciò significa che può essere scalato fino a zero istanze in esecuzione o semplicemente il database può essere essenzialmente spento. Se il database viene spento, ci sarà un ritardo nel riaccenderlo, rendendo così tradizionalmente molto difficile la realizzazione di serverless a livello di database.

Il problema di scalare o ridurre i database riguarda la dimensione dei dati; più dati significa che ci vorrà più tempo per attivare o disattivare un database. Storicamente, è molto più semplice e senza attriti mantenere i servizi di database sempre in funzione, mentre l'applicazione può essere serverless (o meno) grazie a Kubernetes e alle varie implementazioni di Docker.

Non ho ancora visto un'alternativa SQL Serverless che sia all'altezza di ciò che fa Atlas Serverless, e questo non è un risultato da poco per il team di MongoDB. È bello vederli pionieri dei database serverless.

Non ho visto il supporto per MongoDB open-source senza server. Forse è in arrivo anche quello.

Serverless: Velocità, costi e attriti

Più velocemente posso distribuire le applicazioni, più velocemente posso imparare cosa funziona e cosa no. Serverless consente di eseguire questo tipo di test con un aumento minimo dei costi. Questo, a mio avviso, è uno dei maggiori vantaggi dell'utilizzo di serverless.

Se la vostra applicazione non funziona, lasciatela lì, ma con zero risorse in funzione. Al primo segnale di traffico, scalate per soddisfare la domanda. Riducete la scala quando la domanda si affievolisce. Questo si allinea perfettamente con l'esecuzione di test pubblicitari A/B, in modo che l'app possa funzionare quando serve e non sempre.

Se la vostra applicazione funziona e funziona bene, l'overhead del mantenimento del carico continuo è sottratto al vostro team da vari servizi gestiti. Ciò significa che un piccolo team può gestire un'incredibile quantità di carico con pochissimo (o addirittura nessuno) lavoro aggiuntivo.

Tutto questo per dire che serverless aumenta l'efficacia dei team, riducendo al contempo i costi complessivi necessari per gestire i requisiti della domanda di quell'applicazione.

Serverless non è una soluzione perfetta per tutto, ma è certamente in grado di risolvere molti problemi con i team con risorse limitate.

Serie temporali su MongoDB

MongoDB (almeno dalla versione 5) supporta funzioni integrate per l'analisi delle serie temporali. Se non si ha familiarità con la creazione di dati di serie temporali, si tratta semplicemente di aggiungere una sorta di timestamp a ogni riga della collezione (tabella) del database.

L'analisi delle serie temporali è ideale per:

• Migliorare le decisioni finanziarie che richiedono previsioni di vendita, domanda di prodotti, stime di traffico, ecc.
• Acquisto di azioni, obbligazioni, ecc.
• Tracciamento dei sensori e dei dispositivi IoT nel tempo.
• Metriche di performance (come le prestazioni del sito web, la pubblicità, ecc.)

Ci sono sicuramente molte altre applicazioni per questo tipo di analisi, ma come vediamo l'utilizzo dei dati delle serie temporali è fondamentale per molti ruoli in un'organizzazione. MongoDB rende l'analisi molto più semplice. In futuro tratterò molto di più sull'analisi delle serie temporali con MongoDB, ma per ora ecco un rapido esempio che utilizza MongoDB con il pacchetto Python pymongo:

1. Inizializzare il 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. Creare la collezione di serie temporali

# 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. Aggiungere i dati delle serie temporali di simulazione

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. Eseguire le aggregazioni delle serie temporali

# 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" }
  }
}
]))

Ne consegue che:

[{'_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},
]

I dati qui sopra provengono da miei esperimenti con Python e MongoDB, ma sono stati ispirati in gran parte da una sessione che parlava dell'utilizzo di MongoDB Time Series Analysis per automatizzare l'acquisto di azioni sulla base dei prezzi storici. L'intervento non era un'immersione profonda dal punto di vista tecnico perché, come potete vedere qui sopra, non ce n'era bisogno! MongoDB sembra certamente ridurre l'attrito nel fare alcune cose incredibili.

Recensione

Nel complesso, le sessioni di breakout mancavano dell'approfondimento tecnico che mi piace molto come sviluppatore, ma questo aveva senso. La maggior parte delle sessioni è durata meno di un'ora, spesso 30 minuti. È difficile entrare nel vivo dei dettagli tecnici in un tempo così breve con un pubblico così eterogeneo.

I contenuti presentati nelle sessioni a cui ho partecipato sono stati generalmente eccezionali, con qualche mancanza qua e là.

Valutazione: 8/10

Padiglione partner

Il padiglione dei partner era pieno di aziende che offrono servizi correlati alle imprese che possono (o meno) utilizzare MongoDB nella loro attività. Le persone che lavorano in questi stand sono spesso venditori che si rivolgono ai responsabili delle decisioni per le loro organizzazioni.

Qui ho avuto la possibilità di incontrare altri membri del team Linode e Akamai e di entrare in contatto con loro. In breve, è stato fantastico entrare in contatto con loro, dal momento che la maggior parte delle nostre comunicazioni avviene via Internet, come immagino faccia anche un gran numero di loro clienti. Sono certamente di parte, ma trovo che il team Linode/Akamai sia incredibilmente accessibile, aperto e più che disposto a fare brainstorming su tutti i tipi di idee.

Ho avuto modo di parlare con alcune aziende chiave:

• HashiCorp: Chiacchierando con i creatori di Terraform (tra le altre cose) è stato bello sentire il loro impegno a rendere DevOps migliore e più facile per un maggior numero di persone. Certo, mi piace molto usare Terraform nel suo stato attuale, ma il futuro sembra luminoso. Forse dovrò dare un'occhiata anche ai futuri eventi della HashiConf!
• Vercel: L'azienda produttrice di Next.js è stata molto presente al keynote grazie alla sua recente integrazione con Atlas. A tempo debito, dedicherò più tempo alla loro piattaforma e a Next.js!
• Università MongoDB: È chiaro che l'istruzione è una parte importante della strategia di MongoDB, il che mi entusiasma assolutamente per il futuro dell'istruzione: accessibile e guidata da competenze pratiche e spendibili.
• Datadog: Chi rende l'analisi dei log un'attività cool? Datadog, ecco chi. Sono stato coinvolto in una demo e sono molto contento di averlo fatto. Devo assolutamente approfondire la conoscenza di questa azienda.

Valutazioni generali

Keynote (discusse sopra): 7/10

• Alcuni grandi diffusori e altri poco brillanti

Sessioni di approfondimento (discusse più sopra): 8/10

• Nel complesso ottime sessioni, ma mancava l'approfondimento tecnico che mi piace come sviluppatore.

Tutorial: 6/10

• In quello principale a cui ho partecipato, c'erano problemi di wifi. Perché non si possono fare backup via ethernet?
• L'oratore ha trattato i temi in modo eccellente, ma il contenuto ha finito per essere un po' troppo lento.

Cibo: 3/10

• Hot dog il secondo giorno? Davvero? E' un'ottima idea.
• Pizza strepitosa a tre isolati dalla conferenza.

Adatto alle famiglie: 3/10

• Se avete bambini sotto i 5 anni, è uno 0/10.
• A parte le destinazioni turistiche più popolari, c'è poco da fare per i bambini piccoli.
• New York è affollata, rumorosa, i pedoni camminano in modo aggressivo e i veicoli sono molto aggressivi.
• Sì, vivo in una piccola città vicino ad Austin, in Texas, quindi la valutazione si basa su questo. Abbiamo molto spazio, New York no.

Posizione: 9/10

• Dal punto di vista professionale, un evento a New York è incredibile. C'è un sacco di ottimo cibo, ristoranti, bar, luoghi di ritrovo, ecc. per intrattenere e connettersi con altri professionisti.
• L'energia di NYC non ha eguali in quasi tutti i luoghi del mondo: si costruisce/ricostruisce sempre qualcosa, la gente è sempre in giro, c'è quasi sempre qualcosa di buono da mangiare.
• È incredibile come 15 miglia possano richiedere più di 2 ore di guida a New York. Per alcuni, questo potrebbe abbassare la valutazione della location a 3/10.
• Se non fossi stata sponsorizzata, il voto sarebbe stato di 2/10 (haha!) a causa del costo elevato di tutto a New York.

Hotel: 5/10

• Costoso per una stanza minuscola.
• Il lato positivo è che la colazione a buffet del mio hotel era stellare e ho sentito dire lo stesso di altri hotel.
• Molte scelte.

Aeroporto: 3/10

• Evitare assolutamente il Terminal 8 del JFK. È fatiscente e le opzioni di cibo/souvenir sono scarse.
• L'uscita dall'aeroporto offre molte opzioni e tutte relativamente veloci.
• Se atterrassi nel terminal giusto, potrebbe passare a 6/10.

Trasporto: 7/10

• Uber/Lyft/taxi/ecc. sono ovunque.
• Il costo del trasporto è elevato quando è necessario prenderlo.
• Il trasporto da/per l'aeroporto è costato quasi 1/4 del costo dei biglietti aerei.
• New York è molto accessibile a piedi e quindi facile da girare.

Spuntini della conferenza: 6/10

• Buone scelte, troppo poche

Selezione delle bevande della conferenza: 5/10

• In pratica i 3 grandi prodotti della Coca Cola.

Caffè della conferenza: 8/10

• Il caffè prodotto localmente era solido, ma d'altra parte amo il caffè nero appena fatto da qualsiasi parte.

Affluenza in azienda: 6/10

• Stimerei che si siano presentate 20 aziende; mi aspettavo di più.

Swag: 3/10

• Caccia al tesoro per ottenere un premio? Carino, ma no grazie.

Intrattenimento della conferenza: 8/10

• Nel padiglione c'erano dei comici che duellavano al pianoforte. Erano fantastici.
• Sembrava che ci fossero delle gare di gioco, ma sembravano limitate a pochi partecipanti alla volta.
• L'emcee nella lounge IDEA è stato fantastico.
• L'after party si è rivelato divertente per coloro che vi hanno partecipato.

Accessibilità uditiva:

• C'erano almeno 3 interpreti ASL che lavoravano agli eventi dove necessario.
• Non posso parlare della qualità, ma sembrava che fossero ottimi.

Accessibilità visiva: N/D

• Non ho cercato né visto supporto per gli ipovedenti.

Naturalmente, l'esperienza di ognuno può variare in modo sostanziale, quindi prendete quanto sopra con un granello di salt.

Valutazione complessiva: 8/10

Il MongoDB World mi ha convinto che devo dedicare un tempo 10x-100x maggiore all'utilizzo di MongoDB. Non è una cosa da poco per me, visto che devo gran parte della mia carriera a SQL e agli strumenti che vi si integrano.

Nel complesso, il MongoDB World mi è piaciuto e, se ne avete la possibilità, potreste prendere in considerazione la partecipazione nel 2023. Se avete poco tempo a disposizione, credo che possiate ottenere molto partecipando solo al primo giorno. Se partecipate, potete sempre guardare/rivedere le sessioni on-demand dopo la fine dell'evento (credo per un massimo di 30 giorni). Il secondo e il terzo giorno hanno avuto ancora molto da fare, ma la partecipazione ha iniziato a diminuire nel pomeriggio del secondo giorno.

Penso che sia difficile per le conferenze servire tutte le gamme di competenze tecniche, ma credo che MongoDB World abbia fatto un ottimo lavoro di bilanciamento. Molti dei relatori si sono resi disponibili dopo le sessioni per discussioni più approfondite, il che è stato fantastico. La maggior parte delle presentazioni a cui ho partecipato erano tutte professionali e ben eseguite, come ci si aspetterebbe. I partecipanti sembravano sinceramente interessati a stabilire un contatto e a conoscere ciò che gli altri stanno facendo nello spazio.

Il Javits Conference Center di New York è stato incredibile e ha dato una sensazione di grandezza all'intera atmosfera dell'evento. L'imponenza del centro congressi ha messo in evidenza quanto fosse patetica la mia minuscola camera d'albergo.

La scarsità di cibo alla conferenza è stata compensata dal fatto che a New York c'è il miglior cibo del mondo in quasi ogni angolo di strada. Se siete dei buongustai, potreste voler fare un salto all'ora di pranzo a Hudson Yards o a Time Square. E come ogni buona conferenza, il caffè scorreva a fiumi!

Se state pensando di portare con voi la famiglia durante la conferenza, dovreste riconsiderare l'idea, poiché non c'è molto che i bambini piccoli (5 anni e meno) possano fare mentre voi siete impegnati nell'evento.

Per me, lo scopo di questo evento è quello di insegnare ai partecipanti come utilizzare al meglio MongoDB all'interno della loro azienda. Per questo, credo che abbiano fatto centro e sono assolutamente convinto di MongoDB. Non dimentichiamo che SQL è apparso per la prima volta nel 1974, mentre il primo rilascio di MongoDB risale al 2009. La differenza in quest'epoca è evidente con l'approccio moderno di MongoDB per risolvere i problemi moderni che devono affrontare le organizzazioni e i progetti cloud-first. Il solo fatto che questa conferenza esista testimonia la loro dedizione a spingere il progresso e a portarci tutti con loro.

Per il MongoDB World 2023, forse potremo incontrarci.

Salute!

Justin Mitchel
Insegnante e fondatore
CodingForEntrepreneurs.com