El Edge y las Bases de Datos: Todo en Todas Partes al Mismo Tiempo

Hola a todos. Es bueno verlos aquí. Y también ponerle cara a los nombres de las personas con las que suelo interactuar en Twitter y espero también después de la conferencia.

Como mencionó Ryan Darl en la charla anterior, ya saben, cuando envías una charla, generalmente solo envías algo. Y luego se me ocurrió un mejor título, que es, Edge y Bases de Datos. Todo, en todas partes y todo al mismo tiempo. En esta charla, hablaremos sobre qué significa trabajar con bases de datos en el Edge y cómo exactamente puedes usarlas si así lo deseas.

Sí. Así que mi nombre es Alex y soy un JavaScript... Oh, adicto. Lo siento. Sesión equivocada. Soy un Defensor del Desarrollador en Prisma, donde, como mencionó Kevin amablemente, trabajo en enseñarles cómo hacer que trabajar con bases de datos sea fácil para los desarrolladores. Como empresa, hemos intensificado nuestros esfuerzos en comprender el ecosistema serverless, especialmente cuando se trata de trabajar con bases de datos, para poder proporcionar herramientas que ofrezcan la mejor experiencia para ustedes como desarrolladores. Y una de ellas es Accelerate, que lanzamos hace un par de meses y que te permite almacenar en caché las respuestas de tus consultas a la base de datos... Sí, las respuestas de tus consultas a la base de datos en el Edge o a nivel global.

Esta charla se dividirá en cuatro secciones. En la primera sección, repasaremos el pasado y entenderemos cómo llegamos hasta aquí en el Edge y luego, en el segundo segmento, hablaré sobre el Edge, qué es, las limitaciones y cómo puedes superar esas limitaciones en relación a las bases de datos. Y luego, en la tercera parte, te mostraré una demostración de una herramienta que construí para mostrarte cómo sería con la solución que hemos construido. Y luego concluiremos con algunas reflexiones finales y si tienes preguntas, no dudes en hacerlas después de la conclusión. Así que empecemos. ¿Cómo llegaste realmente hasta aquí? Bueno, la implementación de aplicaciones ha recorrido un largo camino. Y a veces, cuando hablo de estas tecnologías, puedo parecer joven, pero tengo la mente de una persona de 56 años. Así que espero que tú tampoco te sientas viejo realmente. Um, en el pasado. Eones atrás, incluso antes de que comenzara a aprender a usar computadoras, la mayoría de los equipos y empresas solían implementar sus aplicaciones en una computadora que solía estar en el sótano, por ejemplo, el sótano es solo un ejemplo. Y esto funcionaba bien. Y los desarrolladores o equipos de DevOps eran responsables de administrar todo el proceso. Y el servidor de la aplicación vivía junto con tu base de datos, lo cual era ideal. Y luego, en 2006, Amazon o, um, infraestructura como servicio comenzó a existir.

Y esto cambió la responsabilidad de tener que pensar en las computadoras y simplemente dejarlo todo en manos de Amazon. Y luego, unos años después, comenzamos a ver el surgimiento de plataformas como servicio, lo que transfirió más responsabilidad donde tenías que preocuparte menos por la computadora en la que se ejecuta tu aplicación y simplemente dejar eso en manos de tu proveedor de la nube. Y luego, unos años después, nuevamente, vimos el surgimiento de funciones como servicio con AWS Lambda, um, en la nube. No puedo pensar en otros ejemplos en este momento, pero fue genial porque nos preocupamos menos por nuestros servidores. Y nos enfocamos únicamente en construir el código que ejecuta nuestras aplicaciones. Y esto fue genial porque podías escalar tu aplicación casi infinitamente porque, en caso de que haya un aumento repentino de tráfico en tu aplicación, puedes escalar hasta tener 1,000 instancias de funciones ejecutándose al mismo tiempo.

Y luego, en caso de que no haya tráfico, se reduciría a cero y solo pagarías por lo que realmente uses en lugar de tener un servidor en funcionamiento durante mucho tiempo. Pero esto trajo algunos desafíos, especialmente cuando se trataba de trabajar con bases de datos relacionales. En esta charla, hablaré sobre tres desafíos concretos que, um, bueno, los desarrolladores y los equipos experimentaron. Y el más grande de todos ellos fue la gestión de conexiones y cómo manejar las conexiones a tu base de datos. Tomemos como ejemplo una función, que está representada por este hermoso OVNI aquí. Um, si tu función tuviera que interactuar con la base de datos y estás utilizando un generador de consultas o un conector de base de datos, si sigues la configuración predeterminada, es probable que se abran múltiples conexiones. Y esto está bien si tienes un solo Lambda que se ejecuta una vez cada mucho tiempo, porque tu base de datos estaría bastante relajada, pero el desafío principal surge cuando tienes un aumento repentino de tráfico y tienes un enjambre completo de Lambdas.

Y no uno o dos, tres, tantos cuatro, sino un enjambre completo. Y en este caso, tu base de datos está en un estado de pánico porque generalmente tiene un número limitado de conexiones en un momento dado. Y antes de que te des cuenta, te quedarás sin conexiones y tus datos y tus funciones comenzarán a generar errores y fallarán. Y esto no es ideal porque lamentablemente tu base de datos no puede escalar junto con tus funciones en el entorno serverless. Otros problemas que aún experimentamos con serverless incluyen los tiempos de espera de las funciones, lo cual no es ideal para trabajar con procesos de larga duración. Por ejemplo, si tienes una operación por lotes que tarda una hora en completarse, la mayoría de los proveedores de la nube suelen tener un tiempo establecido de cuánto tiempo debe ejecutarse tu función, lo cual no es ideal si tienes un proceso que dura mucho tiempo. Otro desafío con el que todavía nos encontramos es el inicio en frío, lo cual afecta la latencia de tu función y no brinda una experiencia óptima para tus usuarios. Pero no todo es tan malo porque encontramos soluciones y eso es genial, porque impulsa la innovación. Y una de ellas fue establecer el tamaño del grupo de conexiones al conectarse a tu base de datos en uno. Entonces, en lugar de tener múltiples conexiones, puedes limitarlo a solo una. Sin embargo, esto no es ideal, porque si tienes, por ejemplo, una operación por lotes que inserta mil registros, entonces se ejecutarían de forma secuencial en lugar de paralela, lo que lo hace un poco lento. Eso está bien. Tenemos otra posibilidad, que es definir un límite de concurrencia. Entonces, en caso de que haya un aumento repentino de tráfico, tu proveedor de la nube generalmente establece cuántas Lambdas puedes ejecutar en un momento dado. Entonces, en este caso, puedes ir a tu consola de AWS, por ejemplo, y luego puedes limitar en lugar de tener 100 Lambdas ejecutándose simultáneamente, puedes tener, digamos, 10 o 20 en cualquier momento. Pero la solución más robusta de todas es utilizar un grupo de conexiones externo como PG Bouncer, que se encargará de administrar todas las conexiones que van a tu base de datos.

Entonces, en este caso, no te quedarías sin conexiones porque tiene un registro de cuántas conexiones puede proporcionar en cualquier momento dado. Con todas estas innovaciones, nos llevó al edge, que es como una nueva era en cierto sentido, porque el edge, en este caso, es una forma de computación serverless que te permite ejecutar tus aplicaciones lo más cerca posible de tus usuarios.

Entonces, en este caso, una vez que despliegas la aplicación, se desplegaría instantáneamente en todo el mundo. Y si tu usuario está en la costa este de los EE. UU., entonces la aplicación que se despliega o el centro de datos más cercano a ellos sería responsable de devolver los datos que les corresponden. Y si tienes otro usuario que también está en algún lugar, digamos, en Asia Oriental, el centro de datos más cercano a ellos también respondería a ellos.

Ahora, esto tiene varios beneficios, por cierto, al desplegar en el edge y, por cierto, cuando me refiero al edge, me refiero a Cloud Flare Workers y Dino Edge Functions. Pero también puedes lograr una configuración similar utilizando máquinas virtuales. Pero requeriría un poco más de ajustes por tu cuenta. Bueno, puedes escalar infinitamente porque tu aplicación está en todo el mundo. Y esto significa que tienes una menor latencia. Y en Cloud Flare Workers, por cierto, no hay estadísticas de llamadas porque se ejecuta en un runtime diferente, del cual hablaré en un momento. Y reduce el costo de cómo se ejecuta tu aplicación.

Sin embargo, cuando se trata de trabajar con bases de datos, presenta algunos inconvenientes de los que debes ser consciente. Uno de ellos es que tienes un runtime limitado porque cuando ejecutas tu aplicación en lambdas, generalmente tienes acceso completo a toda la API de nodos. Sin embargo, cuando usas Cloud Flare Workers en particular, estás limitado a un aislamiento de V8, que es un runtime significativamente más pequeño que tiene una superficie limitada en términos de la API que puedes usar al momento de desplegar tu aplicación. Y otro desafío que tienen Cloud Flare Workers o Edge es que tienes recursos informáticos limitados. Por ejemplo, tienes menos CPU, menos memoria, y también tienes una asignación significativamente más pequeña de cuánto debe ser el tamaño de tu aplicación. Y creo que para Cloud Flare Workers es de alrededor de cinco megabytes. Y esto se vuelve aún más difícil cuando se trata de trabajar con bases de datos. Y dado que tenemos una superficie de API limitada, no hay conexiones TCP, lo que dificulta la comunicación con las bases de datos. Y dado que la mayoría de las implementaciones de base de datos suelen estar en una sola región, servir tus Edge functions, que son globales, se vuelve un poco difícil debido a la latencia y los viajes de ida y vuelta para conectarse a tu base de datos. Otra pausa. Vamos, anima, alegra.

Sin embargo, no todo es tan malo. Hay soluciones y puedes solucionarlos. Y para el problema de trabajar con conexiones TCP, una forma de solucionarlo es utilizar una conexión de proxy utilizando HTTP o WebSockets. Esto significa que tienes un proxy que se encuentra entre tu función en el edge y tu base de datos. Y tu función en el edge se comunicaría con tu data con el proxy utilizando HTTP o WebSockets. Y luego el proxy utilizaría TCP para comunicarse con la base de datos. Y luego respondería a tu aplicación con los datos que solicitaste.

Y un par de ejemplos de estas herramientas incluyen el paquete NEON serverless, el proxy AWS RDS y el proxy de datos Prisma.

El segundo desafío que mencioné es la latencia y los viajes de ida y vuelta al conectarse a tu base de datos. Y una forma de solucionar esto es utilizando un almacén de datos replicado globalmente. Y con esto me refiero a que tu proveedor de base de datos o tú como desarrollador podrían ser responsables de crear réplicas de tus datos y distribuirlos por todo el mundo. Y sé que esto suena fácil, algo ideal. Pero en el momento en que comienzas a hablar de replicar tus datos, nos encontramos en el territorio de los sistemas distribuidos. Y no es tan fácil porque tienes que empezar a pensar en la consistencia. Por ejemplo, ¿qué sucede? ¿Cómo sincronizas tus datos en tus réplicas y qué réplica o nodo es responsable de manejar las solicitudes? Y este no es realmente un problema fácil de solucionar. Y aunque empresas como Fauna, CloudFlare, Cockroach y AWS están haciendo un gran trabajo con estas herramientas, también tenemos que aceptar que tal vez nuestra base de datos no se moverá al edge, y está bien.

Ahora, una solución o sugerencia final, porque esto es solo un borrador y me gustaría tu opinión al respecto es utilizar algo llamado un almacén de datos o caché especializado, lo que significa que solo almacenas los datos que tu usuario necesita por región. Y esto viene con la advertencia de que tu aplicación o algunas partes de tu aplicación deben tener tolerancia para datos obsoletos. Y eso está bien. Como dijo Lee Robinson en su artículo sobre el estado de las bases de datos y el edge en 2023, tal vez lo que estamos buscando cuando se trata de trabajar con aplicaciones en el edge no es un almacén de datos replicado, sino una API de datos especializada.

Entonces, esto es lo que se vería. Bueno, tendríamos tu aplicación desplegada en todo el mundo y tu base de datos ubicada en algún lugar de la costa este, porque ahí es donde provienen la mayoría de las bromas de AWS en EE. UU. Y luego, si un usuario en algún lugar de la costa este de EE. UU. realiza una solicitud, entonces la primera solicitud, por supuesto, se enviaría a tu base de datos. Y luego, después de eso, tu base de datos respondería. Por supuesto, la primera solicitud llevaría un tiempo. Sin embargo, esos datos que el usuario solicitó podrían almacenarse en ese centro de datos. Y luego, esos datos se servirían al usuario. Y en caso de que el usuario realice una segunda solicitud, el tiempo de respuesta para esa función en particular sería significativamente más rápido. Y esos son los mismos datos que se servirían. Ahora, cuánto tiempo sirves estos datos depende completamente de ti. Podrían ser 10 segundos, 60 segundos, dos meses. Pero nuevamente, como mencioné antes, depende completamente de cuánta tolerancia tiene tu aplicación para datos obsoletos. Y los datos obsoletos no están mal. También son buenos porque te sirven. Lo siento. Porque con datos obsoletos, puedes reducir la carga en tu base de datos. Entonces, este es un ejemplo de cómo se vería en un Cloud Foundry en un Cloud Flare worker.

Disculpa por la cita errónea. En este caso, estoy utilizando Prisma, que es una herramienta para consultar e interactuar con bases de datos. Y en este caso, estoy solicitando publicaciones en mi base de datos y configurando una caché. Lo siento, el rojo no se puede ver, pero estoy resaltando la estrategia de caché y el feed que estoy solicitando tiene un tiempo de vida de 60 segundos. Y esto significa que los datos se almacenarán en el edge durante 60 segundos. Y luego, SWR significa Stale While Revalidate, lo que significa que podrás servir los datos obsoletos durante 60 segundos antes de que tu worker sea responsable de volver a obtener los datos y validarlos por ti. Entonces, eso es cómo se vería.

Ahora una demostración rápida de una aplicación que construí. Este es un hermoso blog. Y si actualizo esta página, esperando que el Wi-Fi funcione. Sí. Así que tenemos algunos datos de CloudFlare, y podemos ver que el centro de datos que respondió a nuestra solicitud está ubicado en Berlín, y el código para el centro de datos es FRA. Y FRA es como un código IATA, que son los códigos de aeropuerto, pero para centros de datos. Y para nuestra solicitud particular de base de datos, puedes ver que el centro de datos que respondió es el mismo que nuestro centro de datos. Y en este caso, fue un fallo de caché. Y por eso quizás la actualización tardó un poco. Y los datos se actualizaron por última vez en GMT. Esto fue hace aproximadamente dos horas. Y si actualizo estos datos, podemos ver que la respuesta es significativamente más rápida Y podemos ver que el estado de la caché es el tiempo de vida, lo que significa que ya ha sido almacenado en caché y cualquier otra solicitud posterior será significativamente más rápida. Lo mismo ocurre con las publicaciones individuales. Puedes ver que la transición a las diferentes páginas es significativamente lenta. Y eso se debe a que no se encontró en la caché y el mismo centro de datos respondió a nuestros datos, que es el código FRA.

Entonces, ¿cómo se ve esto en el código? En este caso, solo te mostraré una consulta. En este caso, tengo una consulta para todas las publicaciones y estoy filtrando las publicaciones que han sido publicadas. Y en este caso, establezco un tiempo de vida de aproximadamente 10 minutos. Y el tiempo de revalidación es de 60 segundos. En este caso, también obtengo la información de CloudFlare de la solicitud en CF, lamentablemente, eso no está escrito en remix, por cierto. Esta es una aplicación simple y familiar que utiliza remix. Y eso es todo para la demostración, en caso de que este sea el tipo de cosas que te interesaría probar. No dudes en contactarme y hablar conmigo o con Flow allí.

Saludos, saludos a Flow. Y en conclusión, la gran pregunta es, ¿deberías migrar al edge? Bueno, depende y no tengo la respuesta para ti. Viene con algunas consideraciones, lo que significa que, ya sabes, si tu aplicación depende de un almacén central de datos, entonces probablemente no sea tan bueno debido a la latencia y cuando tienes múltiples solicitudes, una tras otra en una sola función llevará un tiempo. Y tal vez lo que deberíamos hacer es entender las necesidades, las necesidades de datos de nuestra aplicación, que es y porque algunas partes de la aplicación, como mencioné, pueden tolerar datos obsoletos, y eso está bien. Y finalmente, recordemos que todas estas son herramientas y no tienes que migrar desde lo que estás usando. Funciona perfectamente. Así que gracias, por cierto. Espero que hayas disfrutado la charla y me gustaría dar un reconocimiento a una ex colega, Matina Velander, que me permitió usar las hermosas ilustraciones en mis diapositivas. Gracias. Muchas gracias.

Entonces, tu primera pregunta es, ¿puedo usar la estrategia de caché para las consultas en bruto de Prisma? En este momento, aún no, pero está en nuestros planes incluir caché para tus consultas en bruto.

Sí. Genial. Siguiente pregunta. Si los datos se almacenan o se almacenan en caché junto a los usuarios, ¿qué sucede cuando los usuarios trabajan dentro de una cuenta o dominio desde diferentes ubicaciones? ¿Qué sucede cuando las personas trabajan entre ubicaciones? ¿Habrá alguna inconsistencia?

Entonces, si trabajas desde diferentes ubicaciones, creo que, bueno, uno, estamos confiando en CloudFlare para acelerar en este caso. El centro de datos más cercano al usuario será el que responderá a las solicitudes de los usuarios. Y si los datos no están en caché en ese centro de datos en particular, entonces también se enviarán. Se enviará la solicitud a la base de datos y luego se almacenarán en caché los datos en el centro de datos que recibió la solicitud. Entonces, incluso si se mueven, siempre verán si está en caché en el centro de datos más cercano a ellos.

Sí. Genial. Siguiente pregunta. ¿En qué se diferencia SWR de TTL en el servidor Edge? Es complicado. Entonces, TTL solo especifica cuánto tiempo debes almacenar en caché los datos y stalewhileRevalidate especifica cuánto tiempo puedes servir los datos obsoletos antes de volver a buscar los datos en tu base de datos. Espero que eso esté claro. No estoy seguro de entenderlo completamente. No hay problema. Tal vez podamos hablar de esto en el descanso. ¿Puedes describirlo de otra manera si tienes otra forma de explicarlo, o prefieres hacerlo en el descanso y tener un momento para pensarlo? Así que puedo intentarlo una vez más. Si has decidido almacenar en caché tus datos durante 60 segundos, entonces el TTL se aplicará primero. La primera solicitud enviará la solicitud a la base de datos y luego se almacenará en caché en la base de datos. Ahora, una vez que hayan pasado los 60 segundos, entra en juego SWR y especifica cuánto tiempo puedes seguir sirviendo los datos obsoletos antes de volver a buscarlos en la base de datos. Así que, sí, es simplemente, sí. Juegan juntos pero en diferentes momentos en ese proceso de almacenar y servir datos potencialmente obsoletos. Sí. Genial, gracias.

Tenemos, parece que tenemos varias preguntas rápidas. Genial. Sigamos con esta pregunta. ¿Es Cloudflare Workers la única solución de edge que admitiría esta estrategia de caché? No. Accelerate Edge es solo una de las plataformas que puedes usar con Accelerate. También puedes usarlo con serverless o cuando trabajas con un servidor tradicional. No es la única plataforma con la que puedes utilizar estrategias de caché. Genial, y eso significa que puedes utilizar tus propios proveedores de servicios en la nube. También puedes utilizar esta estrategia con tu propio proveedor de servicios en la nube. Donde implementes aplicaciones. Sí. Genial. Sí. La siguiente pregunta es, creo que esta podría ser una repetición, pero la haré de todas formas. ¿En qué plataformas podemos utilizar el caché de Prisma? Yo diría que lo recomendaría especialmente para serverless y el edge, si estás utilizando esos en particular. Pero si tu aplicación está en la misma red que tu base de datos, tal vez sería más rápido solicitar los datos directamente de la base de datos en este caso. Sí. Solo tengo un par en general. Si alguien intentara implementar esto ahora, ¿cuáles son los errores comunes, conceptos erróneos, pasos en falso que sueles ver que la gente cometa? Esa es una pregunta difícil. Quiero decir, el producto solo ha estado disponible durante aproximadamente dos meses, así que aún no hemos visto ninguno. Pero esperamos buscar, bueno, que la gente lo pruebe y así también podamos aprender de ellos. Sí. Interesante. Sí. ¿Dónde pueden ir las personas para obtener más información? Prisma.io/accelerate debería ser el lugar correcto también. ¿Hay otros recursos que las personas puedan consultar? Bueno, la URL que acabo de mencionar debería funcionar. También tiene un enlace a una lista de espera y aún está en acceso anticipado, lo que significa que es como una versión beta privada. Una vez que obtengas acceso, compartiremos contigo más recursos como la documentación. Pero también puedes obtener eso si estás interesado en leer más sobre cómo funciona. Sí, lo cual no tengo en mente en este momento. Muy bien. Las personas siempre pueden venir y hacerte preguntas si las tienen. Me gustaría que todos demos un gran, gran aplauso por una charla realmente fascinante. Estoy muy interesado en aprender más y gracias por presentarnos estos conceptos. Gracias por tenerme aquí.