Ir al contenido principal
BlogBases de datosFuimos a MongoDB World 2022, ¡para que no tuvieras que hacerlo!

Fuimos al MongoDB World 2022, ¡para que no tuvieras que hacerlo!

mongodbWorldRecap22-blogHeader

La semana pasada asistí al MongoDB World 2022 gracias a un patrocinio de Linode. En este artículo, desglosaré mi estancia allí junto con algunos fragmentos de código en los que estoy trabajando para un próximo tutorial. También he creado un vídeo que recapitula mi estancia en MongoDB World.

Mi resumen de 240 caracteres:

MongoDB World me convenció de que tengo que usar MongoDB más a menudo. El público al que se dirigía el evento era probablemente más el de los directivos que el de los desarrolladores, ya que la mayoría de las charlas (incluida la mía) no entraban en la profundidad técnica que suele gustar a los desarrolladores. Recomiendo asistir.

Ubicación: Nueva York

La ubicación del Javits Center era perfecta y el lugar era impresionante. Para una conferencia, una ciudad como Nueva York es exactamente el tipo de energía que se necesita. Hay tanta actividad en el exterior que se traslada de forma natural a la conferencia.

Valoración: 9/10

Claves

Para comenzar el evento, escuchamos al CEO de MongoDB, Dev Ittycheria. Si la única ponencia que hubiera escuchado fuera la de Dev, me habría convencido de utilizar MongoDB con mucha más frecuencia. Dev reforzó la noción de que MongoDB existe para ayudar a los equipos a entregar más con menos y, a lo largo de mi tiempo en la conferencia, esto parecía ser cierto.

A Dev le siguió rápidamente otro presentador que realmente absorbió la energía de la sala. La sensación era palpable. Dev regresó al escenario para dar un poco de la energía necesaria justo antes de que comenzaran las sesiones de trabajo.

También tuvimos unas cuantas demostraciones en vivo durante la presentación que destacaron algunas de las maravillas de MongoDB. Como se puede imaginar, las demostraciones en vivo son a menudo una receta para el desastre, pero estas se desarrollaron sin problemas, por lo que pude ver.

El primer día, por la tarde, el director de tecnología Mark Porter pronunció una de las mejores conferencias tecnológicas que he visto en persona. Está claro que primero es un profesor y luego un director de tecnología. Su ambiente era el de un instructor de un campamento de surf, mientras que sus habilidades son las de un experimentado profesional de las bases de datos que puede correr en círculos, técnicamente hablando, alrededor de la gran mayoría de los CTOs que hay. Si sólo hubiera asistido a una charla en todo el evento, habría sido la de Mark.

Me entusiasmó escuchar al orador principal del último día: Ray Kurzweil. Ray es un futurista consumado y ha hecho algunas predicciones brillantes a lo largo de su carrera. También ha escrito varios libros de gran éxito y ha dado numerosas charlas a lo largo de los años.

En MongoDB World, Ray reiteró muchas de las cosas que le he oído decir a lo largo de los años. En retrospectiva, esto no es tan sorprendente, pero sí me llevó a la conclusión de que Ray debería haber sido entrevistado por personas como Dev o Mark para proporcionar una conversación dinámica para la nota clave final.

Valoración: 7/10

Sesiones de trabajo

Las sesiones de trabajo ofrecieron una interesante visión general de las distintas herramientas y técnicas con las que los equipos aprovechan MongoDB en sus organizaciones.

Aquí hay algunos temas que me parecieron muy interesantes:

  • Reino
  • MongoDB sin servidor (Atlas Serverless)
  • Series temporales

Reino

Realm parece ser una oferta muy atractiva para permitir que los dispositivos móviles y el IOT sincronicen los datos con un clúster MongoDB gestionado (como Atlas o Linode Managed Databases).

El reto de los datos en el borde es asegurar que la base de datos local/en el dispositivo a menudo no está sincronizada con la base de datos en la nube. A primera vista, esto puede parecer un problema trivial, pero una vez que se alcanza la escala, como 100.000 dispositivos móviles, este problema puede convertirse en uno grande.

Todavía no lo he probado, pero en la sesión a la que asistí seguro que Realm de MongoDB es la solución perfecta para los diversos problemas que conlleva la sincronización de bases de datos de borde a nube.

Algunas de las principales ventajas de Realm:

  • Hecho para la sincronización dinámica de datos con MongoDB
  • Sustitución de SQLite/Core Data
  • Pequeña huella en los dispositivos
  • APIs multiplataforma (Kotlin, Swift, JavaScript, etc.)
  • Ayuda a resolver los problemas de conexión en los dispositivos móviles/IoT

Obtenga más información aquí.

MongoDB sin servidor

El término serverless es un poco tonto si me preguntas, ya que tiendo a pensar en serverless como "alojamiento a escala gestionado". Independientemente del nombre, serverless está aquí para quedarse y estoy a favor.

Serverless es el proceso de escalar sus recursos informáticos para satisfacer la demanda, sin importar lo grande o lo pequeño que sea. El tamaño es a menudo objeto de debate, pero el escalado a cero a menudo ahorra mucho en términos de recursos y, a menudo, dólares y sentido.

Vamos a plantear un escenario que ayude a resaltar los beneficios de serverless:

Escenario sin servidor: Un sitio web hace un seguimiento de las estadísticas, en tiempo real, durante los eventos deportivos.

Cuando se celebra un evento deportivo: La aplicación web tiene muchos datos de seguimiento de la actividad; la aplicación web tiene un tráfico variable en función del número de aficionados, la hora del día, el momento de la temporada, etc,; la aplicación web tiene que ser rápida para todo el mundo en cualquier lugar durante todo el evento

Cuando no hay un evento deportivo: La aplicación web hace un seguimiento cero de la actividad; la aplicación web tiene cero tráfico la mayor parte del tiempo; la aplicación web, en teoría, podría estar apagada por completo y nadie lo sabría.

No importa lo largo que sea el tiempo entre eventos, lo anterior es casi siempre cierto. La variabilidad en el funcionamiento de este sitio web teórico es un ejemplo dramático de por qué serverless es genial: Un segundo tienes 100.000 peticiones, el siguiente son ocho peticiones. Al siguiente son 250.000 peticiones, al siguiente son 76. Serverless está diseñado para manejar estos escenarios con gracia y una latencia increíble.

Bases de datos sin servidor: El sueño difícil de alcanzar

El escenario anterior funciona bien con aplicaciones web sin servidor, pero ¿qué pasa con una base de datos sin servidor también?

Las aplicaciones web modernas, con o sin servidor, necesitan la capacidad de acceder a los datos con la menor latencia posible. Si la base de datos es sin servidor, esto significa que puede ser escalada a cero instancias en ejecución o simplemente la base de datos puede ser esencialmente apagada. Por lo tanto, si la base de datos se apaga, habrá un retraso en volver a encenderla; lo que hace que el serverless en la capa de base de datos sea tradicionalmente muy difícil de hacer.

El problema de escalar o reducir las bases de datos tiene que ver con el tamaño de los datos; más datos significa que va a tomar más tiempo para encender o apagar una base de datos. Históricamente, es mucho más fácil y sin fricciones mantener los servicios de la base de datos en funcionamiento todo el tiempo mientras tu aplicación puede ser sin servidor (o no) gracias a Kubernetes y varias implementaciones de Docker.

Todavía no he visto una alternativa SQL sin servidor que iguale lo que hace Atlas Serverless, y esto no es un pequeño logro del equipo de MongoDB. Es genial verles ser pioneros en las bases de datos sin servidor.

Lo que no vi fue el soporte para MongoDB de código abierto sin servidor. Quizás eso también esté por llegar.

Sin servidor: Velocidad, coste y fricción

Cuanto más rápido pueda desplegar las aplicaciones, más rápido podré aprender lo que funciona y lo que no. Serverless desbloquea la capacidad de hacer este tipo de pruebas con un aumento mínimo en el costo para hacerlo. Esto, yo diría, es uno de los mayores beneficios de usar serverless.

Si tu aplicación no funciona, déjala ahí pero sin recursos en funcionamiento. A la primera señal de tráfico, escale para satisfacer la demanda. Reduzca la escala cuando la demanda disminuya. Esto se alinea perfectamente con la realización de pruebas de publicidad A/B para que tu aplicación funcione cuando sea necesario y no todo el tiempo.

Si tu aplicación funciona y funciona bien, la sobrecarga de mantener la carga continua se abstrae de tu equipo mediante varios servicios gestionados. Esto significa que un equipo pequeño puede manejar una cantidad increíble de carga con muy poco (o ningún) trabajo extra.

Todo esto viene a decir que el serverless aumenta la eficacia de los equipos a la vez que reduce el coste global que supone gestionar los requisitos de demanda de esa aplicación.

La tecnología sin servidor no es una solución perfecta para todo, pero sin duda resuelve muchos problemas de los equipos con recursos limitados.

Series temporales en MongoDB

MongoDB (al menos desde la versión 5), tiene soporte para funciones incorporadas para hacer análisis de series temporales. Si no está familiarizado con la creación de datos de series temporales, es simplemente el proceso de añadir algún tipo de marca de tiempo a cada fila de su colección de base de datos (tabla).

El Análisis de Series Temporales es ideal para:

  • Mejora de las decisiones financieras que requieren previsiones de ventas, demanda de productos, estimaciones de tráfico, etc.
  • Compra de acciones, bonos, etc.
  • Seguimiento de sensores y dispositivos IoT a lo largo del tiempo.
  • Métricas de rendimiento (como el rendimiento del sitio web, la publicidad, etc.)

Ciertamente hay muchas más aplicaciones para este tipo de análisis, pero como vemos el uso de datos de series temporales es fundamental para muchos roles en una organización. MongoDB hace que hacer este análisis sea mucho más fácil. En el futuro hablaré más sobre el análisis de series temporales con MongoDB, pero por ahora, aquí hay un ejemplo rápido usando MongoDB con el paquete Python pymongo:

1. Inicializar el 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. Crear la colección de series temporales

# 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. Añadir datos de series temporales 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 las agregaciones de las series temporales

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

Esto da como resultado:

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

Los datos anteriores proceden de mi propia experimentación con Python y MongoDB, pero se inspiraron en gran medida en una sesión en la que se hablaba de utilizar el análisis de series temporales de MongoDB para automatizar la compra de acciones basándose en los precios históricos. La charla no fue una inmersión profunda técnicamente porque, como puedes ver arriba, ¡realmente no tenía que serlo! MongoDB ciertamente parece reducir la fricción para hacer algunas cosas sorprendentes.

Revise

En general, las sesiones de trabajo carecían de la profundidad técnica que me gusta como desarrollador, pero esto tenía sentido. La mayoría de las sesiones duraron menos de una hora y a menudo 30 minutos. Es difícil profundizar en los detalles técnicos en tan poco tiempo y con un público tan variado.

El contenido que se presentó en las sesiones a las que asistí fue en general sobresaliente, con algunos fallos aquí y allá.

Valoración: 8/10

Pabellón de socios

El Pabellón de Socios estaba lleno de empresas que ofrecen servicios relacionados con empresas que pueden (o no) utilizar MongoDB en su negocio. Las personas que trabajaban en estos stands solían ser vendedores que se dirigían a los responsables de la toma de decisiones de sus organizaciones.

Aquí tuve la oportunidad de conocer a más miembros del equipo de Linode y Akamai y conectar con ellos. En resumen, fue estupendo conectar con ellos, ya que la mayor parte de nuestra comunicación se realiza a través de Internet, como me imagino que hacen también un gran número de sus clientes. Sin duda soy parcial, pero el equipo de Linode/Akamai me parece increíblemente accesible, abierto y más que dispuesto a aportar todo tipo de ideas.

Algunas empresas clave con las que pude charlar:

  • HashiCorp: Hablar con los creadores de Terraform (entre otras cosas) fue genial para escuchar su compromiso de hacer DevOps mejor y más fácil para más personas. Por supuesto, me gusta mucho usar Terraform en su estado actual, pero el futuro parece brillante. Tal vez tenga que ir a los futuros eventos de la HashiConf también.
  • Vercel: Los creadores de Next.js tuvieron un gran protagonismo en la keynote debido a su recientemente anunciada integración con Atlas. A su debido tiempo, pasaré más tiempo con su plataforma, así como con Next.js.
  • Universidad MongoDB: Está claro que la educación es una parte importante de la estrategia de MongoDB, lo que nos entusiasma por el futuro de la educación: accesible e impulsada a través de habilidades demandadas, prácticas y comercializables.
  • Datadog: ¿Quién hace que el análisis de los registros sea genial? Datadog. Me llevaron a una demostración y estoy muy contento de haberlo hecho. Definitivamente tengo que aprender más sobre esta empresa.

Clasificaciones generales

Notas clave (comentadas anteriormente): 7/10

  • Algunos grandes oradores con otros deslucidos

Sesiones de trabajo (más arriba): 8/10

  • En general, grandes sesiones, pero faltó la profundidad técnica que me gusta como desarrollador

Tutoriales: 6/10

  • En el principal al que asistí, hubo problemas de wifi. ¿Por qué no hay copias de seguridad por cable?
  • El orador manejó los temas muy bien, pero el contenido terminó siendo demasiado lento.

Comida: 3/10

  • ¿Perritos calientes en el segundo día? ¿De verdad?
  • Una pizza increíble a tres manzanas de la conferencia.

Para familias: 3/10

  • Si tienes niños menores de 5 años, es un 0/10.
  • Aparte de los destinos turísticos populares, hay poco que hacer para los niños pequeños.
  • Nueva York está abarrotada, es ruidosa, los peatones caminan con agresividad y los vehículos son muy agresivos.
  • Sí, vivo en una pequeña ciudad cerca de Austin, Texas, por lo que la calificación se basa en eso. Tenemos mucho espacio, Nueva York no.

Ubicación: 9/10

  • Desde el punto de vista profesional, un evento en la ciudad de Nueva York es increíble. Hay mucha comida, restaurantes, bares, locales, etc., para entretenerse y conectar con otros profesionales.
  • La energía de Nueva York es incomparable a la de casi todos los lugares del mundo; siempre se está construyendo/reconstruyendo algo, la gente siempre está fuera, casi siempre hay algo bueno que comer.
  • Es increíble cómo 15 millas pueden tomar más de 2 horas de conducción en la ciudad de Nueva York. Para algunos, esto podría bajar la calificación de la ubicación a 3/10.
  • Si no me patrocinaran para asistir, la valoración sería de 2/10 (¡jaja!) debido al elevado coste de todo en Nueva York.

Hoteles: 5/10

  • Caro para una habitación diminuta.
  • En el lado positivo, el buffet de desayuno en mi hotel era estelar y escuché lo mismo sobre otros hoteles.
  • Un montón de opciones.

Aeropuerto: 3/10

  • Evite la Terminal 8 del aeropuerto JFK a toda costa. Está deteriorada y las opciones de comida/souvenir son escasas.
  • Salir del aeropuerto tiene muchas opciones y todas son relativamente rápidas.
  • Si aterrizara en la terminal correcta, podría subir a 6/10.

Transporte: 7/10

  • Uber/Lyft/taxis/etc, están por todas partes.
  • El coste del transporte es elevado cuando hay que cogerlo.
  • El transporte hacia y desde el aeropuerto acabó costando casi 1/4 del coste de mis billetes de avión.
  • Nueva York es una ciudad muy transitable y, por tanto, fácil de recorrer.

Aperitivos de la conferencia: 6/10

  • Buenas opciones, muy pocas

Selección de bebidas de la conferencia: 5/10

  • Básicamente los 3 grandes productos de Coca-Cola.

Café de la Conferencia: 8/10

  • El café elaborado localmente era sólido, pero de nuevo me encanta el café negro recién hecho de casi cualquier lugar.

Participación de la empresa: 6/10

  • Calculo que se presentaron unas 20 empresas; esperaba más.

Swag: 3/10

  • ¿Caza del tesoro para conseguir un botín? Bonito, pero no gracias.

Entretenimiento en la conferencia: 8/10

  • Había comediantes de duelo de piano en el pabellón. Eran increíbles.
  • Parecía que había algunas competiciones de juegos, pero parecían limitadas a unos pocos participantes a la vez.
  • El presentador de la sala de IDEA fue genial.
  • La fiesta posterior sonó divertida para los que asistieron.

Accesibilidad auditiva:

  • Hubo al menos 3 intérpretes de ASL trabajando en los eventos cuando fue necesario.
  • No puedo hablar de la calidad, pero parecía que estaban muy bien.

Accesibilidad visual: N/A

  • No busqué ni vi apoyo para los discapacitados visuales.

Naturalmente, la experiencia de cada uno va a variar mucho, así que tómese lo anterior con un grano de salt.

Calificación general: 8/10

MongoDB World me convenció de que necesito pasar 10x-100x más tiempo usando MongoDB. Eso no es poca cosa para mí, ya que debo gran parte de mi carrera a SQL y a las herramientas que se integran con él.

Disfruté de MongoDB World en general y, si tienes la posibilidad, podrías considerar asistir en 2023. Si tienes poco tiempo, creo que puedes sacar mucho provecho de asistir sólo al primer día. Si asistes, siempre puedes ver/revisar las sesiones a la carta una vez finalizado el evento (creo que hasta 30 días). En los días 2 y 3 hubo muchas actividades, pero la asistencia empezó a disminuir por la tarde del día 2.

Creo que es difícil que las conferencias sirvan para todos los rangos de experiencia técnica, pero creo que MongoDB World hizo un gran trabajo para equilibrar esto. Muchos de los conferenciantes se pusieron a disposición de los asistentes después de las sesiones para que pudieran debatir en profundidad, lo que fue estupendo. La mayoría de las presentaciones a las que asistí fueron profesionales y bien ejecutadas, como era de esperar. Los asistentes parecían realmente interesados en conectarse y aprender sobre lo que otros están haciendo en el espacio.

El Centro de Conferencias Javits de Nueva York era increíble y ciertamente daba una sensación de grandeza a todo el ambiente del evento. La grandeza del centro de conferencias puso de manifiesto lo patética que era mi pequeña habitación de hotel.

La escasa comida de la conferencia se compensó con el hecho de que Nueva York tiene una de las mejores comidas del mundo en casi todas las esquinas. Si eres un amante de la comida, quizá quieras ir a Hudson Yards o a Time Square a la hora de comer. Y, como en toda buena conferencia, el café era abundante.

Si está pensando en traer a su familia mientras está en la conferencia, tal vez quiera reconsiderarlo, ya que no hay mucho que los niños pequeños (5 y menores) puedan hacer realmente mientras usted está ocupado en el evento.

Para mí, el punto de este evento es ayudar a enseñar a los asistentes cómo pueden utilizar mejor MongoDB dentro de su negocio. En este sentido, creo que lo han conseguido y estoy absolutamente convencido de MongoDB. No olvidemos que SQL apareció por primera vez en 1974 mientras que el primer lanzamiento de MongoDB fue en 2009. La diferencia en esta época es clara con el enfoque moderno de MongoDB para resolver los problemas modernos a los que se enfrentan las organizaciones y los proyectos cloud-first. El mero hecho de que esta conferencia exista es un testimonio de su dedicación para impulsar el desarrollo y llevarnos a todos con ellos.

Para el MongoDB World 2023, quizás podamos conocernos.

¡Salud!

Justin Mitchel
Profesor y fundador
CodingForEntrepreneurs.com


Comentarios

Dejar una respuesta

Su dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *.