Participei da MongoDB World 2022 na semana passada, graças a um patrocínio da Linode. Neste artigo, vou dividir meu tempo lá junto com alguns trechos de código em que estou trabalhando para um próximo tutorial. Eu também criei um vídeo recapitulando meu tempo na MongoDB World.
Meu resumo de 240 caracteres:
MongoDB World me convenceu de que preciso usar o MongoDB com mais freqüência. O público-alvo era provavelmente os gerentes sobre os desenvolvedores, já que a maioria das conversas (incluindo a minha própria) não entrava no aprofundamento técnico como muitas vezes acontece. Eu recomendo participar!
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 é exatamente o tipo de energia que você precisa. Há tanta coisa acontecendo fora dela que, naturalmente, sangra para dentro da conferência.
Classificação: 9/10
Keynotes
Para dar início ao evento, ouvimos do CEO da MongoDB, Dev Ittycheria. Se a única nota-chave que ouvi foi a de Dev, eu teria sido vendido usando MongoDB significativamente mais vezes. Dev reforçou a noção de que o MongoDB existe para ajudar a capacitar as equipes a entregar mais com menos e, durante todo o meu tempo na conferência, isto pareceu ser verdade.
Dev foi rapidamente seguido por outro apresentador que realmente sugou a energia para fora da sala. A sensação era palpável. Dev retornou ao palco para dar alguma energia muito necessária logo antes do início das sessões de abertura.
Também tivemos algumas demonstrações ao vivo durante a palestra principal que destacou algumas das maravilhas que é MongoDB. Como você pode imaginar, as demonstrações ao vivo são muitas vezes uma receita para o desastre, mas estas foram bem sucedidas, tanto quanto pude perceber.
À tarde, no primeiro dia, o CTO Mark Porter entregou uma das melhores notas-chave tecnológicas que eu já vi pessoalmente. É claro que ele é primeiro um professor e segundo um CTO. Sua vibração era a de um instrutor de surf, enquanto seu conjunto de habilidades é de um profissional experiente em banco de dados que pode dirigir círculos, tecnicamente falando, em torno 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 ao ouvir o orador principal do último dia: Ray Kurzweil. Ray é um futurista realizado e fez algumas previsões brilhantes ao longo de 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 eu o ouvi dizer ao longo dos anos. Em retrospectiva, isto não é tão surpreendente, mas me levou à conclusão de que Ray deveria ter sido entrevistado por pessoas como Dev ou Mark para proporcionar uma conversa dinâmica para a conclusão.
Classificação: 7/10
Sessões de Intervalo
As sessões de breakout proporcionaram visões interessantes das várias ferramentas e técnicas que as equipes da MongoDB utilizam em suas organizações.
Aqui estão alguns tópicos que achei muito interessantes:
- Realm
- MongoDB sem servidor (Atlas Serverless)
- Série cronológica
Realm
Realm parece ser uma oferta muito convincente para permitir que dispositivos móveis e IOT sincronizem dados com um Cluster MongoDB gerenciado (como o Atlas ou Linode Managed Databases).
O desafio com dados no limite é garantir que o banco de dados local/em-dispositivo esteja muitas vezes fora de sincronia com o banco de dados das nuvens. De relance, isto pode parecer uma questão trivial, mas uma vez atingida a escala, como 100.000 dispositivos móveis, este problema pode se tornar um grande problema.
Ainda não o testei, mas a sessão em que participei fez do Reino de MongoDB a solução perfeita para os vários problemas que vêm com a sincronização de banco de dados de ponta a ponta.
Alguns benefícios chave 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 problemas de conexão em dispositivos móveis/IoT
Saiba mais sobre isso aqui.
MongoDB sem servidor
O termo serverless é um pouco idiota se você me perguntar, pois tenho a tendência de pensar em serverless como "hospedagem gerenciada em escala". Independentemente do nome, o serverless está aqui para ficar e eu sou a favor dele.
Serverless é o processo de dimensionar seus recursos computacionais para atender à demanda, não importa o quão grande ou pequeno seja. O quão grande é muitas vezes motivo de debate, mas o redimensionamento para zero muitas vezes economiza muito em termos de recursos e muitas vezes dólares e bom senso.
Vamos traçar um cenário que ajude a destacar os benefícios do servidor sem servidor:
Cenário sem servidor: Um site acompanha as estatísticas, em tempo real, durante eventos esportivos.
Quando um evento esportivo está acontecendo: A aplicação web tem muitos dados de rastreamento de atividades; a aplicação web tem tráfego variável baseado no número de torcedores, hora do dia, ponto na temporada, etc.; a aplicação web precisa ser rápida para todos em todos os lugares durante todo o evento
Quando um evento esportivo não está acontecendo: A aplicação web faz o rastreamento de atividade zero; a aplicação web tem tráfego zero na maioria das vezes; a aplicação web, em teoria, poderia estar completamente desligada e ninguém saberia.
Não importa quanto tempo haja entre os eventos, o acima exposto é quase sempre verdade. A variabilidade de como este site teórico funciona é um exemplo dramático de porque o serverless é ótimo: Num segundo você tem 100.000 solicitações, no outro são oito solicitações. No seguinte, são 250.000 solicitações, no seguinte, são 76 solicitações. O serverless é projetado para lidar com estes cenários com graça e uma latência incrível.
Bancos de dados sem servidor: O Sonho Elusivo
O cenário acima funciona bem com aplicações web sem servidor, mas o que dizer de um banco de dados sem servidor também?
Aplicações web modernas, sem servidor ou não, precisam da capacidade de acessar dados com a latência mais baixa possível. Se o banco de dados estiver sem servidor, isto significa que ele pode ser escalado para zero instâncias em execução ou simplesmente o banco de dados pode ser essencialmente desativado. Portanto, se o banco de dados for desligado, haverá um atraso para ligá-lo novamente; assim, tornando o servidor sem servidor na camada de banco de dados tradicionalmente muito difícil de fazer.
O problema de aumentar ou diminuir a escala dos bancos de dados lida com o tamanho dos dados; mais dados significa que vai demorar mais tempo para ligar ou desligar um banco de dados. Historicamente, é muito mais fácil e sem atritos manter seus serviços de banco de dados funcionando o tempo todo enquanto sua aplicação pode ser sem servidor (ou não) graças à Kubernetes e várias implementações do Docker.
Ainda não vi uma alternativa SQL Serverless que corresponda ao que a Atlas Serverless faz, e isto não é uma pequena realização da equipe MongoDB. É ótimo vê-los bancos de dados sem servidor pioneiros.
O que eu não vi foi suporte para MongoDB sem servidor de código aberto. Talvez isso também esteja vindo.
Sem servidor: Velocidade, custo e fricção
Quanto mais rápido eu posso implantar aplicações, mais rápido eu posso aprender o que está funcionando e o que não está. O Serverless desbloqueia a capacidade de fazer estes tipos de testes com aumentos mínimos no custo para fazê-lo. Este, eu diria, é um dos maiores benefícios do uso do serverless.
Se seu aplicativo não estiver funcionando, deixe-o ali, mas com zero recursos funcionando. Ao primeiro sinal de tráfego, escalar para atender a demanda. Reduza a escala quando a demanda se desvanecer. Isto se alinha perfeitamente com fazer testes de publicidade A/B para que seu aplicativo possa estar funcionando quando for necessário e não o tempo todo.
Se seu aplicativo estiver funcionando e funcionando bem, a sobrecarga na manutenção da carga contínua é abstraída de sua equipe por vários serviços gerenciados. Isto significa que uma pequena equipe pode lidar com uma quantidade incrível de carga com muito pouco (se houver) trabalho extra.
Tudo isso para dizer que o servidor sem servidor aumenta a eficácia das equipes enquanto reduz o custo total necessário para lidar com os requisitos de demanda para aquela aplicação.
O Serverless não é uma solução perfeita para tudo, mas certamente resolve tantos problemas com equipes com recursos limitados.
Série cronológica em MongoDB
MongoDB (pelo menos a partir da versão 5), tem suporte para funções incorporadas para fazer análises de série temporal. Se você 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 de sua coleção de banco de dados (tabela).
A Análise de Séries Temporais é ótima para:
- Melhoria das decisões financeiras que requerem previsão de vendas, demanda de produtos, estimativas de tráfego, etc.
- Compra de Ações, Títulos, etc.
- Sensores de rastreamento e dispositivos IoT ao longo do tempo.
- Métricas de desempenho (tais como desempenho do website, publicidade, etc.)
Certamente há muito mais aplicações para este tipo de análise, mas como vemos, o uso de dados da série temporal é crítico para muitas funções em uma organização. O MongoDB torna esta análise muito mais fácil. Vou tocar muito mais na Análise de Série Temporal com o MongoDB no futuro, mas por enquanto, aqui está uma amostra rápida usando o MongoDB com o pacote pymongo 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 coleçã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 de minhas próprias experiências com Python e MongoDB, mas foram inspirados em grande parte por uma sessão sobre o uso da Análise da Série Temporal MongoDB para automatizar as ações de compra com base nos preços históricos. A palestra não foi um mergulho profundo tecnicamente porque, como você pode ver acima, realmente não precisava ser! A MongoDB certamente parece diminuir o atrito em fazer algumas coisas incríveis.
Revisão
De modo geral, as sessões de breakout não tiveram a profundidade técnica que eu realmente aprecio como desenvolvedor, mas isto fez sentido. A maioria das sessões era de menos de uma hora e muitas vezes de 30 minutos. É difícil entrar nas porcas e parafusos nos detalhes técnicos em tão pouco tempo, com uma variedade tão grande de antecedentes para o público.
O conteúdo que foi apresentado nas sessões em que participei foi geralmente excelente, com algumas falhas aqui e ali.
Classificação: 8/10
Pavilhão de parceiros
O Pavilhão dos Parceiros foi preenchido com empresas que oferecem serviços relacionados a empresas que podem (ou não) usar MongoDB em seus negócios. As pessoas que trabalham nestes estandes são muitas vezes vendedores, visando os tomadores de decisão para suas organizações.
Aqui, tive a oportunidade de conhecer mais dos membros da equipe Linode e Akamai e me conectar com eles. Em resumo, foi ótimo conectar-se com eles, já que a maior parte de nossa comunicação é feita pela Internet, como imagino que um grande número de seus clientes também faça. Certamente sou tendencioso, mas acho a equipe da Linode/Akamai incrivelmente acessível, aberta e mais do que disposta a fazer brainstorming de todos os tipos de idéias.
Algumas empresas chave com as quais pude conversar:
- HashiCorp: Conversar com os fabricantes de Terraform (entre outras coisas) foi ótimo para ouvir seu compromisso de tornar o DevOps melhor e mais fácil para mais pessoas. É verdade, gosto muito de usar Terraform em seu estado atual, mas o futuro parece brilhante. Talvez eu precise conferir os futuros eventos da HashiConf também!
- Vercel: Os fabricantes do Next.js tiveram uma grande participação na palestra principal devido a sua integração recentemente anunciada com a Atlas. No devido tempo, estarei passando mais tempo com sua plataforma, bem como com o Next.js!
- Universidade de MongoDB: É claro 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 habilidades in-demand, práticas e comercializáveis.
- Datadog: Quem torna legal a análise de logs? Datadog: Quem é quem. Eu fui puxado para uma demonstração e estou tão feliz de ter feito. Eu definitivamente preciso aprender mais sobre esta empresa.
Avaliações gerais
Notas-chave (discutidas acima): 7/10
- Alguns grandes alto-falantes com alguns de pouco brilho
Sessões de Intervalo (discutidas mais acima): 8/10
- No geral, grandes sessões, mas sem profundidade técnica, eu gosto como desenvolvedor.
Tutoriais: 6/10
- No principal que eu participei, havia questões de wifi. Por que não backups de ethernet com fio?
- O orador tratou muito bem das questões, mas o conteúdo acabou sendo um pouco lento demais.
Alimentos: 3/10
- Cachorro-quente no Dia 2? Sério?
- Uma pizza incrível a três quarteirões da conferência.
Amigável à família: 3/10
- Se você tem filhos menores de 5 anos, é um 0/10.
- Além dos destinos turísticos populares, há pouco o que fazer para as crianças pequenas.
- Nova York está lotada, barulhenta, os pedestres andam agressivamente e os veículos são muito agressivos.
- Sim, vivo em uma pequena cidade perto de Austin, Texas, de modo que a classificação se baseia nisso. Temos muito espaço, Nova Iorque não tem.
Localização: 9/10
- Do ponto de vista profissional, um evento na cidade de Nova York é incrível. Há muita comida ótima, restaurantes, bares, locais, etc., para entreter e se conectar com outros profissionais.
- A energia de NYC é inigualável em quase todos os lugares do mundo; algo está sempre sendo construído/reonstruído, as pessoas estão sempre fora, há quase sempre algo bom para comer.
- É incrível como 15 milhas podem levar mais de 2 horas de carro na cidade de Nova York. Para alguns, isto pode baixar a classificação de localização para 3/10.
- Se eu não fosse patrocinado para participar, a classificação seria de 2/10 (haha!) devido ao alto custo de tudo em Nova York.
Hotéis: 5/10
- Caro para um quarto minúsculo.
- No lado positivo, o buffet de café da manhã no meu hotel era estelar e ouvi o mesmo sobre outros hotéis.
- Muitas escolhas.
Aeroporto: 3/10
- Evite o Terminal 8 no JFK a todo custo. Está esgotado e as opções de alimentos/ouvenir são pobres.
- Deixar o aeroporto tem muitas opções e todas são relativamente rápidas.
- Se eu aterrisse no terminal certo, ele poderia chocar-se com 6/10.
Transporte: 7/10
- Uber/Lyft/taxis/etc, estão em toda parte.
- O custo de transporte é alto quando você precisa levá-lo.
- O transporte de/para o aeroporto acabou sendo de quase 1/4 do custo das minhas passagens aéreas.
- Nova York é muito fácil de se locomover, portanto, é fácil de se locomover.
Lanches de Conferência: 6/10
- Boas escolhas, muito poucas delas
Seleção de bebidas para conferência: 5/10
- Basicamente, os 3 grandes produtos de coque.
Café da Conferência: 8/10
- O café café café extraído localmente era sólido, mas depois novamente eu adoro café preto extraído recentemente de quase qualquer lugar.
Participação da empresa: 6/10
- Eu estimaria que 20 empresas apareceram; eu estava esperando mais.
Swag: 3/10
- Caça ao tesouro? Bonito, mas não obrigado.
Entretenimento da Conferência: 8/10
- Havia comediantes de piano em duelo no pavilhão. Eles eram incríveis.
- Parecia que havia algumas competições de jogos, mas parecia limitado a poucos participantes de cada vez.
- O emcee no salão IDEA foi ótimo.
- A pós-festa pareceu divertida para aqueles que compareceram.
Acessibilidade Auditiva:
- Havia pelo menos 3 intérpretes da ASL trabalhando nos eventos onde era necessário.
- Não posso falar com a qualidade, mas parecia que eram ótimos.
Acessibilidade visual: N/A
- Eu não procurei ou vi apoio para os deficientes visuais.
Naturalmente, a experiência de cada um vai variar muito, por isso, pegue o acima com um grão de salt.
Classificação geral: 8/10
MongoDB World me convenceu de que preciso gastar 10x-100x mais tempo usando MongoDB. Não é pouca coisa para mim, pois devo tanto da minha carreira ao SQL e às ferramentas que se integram com ele.
Gostei da MongoDB World em geral e, se você tiver essa capacidade, talvez queira considerar participar em 2023. Se você estiver pressionado pelo tempo, eu acho que você pode conseguir muito tempo para participar apenas do Dia 1. Se você comparecer, podemos sempre assistir a sessões sob demanda após o término do evento (acredito que por até 30 dias). Os dias 2 e 3 ainda tinham muita coisa acontecendo, mas o comparecimento começou a diminuir na tarde do dia 2.
Acho que é difícil para as conferências servir a todas as faixas de especialização técnica, mas acho que a MongoDB World fez um ótimo trabalho equilibrando isso. Muitos dos palestrantes se disponibilizaram após as sessões para discussões mais aprofundadas, o que foi ótimo de se ver. A maioria das apresentações que participei foram todas profissionais e bem executadas, como seria de se esperar. Os participantes pareceram genuinamente interessados em se conectar e aprender sobre o que os outros estão fazendo no espaço.
O Javits Conference Center em Nova York foi incrível e certamente deu uma grande sensação a toda a vibração do evento. A grandiosidade do centro de conferências realmente destacou o quão patético foi meu minúsculo quarto de hotel.
A falta de alimentos na conferência foi compensada pelo fato de NYC ter alguns dos melhores alimentos do mundo em quase todas as esquinas. Se você for um gourmet, talvez queira saltar durante a hora do almoço para a Hudson Yards ou até a Time Square. E, como qualquer boa conferência, o café estava fluindo!
Se você estiver pensando em trazer sua família enquanto estiver na conferência, talvez queira reconsiderar, já que não há muita coisa que crianças pequenas (5 ou menos) possam realmente fazer enquanto você estiver ocupado no evento.
Para mim, o objetivo deste evento é ajudar a ensinar aos participantes como podem utilizar melhor a MongoDB dentro de seus negócios. Para isso, acho que eles conseguiram e eu sou absolutamente vendido na MongoDB. Não esqueçamos que o SQL apareceu pela primeira vez em 1974, onde o primeiro lançamento da MongoDB foi em 2009. A diferença nesta era é clara com a abordagem moderna da MongoDB para resolver problemas modernos que enfrentam organizações e projetos que primeiro se transformam em nuvens. O simples fato de esta conferência existir é uma prova de sua dedicação em empurrar o envelope para frente e nos trazer a todos com eles.
Para MongoDB World 2023, talvez possamos nos encontrar.
Abraço!
Justin Mitchel
Professor e Fundador
CodingForEntrepreneurs.com
Comentários