Fomos a MongoDB World 2022, por isso não era preciso!

Assisti ao MongoDB World 2022 na semana passada, graças a um patrocínio da Linode. Neste artigo, vou dividir o meu tempo lá juntamente com alguns trechos de código em que estou a trabalhar para um próximo tutorial. Também criei um vídeo recapitulando o meu tempo no MongoDB World.

O meu resumo de 240 caracteres:

MongoDB World convenceu-me que preciso de usar MongoDB com mais frequência. O público-alvo era provavelmente os gestores sobre os programadores, uma vez que a maioria das conversações (incluindo a minha própria) não entraram no aprofundamento técnico que muitas vezes se verificava. Recomendo a minha presença!

Localização: Cidade de Nova Iorque

A localização do Javits Center era perfeita e o local era deslumbrante. Para uma conferência, uma cidade como NYC é exactamente o tipo de energia de que se precisa. Há tanta coisa a acontecer fora dela que sangra naturalmente para dentro da conferência.

Classificação: 9/10

Keynotes

Para dar o pontapé de saída do evento, ouvimos o CEO da MongoDB, Dev Ittycheria. Se a única nota-chave que ouvi foi a do Dev, teria sido vendido com a MongoDB significativamente mais vezes. Dev reforçou a noção de que o MongoDB existe para ajudar a capacitar as equipas a fornecer mais com menos e, ao longo do meu tempo na conferência, isto pareceu ser verdade.

O Dev foi rapidamente seguido por outro apresentador que realmente sugou a energia para fora da sala. A sensação era palpável. Dev regressou ao palco para dar alguma energia muito necessária, mesmo antes do início das sessões de fuga.

Tivemos também algumas demonstrações ao vivo durante a nota-chave que destacou algumas das maravilhas que é o MongoDB. Como podem imaginar, as demos ao vivo são muitas vezes uma receita para o desastre, mas, tanto quanto pude perceber, estas decorreram sem sobressaltos.

À tarde, no primeiro dia, CTO Mark Porter entregou uma das melhores notas-chave tecnológicas que já vi pessoalmente. É evidente que ele é primeiro um professor e segundo um CTO. A sua vibração era a de um instrutor de surf campismo, enquanto o seu conjunto de competências é de um profissional experiente em bases de dados que pode dirigir círculos, tecnicamente falando, à volta da grande maioria dos CTOs por aí. Se eu fosse apenas a uma conversa o tempo todo, teria sido a tónica de Mark.

Fiquei realmente entusiasmado por ouvir o orador principal do último dia: Ray Kurzweil. Ray é um futurista de sucesso e fez algumas previsões brilhantes ao longo da sua carreira. Ele também escreveu alguns livros best-sellers e deu inúmeras palestras ao longo dos anos.

Em MongoDB World, Ray reiterou muitas das coisas que o ouvi dizer ao longo dos anos. Em retrospectiva, isto não é assim tão surpreendente, mas levou-me à conclusão de que Ray deveria ter sido entrevistado por pessoas como Dev ou Mark para proporcionar uma conversa dinâmica para a tónica final.

Classificação: 7/10

Sessões de Interrupção

As sessões de breakout proporcionaram visões interessantes das várias ferramentas e técnicas que as equipas de MongoDB utilizam nas suas organizações.

Aqui estão alguns tópicos que achei muito interessantes:

• Realm
• MongoDB sem Servidor (Atlas Serverless)
• Séries cronológicas

Realm

Realm parece ser uma oferta muito convincente para permitir dispositivos móveis e IOT sincronizar dados com um Cluster MongoDB gerido (tais como Atlas ou Linode Managed Databases).

O desafio com dados no limite é assegurar que a base de dados local/em-dispositivo esteja frequentemente fora de sincronia com a base de dados das nuvens. Num relance, isto pode parecer uma questão trivial, mas uma vez atingida a escala, como 100.000 dispositivos móveis, este problema pode tornar-se um grande problema.

Ainda não o testei, mas a sessão a que assisti fez do Reino de MongoDB a solução perfeita para os vários problemas que vêm com a sincronização de bases de dados de ponta a ponta.

Alguns dos principais benefícios para a Realm:

• Feito para Sincronização Dinâmica de Dados para MongoDB
• Substituição de dados SQLite/Core
• Pequenas pegadas nos dispositivos
• APIs multiplataforma (Kotlin, Swift, JavaScript, etc.)
• Ajuda a lidar com questões de ligação em dispositivos móveis/IoT

Saiba mais sobre isto aqui.

MongoDB sem servidor

O termo serverless é um pouco idiota se me perguntarem como eu tendo a pensar em serverless como "managed scale hosting". Independentemente do nome, o serverless está aqui para ficar e eu sou a favor disso.

Serverless é o processo de dimensionar os seus recursos informáticos para satisfazer a procura, independentemente do seu tamanho ou do seu tamanho. O quão grande é muitas vezes motivo de debate, mas o redimensionamento para zero poupa muitas vezes muito em termos de recursos e muitas vezes dólares e bom senso.

Vamos traçar um cenário que ajude a realçar os benefícios de não ter servidor:

Cenário sem servidor: Um sítio web regista as estatísticas, em tempo real, durante eventos desportivos.

Quando um evento desportivo está a acontecer: A aplicação web tem muitos dados de localização de actividades; a aplicação web tem tráfego variável com base no número de adeptos, hora do dia, ponto na época, etc.; a aplicação web precisa de ser rápida para todos em todo o lado durante todo o evento

Quando um evento desportivo não está a acontecer: A aplicação web faz o rastreio de actividade zero; a aplicação web tem tráfego zero a maior parte do tempo; a aplicação web, em teoria, poderia estar completamente desligada e ninguém saberia.

Não importa o tempo decorrido entre os acontecimentos, o acima exposto é quase sempre verdade. A variabilidade na forma como este site teórico funciona é um exemplo dramático da razão pela qual o serverless é grande: Num segundo tem 100.000 pedidos, no seguinte são oito pedidos. No seguinte, são 250.000 pedidos, no seguinte, são 76. O serverless foi concebido para lidar com estes cenários com graça e uma latência incrível.

Bases de dados sem servidor: O Sonho Elusivo

O cenário acima funciona bem com aplicações web sem servidor, mas o que dizer de uma base de dados sem servidor também?

As aplicações web modernas, sem servidor ou não, necessitam da capacidade de aceder a dados com a latência mais baixa possível. Se a base de dados estiver sem servidor, isto significa que pode ser escalada para zero instâncias em execução ou simplesmente a base de dados pode ser essencialmente desligada. Assim, se a base de dados for desligada, haverá um atraso em voltar a ligá-la; tornando assim o servidor sem servidor na camada da base de dados tradicionalmente muito difícil de fazer.

O problema de aumentar ou diminuir a escala das bases de dados trata do tamanho dos dados; mais dados significa que vai demorar mais tempo a ligar ou desligar uma base de dados. Historicamente, é muito mais fácil e sem fricções manter os seus serviços de base de dados sempre a funcionar enquanto a sua aplicação pode ser sem servidor (ou não) graças a Kubernetes e várias implementações de Docker.

Tenho ainda de ver uma alternativa SQL Serverless que corresponda ao que a Atlas Serverless faz, e isto não é uma pequena realização da equipa MongoDB. É óptimo vê-los pioneiros nas bases de dados sem servidor.

O que não vi foi suporte para MongoDB sem servidor de código aberto. Talvez isso também esteja a chegar.

Sem servidor: Velocidade, Custo, & Atrito

Quanto mais depressa puder implementar aplicações, mais depressa posso aprender o que está a funcionar e o que não está. O Serverless desbloqueia a capacidade de fazer este tipo de testes com aumentos mínimos no custo de o fazer. Este, diria eu, é um dos maiores benefícios da utilização do serverless.

Se a sua aplicação não estiver a funcionar, deixe-a ficar ali, mas com zero recursos a funcionar. Ao primeiro sinal de tráfego, escalar para satisfazer a procura. Reduza a escala quando a procura desvanecer. Isto alinha-se perfeitamente com a realização de testes de publicidade A/B para que a sua aplicação possa estar a funcionar quando é necessário e não o tempo todo.

Se a sua aplicação estiver a funcionar e a funcionar bem, as despesas gerais na manutenção da carga contínua são abstraídas da sua equipa por vários serviços geridos. Isto significa que uma pequena equipa pode lidar com uma quantidade incrível de carga com muito pouco (se houver) trabalho extra.

Tudo isto para dizer que o serverless aumenta a eficácia das equipas ao mesmo tempo que reduz o custo global necessário para lidar com os requisitos da procura para essa aplicação.

O Serverless não é uma solução perfeita para tudo, mas é certamente que resolve tantos problemas com equipas com limitações de recursos.

Séries cronológicas em MongoDB

MongoDB (pelo menos a partir da versão 5), tem suporte para funções incorporadas para fazer análises de séries cronológicas. Se não estiver familiarizado com a criação de dados de séries cronológicas, é apenas o processo de adicionar algum tipo de carimbo de data/hora a cada linha da sua colecção de bases de dados (tabela).

A Análise de Séries Temporais é óptima para:

• Melhoria das decisões financeiras que exigem previsões de vendas, procura de produtos, estimativas de tráfego, etc.
• Compra de Acções, Obrigações, etc.
• Sensores de rastreio e dispositivos IoT ao longo do tempo.
• Métricas de desempenho (tais como desempenho do website, publicidade, etc.)

Há certamente muito mais aplicações para este tipo de análise mas, como vemos, a utilização de dados das Séries Temporais é fundamental para muitas funções numa organização. O MongoDB facilita muito mais a realização desta análise. Vou tocar muito mais na Análise de Série Temporal com MongoDB no futuro, mas por agora, aqui está uma amostra rápida usando MongoDB com o pacotepymongo Python :

1. Inicializar o cliente 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. Criar a colecção de séries cronológicas

# 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. Adicionar dados de séries cronológicas simuladas

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. Realizar as agregações das séries cronológicas

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

Isto resulta em:

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

Os dados acima vêm da minha própria experiência com Python e MongoDB, mas foram inspirados em grande parte por uma sessão sobre a utilização da Análise da Série Temporal MongoDB para automatizar a compra de stocks com base em preços históricos. A conversa não foi um mergulho profundo tecnicamente porque, como pode ver acima, não tinha mesmo de ser! MongoDB parece certamente diminuir a fricção em fazer algumas coisas espantosas.

Revisão

Em geral, as sessões de breakout não tiveram a profundidade técnica que eu realmente aprecio como programador, mas isto fez sentido. A maior parte das sessões foram inferiores a uma hora e frequentemente de 30 minutos. É difícil entrar nos pormenores técnicos em tão pouco tempo, com uma gama tão variada de antecedentes para o público.

O conteúdo que foi apresentado nas sessões em que participei foi geralmente notável, com algumas falhas aqui e ali.

Classificação: 8/10

Pavilhão Parceiro

O Pavilhão dos Parceiros foi preenchido com empresas que oferecem serviços relacionados a empresas que podem (ou não) utilizar a MongoDB nos seus negócios. As pessoas que trabalham nestas cabines são muitas vezes vendedores que visam os decisores das suas organizações.

Aqui, tive a oportunidade de conhecer mais dos membros da equipa Linode e Akamai e de me ligar a eles. Em suma, foi óptimo ligar-me com eles uma vez que a maior parte da nossa comunicação é feita através da Internet, como imagino que um grande número dos seus clientes também o faça. Sou certamente tendencioso, mas acho a equipa da Linode/Akamai incrivelmente abordável, aberta, e mais do que disposta a fazer brainstorming de todo o tipo de ideias.

Algumas empresas chave com as quais pude conversar:

• HashiCorp: Conversar com os fabricantes de Terraform (entre outras coisas) foi óptimo para ouvir o seu empenho em tornar o DevOps melhor e mais fácil para mais pessoas. É verdade, gosto muito de usar Terraform no seu estado actual, mas o futuro parece brilhante. Talvez eu também precise de verificar os futuros eventos HashiConf!
• Vercel: Os fabricantes do Next.js foram fortemente destacados na tónica devido à sua integração recentemente anunciada com a Atlas. A seu tempo, passarei mais tempo com a sua plataforma, bem como com a Next.js!
• Universidade de MongoDB: É evidente que a educação é uma grande parte da estratégia de MongoDB que é absolutamente excitante para o futuro da educação: acessível e conduzida através de competências in-demand, práticas e comercializáveis.
• Datadog: Quem torna a análise dos registos legal? Datadog: Quem é que faz a análise dos registos? Fui arrastado para uma demonstração e estou tão contente por o ter feito. Preciso definitivamente de saber mais sobre esta empresa.

Avaliações gerais

Keynotes (discutidos acima): 7/10

• Alguns grandes altifalantes com alguns de pouco brilho

Sessões de Interrupção (discutidas mais acima): 8/10

• Globalmente grandes sessões, mas faltava-me profundidade técnica como programador

Tutoriais: 6/10

• Na principal, em que participei, havia questões wifi. Por que não cópias de segurança de ethernet com fios?
• O orador tratou das questões de forma excelente mas o conteúdo acabou por ser um pouco lento demais.

Alimentação: 3/10

• Cachorros quentes no Dia 2? A sério?
• Pizza espantosa a três quarteirões da conferência.

Amigável à família: 3/10

• Se tiver crianças com menos de 5 anos, é um 0/10.
• Para além dos destinos turísticos populares, há pouco a fazer pelas crianças pequenas.
• Nova Iorque está cheia, barulhenta, os peões andam agressivamente, e os veículos são muito agressivos.
• Sim, vivo numa pequena cidade perto de Austin, Texas, de modo que a classificação se baseia nisso. Temos muito espaço, Nova Iorque não.

Localização: 9/10

• Do ponto de vista profissional, um evento na cidade de Nova Iorque é incrível. Há muita comida fantástica, restaurantes, bares, locais, etc., para entreter e ligar com outros profissionais.
• A energia de NYC é incomparável em quase todos os lugares do mundo; algo está sempre a ser construído/reonstruído, as pessoas estão sempre fora, há quase sempre algo bom para comer.
• É espantoso como 15 milhas podem demorar mais de 2 horas a conduzir em Nova Iorque. Para alguns, isto pode baixar a classificação de localização para 3/10.
• Se não fosse patrocinado para participar, a classificação seria de 2/10 (haha!) devido ao elevado custo de tudo em Nova Iorque.

Hotéis: 5/10

• Caro para um quarto minúsculo.
• No lado positivo, o buffet do pequeno-almoço no meu hotel era estelar e ouvi o mesmo sobre outros hotéis.
• Muitas escolhas.

Aeroporto: 3/10

• Evitar o Terminal 8 em JFK a todo o custo. Está esgotado e as opções de comida/ouvenir são fracas.
• Deixar o aeroporto tem muitas opções e todas são relativamente rápidas.
• Se aterrar no terminal certo, poderá bater a 6/10.

Transporte: 7/10

• Uber/Lyft/taxis/etc, estão em todo o lado.
• O custo de transporte é elevado quando é necessário levá-lo.
• O transporte de/para o aeroporto acabou por ser quase 1/4 do custo dos meus bilhetes de avião.
• Nova Iorque é muito fácil de andar e, por isso, é muito fácil de deslocar.

Lanches de Conferência: 6/10

• Boas escolhas, muito poucas delas

Selecção de Bebidas de Conferência: 5/10

• Basicamente, os 3 grandes produtos de Coca-Cola.

Café da Conferência: 8/10

• O café café de café local era sólido, mas, mais uma vez, adoro café preto acabado de fazer, de quase qualquer lugar.

Participação da empresa: 6/10

• Eu estimaria que apareceram 20 empresas; eu esperava mais.

Swag: 3/10

• Caça ao necrófago por pântano? Giro, mas não obrigado.

Entretenimento da Conferência: 8/10

• Havia comediantes de piano em duelo no pavilhão. Eram espectaculares.
• Parecia haver alguns concursos de jogos, mas parecia limitado a alguns participantes de cada vez.
• O emcee na sala IDEA foi óptimo.
• A festa seguinte pareceu divertida para aqueles que compareceram.

Acessibilidade auditiva:

• Havia pelo menos 3 intérpretes da ASL a trabalhar nos eventos onde era necessário.
• Não consigo falar com a qualidade, mas parecia que eram óptimos.

Acessibilidade Visual: N/A

• Não procurei nem vi apoio para os deficientes visuais.

Naturalmente, a experiência de cada um vai variar muito, por isso, tome o acima referido com um grão de salt.

Classificação geral: 8/10

MongoDB World convenceu-me de que preciso de gastar 10x-100x mais tempo a usar o MongoDB. Não é pouca coisa para mim, pois devo tanto da minha carreira ao SQL e às ferramentas que com ele se integram.

Gostei do MongoDB World em geral e, se tiver a capacidade, talvez queira considerar participar em 2023. Se tiver tempo, penso que poderá ter muito tempo para participar apenas no Dia 1. Se assistir, podemos sempre assistir a sessões a pedido após o fim do evento (creio que até 30 dias). Os dias 2 e 3 ainda tinham muito a decorrer, mas a participação começou a diminuir na tarde do dia 2.

Penso que é difícil para as conferências servir todas as gamas de conhecimentos técnicos, mas penso que a MongoDB World fez um grande trabalho equilibrando isto. Muitos dos apresentadores disponibilizaram-se após as sessões para discussões mais aprofundadas, o que foi óptimo de ver. A maioria das apresentações a que assisti foram todas profissionais e bem executadas, como seria de esperar. Os participantes pareceram estar genuinamente interessados em conectar-se e aprender sobre o que os outros estão a fazer no espaço.

O Javits Conference Center em Nova Iorque foi incrível e certamente deu uma sensação grandiosa a toda a vibração do evento. A grandiosidade do centro de conferências realçou o quão patético foi realmente o meu minúsculo quarto de hotel.

A falta de comida na conferência foi compensada pelo facto de NYC ter alguns dos melhores alimentos do mundo em quase todas as esquinas de rua. Se for um apreciador de comida, talvez queira saltar durante a hora de almoço para a Hudson Yards ou para a Time Square. E, como qualquer boa conferência, o café estava a fluir!

Se estiver a pensar em trazer a sua família enquanto estiver na conferência, talvez queira reconsiderar uma vez que não há muitas crianças pequenas (5 e menos de 5 anos) que realmente possam fazer enquanto estiver ocupado no evento.

Para mim, o objectivo deste evento é ajudar a ensinar aos participantes como podem utilizar melhor o MongoDB dentro dos seus negócios. Para isso, penso que o pregaram totalmente e eu sou absolutamente vendido no MongoDB. Não esqueçamos que o SQL apareceu pela primeira vez em 1974, onde o primeiro lançamento do MongoDB foi em 2009. A diferença nesta era é clara com a abordagem moderna da MongoDB para resolver questões modernas que enfrentam organizações e projectos de cloud-first. O simples facto de esta conferência existir é prova da sua dedicação em empurrar o envelope para a frente e em trazer-nos a todos com eles.

Para MongoDB World 2023, talvez nos possamos encontrar um com o outro.

Abraço!

Justin Mitchel
Professor e Fundador
CodingForEntrepreneurs.com