Escalando Bases de Datos para Aplicaciones Globales sin Servidor

♪♪ Sí, bienvenidos todos. Aún veo a algunas personas llegando, pero de todas formas comenzaremos, así que bienvenidos a esta charla de Node Congress sobre el escalado de bases de datos para aplicaciones serverless globales. Veamos la agenda para hoy. Solo un par de reglas de organización, siéntanse libres de usar el chat, también pueden desactivar el silencio, hay mucha gente aquí, así que manténganse en silencio si no están hablando, pero por favor activen el sonido, hagan preguntas, hagamos esto lo más interactivo posible, porque creo que podemos aprender mucho colaborando con nuestras preguntas.

Así que sí, siéntanse libres de usar el chat, pero obviamente, activen el sonido y preséntense, y, por supuesto, intervengan en cualquier momento si tienen preguntas. Son muy bienvenidas. Entonces, sí, espero que todos puedan escucharme bien, y esta es nuestra agenda para hoy. Un poco sobre mí, soy el fundador de PolyScale y mi experiencia ha estado en trabajar con grandes compañías de data y compañías de database. Y he estado en el espacio de architecture de soluciones y ventas de ingeniería durante muchos años. Y en las últimas compañías en las que estuve, bueno, Alfresco era una compañía de gestión de documentos de código abierto. Así que trabajamos con repositorios de data muy grandes, específicamente para los documentos de gestión de contenido web. DataSift fue uno de los primeros en adoptar el flujo completo de Twitter e ingestar todos los datos de Twitter y luego trabajó con Facebook y LinkedIn para ingestar todos esos datos y proporcionar información de manera segura en términos de privacidad. Y luego de eso, me mudé a Elastic aquí en el Área de la Bahía, en San Francisco, donde trabajé con grandes empresas con la Solución Elastic y escalando esas soluciones y luego, antes de fundar Polyscale, estuve en una compañía llamada Rockset, que es una base de datos basada en la nube para análisis en tiempo real. Así que a lo largo de esos últimos años, siempre me he enfocado en la gestión de grandes volúmenes de datos y en entender cómo escalarlos a nivel global. Eso ha sido realmente los desafíos en los que he estado trabajando.

Pero hoy, tenemos una gran charla preparada. Les presentaré Polyscale y podremos probarlo para aquellos que quieran probarlo. Y hablaré un poco sobre los desafíos en el ámbito enterprise y las pequeñas empresas en cuanto a la gestión y escalado de datos. ¿Y por qué es difícil? ¿Por qué es difícil mover datos a diferentes regiones y mantener la integridad de las transacciones? También hablaremos sobre cuáles son sus opciones, qué hacen las personas hoy en día para escalar estos sistemas de bases de datos y plataformas de datos. Y luego, como mencioné, profundizaremos en Polyscale y qué es Polyscale y cómo funciona. Y como dije, todos están invitados a probarlo. Tenemos algo de código para jugar y comenzar. Entonces, sí, como dije, todos los que quieran, cualquier pregunta, siéntanse libres de participar, activen el sonido, preséntense, son muy bienvenidos a hacer preguntas.

Entonces, realmente, la premisa de por qué Polyscale existe y por qué nuestro enfoque se centra en el escalado de datos nativos en la nube con estado es difícil. Así que cualquiera que haya estado en un puesto donde haya tenido que, por ejemplo, escalar una base de datos a diferentes países, o incluso simplemente escalarla de forma independiente, comprenderá los desafíos que eso implica. Y hay muchas razones por las cuales eso es difícil, desde aspectos relacionados con el teorema CAP hasta, por ejemplo, mantener la transaccionalidad, cómo fragmentar mis datos, dónde reside eso. Y luego, cómo gestionar simplemente las leyes de la física en torno al acceso en un entorno de baja latencia en diferentes continentes, por ejemplo. Así que un gran ejemplo es que tenemos personas de todas partes del planeta conectadas hoy. Y hacer que los datos sean rápidos para todos es algo difícil y complejo, y específicamente aquí, también estamos hablando de datos nativos en la nube. Entonces, ¿qué sucede cuando te encuentras en una situación donde, por ejemplo, hay una interrupción en un centro de datos, donde una región se cae o una parte o componente de tu arquitectura se cae? ¿Cómo se respaldan esos entornos? Y eso es lo que lo hace difícil. Es mantener ese estado y hacerlo en un entorno implacable como la nube. Entonces, hablo mucho sobre este concepto de la gravedad de datos empresariales. Y, ¿qué es eso y cómo nos afecta? La realidad es que los datos se están creando en todas partes. Y pueden estar en múltiples sistemas dispares. Y dentro de una sola empresa, probablemente haya muchas capas de persistencia de datos diferentes. Pueden ser cosas como lagos de datos, bases de datos, almacenes. Y eso se está creando todo el día, todos los días. Con la inteligencia artificial, el aprendizaje automático, los datos de sensores y el IoT, eso se acelera enormemente. Entonces, lo que tiende a suceder es que, dentro de las empresas, cada vez más aplicaciones quieren usar esos datos. Y las personas solicitan acceso a esos datos desde diferentes departamentos, desde diferentes ubicaciones. Y eso nos impide mover los datos. Nos encontramos atados a, una vez que alguien está usando... Digamos que tenemos una gran base de datos transaccional como Postgres, y se ejecuta desde un centro de datos en Nueva York. Y ahora tenemos muchos usuarios que realmente lo están usando activamente. Cada vez es más difícil acceder a esos datos en diferentes ubicaciones y mover esos datos. Por lo tanto, la ubicación se vuelve crítica según donde se encuentren tus usuarios. Y luego, la otra consideración importante en torno a los datos y su uso es, obviamente, ¿cuáles son las regulaciones de datos en esto? Cosas como la privacidad, el cumplimiento y los datos de información personal, ¿qué estás almacenando en qué países? ¿Cumple con el GDPR? Esto se está volviendo cada vez más crítico hoy en día, pero solo se vuelve más crítico a medida que avanzamos con estos sistemas de datos. Y, por último, debemos considerar el crecimiento global. Puede ser una aplicación web sencilla. Descubrimos que ahora tenemos una audiencia en diferentes países o partes de países. ¿Y cómo nos aseguramos de que puedan acceder a esos datos y cómo gestionamos ese crecimiento global? Y lo mismo ocurre con una aplicación que no está orientada al cliente. Tal vez sea algo como un entorno de inteligencia interna donde las personas acceden a datos de inteligencia interna utilizando herramientas como click tech y tableau. Los mismos tipos de problemas. Estamos abriendo nuevas oficinas en diferentes ubicaciones. Las personas trabajan desde casa, trabajan de forma remota. ¿Cómo respaldamos ese crecimiento? Y esa es realmente la esencia de los problemas que surgen con la gravedad de datos. Así que creo que probablemente muchas personas en esta charla estarán muy familiarizadas con el hecho de que el nivel de aplicación tiene mucha agilidad. Y eso es todo el tiempo que tengo hoy. Si les dijera a todos en esta llamada: ¿cómo implementarían una aplicación web? Creo que tendríamos muchas opciones diferentes. Y si les dijera: ¿cómo implemento una aplicación web en diferentes regiones? Creo que también habría una gran cantidad de opciones. Y pienso en esto, en el contenido y el código. Por lo tanto, el contenido estático y la lógica empresarial se pueden replicar fácilmente localmente. Y cuando pienso en tener un servidor donde tenemos estas increíbles empresas como Netlify y Vercel, que pueden, por ejemplo, distribuir mi lógica de aplicación y mi contenido estático en todas partes. Y puedo ejecutar funciones en el borde. Y puedo combinar eso con un simple plan de equilibrio de carga que me permitirá resolver a mi servidor de aplicaciones más cercano. Por lo tanto, ahora es bastante factible para cualquier tamaño de empresa o individuo. Incluso un desarrollador independiente puede configurar el equilibrio de carga global. Podemos implementar en CDNs para nuestro contenido estático y nuestras funciones. Y también estamos viendo la capacidad de que aparezcan nuevos actores como Fly y Section, que te permiten contenerizar tu código y distribuirlo en múltiples regiones. Entonces, en lo que respecta a la lógica empresarial y al contenido estático, realmente hay una gran cantidad de flexibilidad. Y ese es un gran espacio para estar. Solo haré una pausa aquí. ¿Alguna pregunta antes de continuar? ¿Algo en el chat o alguien quiere hacer una pregunta?

Hola. Hola. He hecho una pregunta en el chat. Básicamente, la pregunta es, en términos de cumplimiento, ¿qué sucede si tienes un usuario en la UE, pero el servidor y el producto o servicio están en los EE. UU., cómo manejamos el almacenamiento de datos? Sí, es una buena pregunta. Y les voy a contar un poco más adelante cómo Polyscale aborda eso. Pero, a grandes rasgos, las empresas están definiendo las políticas sobre dónde pueden residir los datos. Y hay una gran industria de auditoría y cumplimiento en torno a qué datos se almacenan dónde, y debes cumplir con esas políticas. Ahora, los productos están facilitando cada vez más eso. Y, ya saben, en un mundo de aplicaciones web básicas, es posible que tengan una lista de bloqueo de ubicaciones a las que deseen implementar esos datos. Ahora, se vuelve más complejo si piensan en audiencias globales que residen en ciertos países y acceden a datos en otros países. Por ejemplo, si soy residente en Alemania y estoy utilizando un servicio en América del Norte, ¿está bien que se almacenen mis datos fuera de Alemania o deben almacenarse en Alemania? Entonces, creo que estas son cosas que deben incorporar en su producto desde el primer día. Creo que son absolutamente críticas. Si están almacenando datos de clientes, deben comenzar con esa mentalidad de cuáles son las políticas que debemos cumplir. Así que sí, les mostraré cómo lo respaldamos con Polyscale. Pero realmente es algo que deben incorporar en sus productos desde las primeras etapas. Y ahora hay muchos productos disponibles que proporcionan marcos con los que pueden interactuar e integrarse para facilitar eso. Entonces, desde una perspectiva de cumplimiento, van a un solo lugar. Pueden auditar fácilmente qué datos se almacenan dónde. Y eso es crítico para el cumplimiento de SoC y otros tipos de cumplimiento.

Entonces, sí, como estaba hablando aquí, tenemos mucha agilidad en el espacio de la lógica empresarial y el contenido. El mercado de las CDN realmente ha hecho que esto sea trivial para nosotros implementar en todas partes. Pero las aplicaciones impulsadas por datos, hacerlas rápidas a nivel global sigue siendo complejo y costoso. Por lo tanto, una cosa es hacer que una aplicación impulsada por datos sea rápida en una sola ubicación. Pero tan pronto como comenzamos a pensar en hacerlo en todas partes, realmente nos encontramos con estos problemas de complejidad y gastos. Y los gastos pueden ser desde el tiempo de los desarrolladores, desde el tiempo de los arquitectos, hasta el uso de diferentes tipos de bases de datos, sistemas de datos. Pueden ser sus costos de almacenamiento en AWS. Y las complejidades suelen ser continuas. Por lo tanto, no se trata simplemente de iniciar una base de datos y poner un par de réplicas de lectura, y luego olvidarnos de ello. Se trata más de qué sucede cuando comienzan a retrasarse y desincronizarse. ¿Cuáles son las implicaciones en mi capa de aplicación? ¿Necesito comenzar a separar mis lecturas y mis escrituras en mi capa de código? Por lo tanto, hay complejidades y gastos en todas las partes del negocio. Entonces, ¿por qué es difícil, como los desafíos globales de datos? Uno de los principales aquí es realmente la consistencia y la transaccionalidad. Por ejemplo, tengo un sitio web de comercio electrónico que puede estar siendo servido desde, digamos, la costa este de los Estados Unidos, Nueva York. Compro un producto, otra persona en el planeta no debería poder comprar ese mismo producto exacto porque es posible que esté agotado. O, en términos más simples, donde las personas realmente están viendo cuáles son los niveles de stock, estos deben ser precisos en tiempo real. Deben ser consistentes. Por lo tanto, deben decidir, y uno de los compromisos aquí es, ¿estamos utilizando sistemas compatibles con activos versus sistemas eventualmente consistentes? Y realmente eso depende del caso de uso, ¿cuáles son sus tolerancias para diferentes semánticas aquí? Y el clásico, que obviamente el espacio de las CDN ha hecho un trabajo increíble al respecto, es la latencia, la clásica velocidad de la luz. ¿Cómo sirvo a un cliente que está en una ubicación lejana a mis datos? Y luego, el otro es, en cierto modo, he hablado aquí un poco sobre las conexiones TCP de corta duración, pero realmente puede ser cualquier cosa en la que dependa su plataforma de datos. Entonces, ya saben, en un database más transaccional, Postgres, MySQL, lo que sea, ya saben, las conexiones TCP realmente importan. Y eso afecta sus desafíos de escalabilidad. Entonces, ¿qué sucede si están utilizando cosas como, ya saben, funciones que se ejecutan en el borde o, ya saben, AWS Lambda, cosas que crean un alto número de conexiones de corta duración, ¿cómo escalo eso y cómo lo respaldo? Estos son algunos de los desafíos principales a los que se enfrentan las personas al expandirse a diferentes regiones.

Entonces, ya saben, ¿cómo abordamos esto hoy? Si les dijera a las personas en esta llamada, como, tengo una aplicación web, reduzcamos esto a aplicaciones web. Y digamos, ya saben, necesito hacerla rápida en los EE. UU. y también necesito hacerla rápida en Europa. ¿Cómo lo haríamos? Y creo que las cosas principales que he visto en mi career y que veo con bastante frecuencia son, las personas recurren al almacenamiento en caché a nivel de aplicación. Entonces, las personas se sienten muy cómodas escribiendo código que guardará esos datos. Podemos reutilizarlo. Podemos hidratarlo. Podemos eliminarlo de la caché de manera inteligente. Podemos usar herramientas como Redis o Memcache que se escalan bien.

Y también podemos compartir estado con ellos si queremos. Estas son las áreas principales para el almacenamiento en caché de aplicaciones. Ahora, cada enfoque tiene sus ventajas y desventajas. Y quiero dejar claro que he visto que todos ellos funcionan muy bien en producción. Pero también he visto que hay costos y complejidades asociados.

El enfoque clásico del almacenamiento en caché de aplicaciones requiere escribir ese código, ¿verdad? Eso no es algo rápido, dependiendo de lo grande o compleja que sea su aplicación web. Y si sus sistemas de datos se escalan en múltiples plataformas, digamos que tenemos un sitio web de bienes raíces y estamos consultando varios repositorios de datos para obtener información sobre el historial de propiedades y las tasas hipotecarias actuales. Es posible que deba cumplir diferentes políticas de almacenamiento en caché dentro de su aplicación. Y luego, de manera continua, cada función que agregue a su aplicación, potencialmente necesitará incorporar el almacenamiento en caché también. Por lo tanto, es algo continuo que, si se abstrae correctamente, puede ser bueno, pero tiene un costo adicional. Y, ustedes saben, díganme, me encantaría escuchar comentarios, pero cualquiera que haya escrito una capa de almacenamiento en caché para una aplicación de tamaño razonable, sabe que puede volverse complejo rápidamente. Por lo tanto, también tiene el efecto secundario de comunicar cómo funciona eso al resto del equipo de ingeniería. Definitivamente, hay ventajas y desventajas en todos estos enfoques. También estamos viendo, en los últimos años, algunas bases de datos globales increíbles como Cockroach y Yugabyte. Estas bases de datos se centran en el desafío global. ¿Cómo dividimos eficientemente los datos? ¿Dónde realizamos nuestras transacciones? Puede configurar y definir todo ese comportamiento, lo cual es increíble. Y, ustedes saben, soy un gran admirador de estos sistemas. Y lo que a menudo es un desafío en la enterprise es la propuesta de, hey, migremos a la base de datos X. Sabemos que la base de datos X puede hacer esto por usted. Vamos a migrar de lo que está utilizando actualmente a esta base de datos. Y eso puede ser una opción si es un proyecto nuevo y no hay problema. Pero nuevamente, en grandes empresas o incluso en pequeñas empresas, la propuesta de migrar una base de datos es compleja. Todos los aspectos transaccionales son iguales. ¿Es el mismo lenguaje de consulta? ¿Tiene las mismas características? ¿Necesito SQL? Por lo general, es un proceso largo migrar una base de datos completa. Pero nuevamente, si es lo correcto para su solución, entonces esa es la forma correcta de hacerlo, elija la herramienta adecuada para el trabajo.

Ahora, lo que veo mucho y he visto mucho en los últimos años es la capa de datos políglota. Y creo que esto es preciso para la mayoría de las empresas ahora que tienen múltiples repositorios para realizar diferentes tareas utilizando diversas herramientas. Y lo que estoy hablando específicamente aquí es si decimos, asumamos que tenemos una gran aplicación web y ahora necesitamos acelerar y hacer las cosas más rápidas. Tomaremos, ya saben, típicamente una forma de abordar esto es tomar su función más lenta. ¿Cuál es la que realmente está en la parte superior de la lista de los gerentes de producto en cuanto al rendimiento para sus clientes? ¿Hay algo que realmente les molesta todos los días? Y obtendrá esa información de su análisis de APM. ¿Cuál es la satisfacción del cliente? ¿Es una página específica? Por ejemplo, sé que cuando ingreso a mi cuenta de proveedor de telefonía móvil no mencionado las cosas son increíblemente lentas. Solo quiero ver mi factura de este mes y el mes pasado y, ya saben, qué números, cuántos mensajes he enviado y cuántos datos he utilizado. Y todo eso es muy lento porque se obtiene de una ubicación remota. Tal vez la base de datos esté ocupada. Tal vez esté sobrecargada. Tal vez lo haya hecho en mi hora de almuerzo. Por lo tanto, vemos picos de carga en ese período. Por lo tanto, es una práctica común decir, bien, tomemos solo una función y separemos eso de nuestra plataforma y comencemos a escalarlo de forma independiente. Y eso puede ser tan extremo como, está bien, usemos una nueva tienda de datos para admitir realmente esa función. Y luego se entra en la complejidad de cosas como, bueno, ¿cómo mantenemos el estado con esa tienda de datos externa? Tal vez necesitemos usar cosas como flujos de captura de cambios para poblar otras fuentes de datos. Y un gran ejemplo aquí es, ya saben, tal vez tengo una base de datos transaccional, usemos algo como MySQL y queremos poblar un motor de búsqueda cuando las cosas cambien. Y puede usar flujos de captura de cambios para hacer eso. Pero tomemos un ejemplo aquí. Y es una excelente manera de pensar en dividir su monolito en microservicios. Entonces, tal vez queramos tomar una función específica y ejecutarla en el borde. Y tal vez queramos comenzar a usar algo como una tienda de clave-valor ofrecida por, ya saben, uno de los muchos proveedores de CDN. Entonces, ahora estoy en una situación en la que tengo una especie de una base de datos transaccional y una tienda de clave-valor y una se ejecuta en el borde y la otra es centralizada. Y nuevamente, eso puede ser una gran solución pero también está agregando mucha complejidad potencial a esa situación. Pero vemos esto mucho. Las personas están dividiendo esas funciones y utilizando la herramienta adecuada para cada tarea. Y como digo al final, todas estas opciones son válidas.

Todas estas opciones son válidas y útiles hoy en día. Y, ya sabes, la otra que no he mencionado realmente en esta lista es database réplicas de lectura que es una opción obvia. Entonces, ya sabes, tengo una ubicación central y quiero comenzar a brindar soporte a los clientes o reducir la latencia en una región geográfica diferente. Sabes, tu hiperescala hace que eso sea muy fácil hoy en día. Puedo hacer clic en un par de botones y puedo implementar una réplica de lectura. Entonces, nuevamente, otra buena opción dependiendo de dónde necesites escalar y dependiendo del comportamiento.

Entonces sí, una breve introducción a Polyscale y dónde encajamos en este mundo y qué somos, esto es un poco complicado pero somos una caché de borde de base de datos sin código que distribuye datos y cálculos de consultas más cerca del usuario. Entonces, ya sabes, en una conferencia de Node eso puede sonar extraño pero somos una aplicación sin código. La idea es que nuestro enfoque y nuestro verdadero impulsor detrás de la plataforma es que como desarrollador, no necesitamos hacer nada. No deberías tener que pensar en implementar almacenamiento en caché y acelerar tu capa de datos y administrar valores de tiempo de vida y qué consultas son costosas y cómo eso cambia con el tiempo. Así que nuestro enfoque completo es, lo que yo llamaría plug and play. Queremos que simplemente conectes Polyscale a tu capa de datos y nada cambie dentro de tu entorno. Y cuando digo que nada cambia, me refiero a que no tienes que cambiar tu lenguaje de consulta, no tienes que migrar tu base de datos, no tienes que escalar nada de manera diferente. Tu transaccionalidad se mantiene igual y ese es realmente nuestro enfoque.

Entonces, lo que hacemos es, si estás familiarizado con una CDN, es un concepto similar y en realidad almacenamos en caché los datos de la base de datos en el borde o más cerca del usuario. Pero además de los datos en sí, también ofrecemos el propio cálculo. Entonces, si quiero ejecutar una consulta SQL, que sea única, se ejecutará en los POP (puntos de presencia) de Polyscale y te devolverá los datos de Polyscale si los tenemos en la caché. Así que trasladamos el cálculo de la consulta y los datos más cerca del usuario. Muy similar a una CDN en el sentido de que, ya sabes, tenemos puntos de presencia globales en todo el mundo. Y nuestro enfoque es hacer que la capa de datos tenga la menor latencia posible y mantener los costos y la complejidad bajos. Como mencioné anteriormente, hay numerosas formas de escalar tu base de datos y, ya sabes, el almacenamiento en caché puede ser o no adecuado para ti, pero nuestro enfoque es realmente hacer que la complejidad sea lo más simple posible. Así que plug and play es realmente nuestro impulsor. Si profundizas un poco en lo que es Polyscale y por qué es útil para mí como desarrollador. Y, ya sabes, nos obsesionamos con la experiencia del desarrollador y del operador y eso es lo que nos importa. Y, ya sabes, pensamos mucho en eso, todos en nuestra empresa han estado en esta posición de tener que construir estos sistemas y comprenderlos y brindarles soporte en su historia. Así que somos absolutamente fanáticos de hacer esto lo más sencillo posible. Y la forma en que nos enfocamos en esto es ver, bueno, ¿qué costos y complejidades podemos abstraer? ¿Cuáles son esas cosas tediosas o difíciles de hacer para un desarrollador o un ingeniero de DevOps? ¿Y cómo podemos alejar esas situaciones y hacer que sean fácilmente alcanzables? Entonces, ya sabes, lo primero es que nos integramos o Polyscale se puede integrar en cuestión de minutos, literalmente. Así que te mostraré, y esto es algo que obviamente haremos en esta masterclass es cómo conectarse. Y todo lo que tienes que hacer es actualizar tus credenciales de la base de datos, como el nombre de host y el nombre de usuario de la base de datos. Esas son las dos cosas que debes cambiar. Por lo general, eso es una variable de entorno. Es un cambio de configuración sencillo. Así que literalmente puedes estar en funcionamiento en unos 30 segundos para enrutar tus datos a través de Polyscale. Y la forma en que funciona es que nos enfocamos en no tener código. Como dije, no queremos que tengas que empezar a agregar nuevas bibliotecas de cliente. Y nuevamente, no es que eso no sea un buen enfoque. Simplemente no queremos agregar otra biblioteca de cliente a tu mundo. El mundo ya está bastante ocupado. Y la forma en que lo hacemos es que Polyscale es completamente transparente para tus clientes de base de datos actuales. Entonces, si estás usando, ya sabes, Prisma o estás usando Mongoose o cualquier otra cosa, Polyscale es completamente transparente. Y la forma en que lo hacemos es que Polyscale en realidad se encuentra en la capa TCP, capa tres, capa cuatro y habla el protocolo nativo de tu base de datos. Entonces, en realidad estás hablando con un servidor de Postgres o un servidor de MySQL. Y solo para dar un paso atrás, quiero decir, lo que es Polyscale es una caché. Entonces, tu cliente de base de datos se conecta a Polyscale y luego Polyscale se conecta a tu base de datos de origen. Y es realmente, realmente simple de configurar como te mostraremos. Y luego llegas a esa columna central que es, bueno, ahora tengo mis datos de la base de datos fluyendo a través de Polyscale, ¿qué debo almacenar en caché? Y eso, ya sabes, nuevamente, si alguna vez has implementado una capa de almacenamiento en caché puede volverse complejo muy rápidamente. Y hay un famoso dicho allí abajo en la parte inferior izquierda que dice, ya sabes, almacenamiento en caché y cómo nombrar las cosas. Y definitivamente estaríamos de acuerdo con esa afirmación. Así que realmente nuestro enfoque es hacer que sea sencillo para un desarrollador tener que pensar en qué almacenar en caché. Entonces, si estás en un entorno donde te acercas a esto con respecto a, tengo cinco microservicios y sé exactamente qué quiero almacenar en caché y durante cuánto tiempo, entonces genial. Puedes ir y configurar eso.

El otro lado de eso es cómo cambian esas cosas con el tiempo. ¿Existe un valor TTL más óptimo basado en fluctuaciones cíclicas basadas en el tiempo? Por ejemplo, en un mundo de comercio electrónico, tal vez haya un pico al mediodía UTC donde muchas personas se conectan en su hora de almuerzo. Entonces, ¿cómo cambiaría mi comportamiento de caché durante ese período, o debería cambiar? Y luego entramos en sistemas mucho más complejos donde tal vez haya 5,000 consultas SQL únicas que fluyen a través de la plataforma todos los días. Entonces, ¿por dónde empiezo? ¿Cuáles debo almacenar en caché? ¿Cuánto tiempo debo almacenar en caché esos datos? Y eso es algo realmente difícil de hacer para un humano.

Y ahí es donde entra en juego la inteligencia artificial y el aprendizaje automático. Lo que hace Polyscale es que, interroga y analiza cada consulta SQL individual que llega a través de la plataforma. Y ajustará el comportamiento de la caché en función de lo que está viendo, ya sabes, cuál es el comportamiento real de ese tráfico entrante. Y establece automáticamente cuánto tiempo deben vivir esos datos en la caché. Y lo que eso significa es que literalmente puedes activar Polyscale, como mencioné, actualizar tu archivo de configuración, comenzar a enviar tu tráfico de base de datos a través de él, y Polyscale comenzará a seleccionar selectivamente qué almacenar en caché y acelerar tus datos. Y lo hace a nivel global. Lo hace en cada punto de presencia. Así que eso es realmente, vemos eso como algo increíblemente útil.

Entonces, digamos que tengo un sistema Drupal o, ya sabes, algo con consultas SQL más complejas, WordPress o cualquier otra cosa, o una plataforma de comercio electrónico. Puedes activar esta cosa y comenzará a almacenar en caché selectivamente, ya sabes, tus datos. Ahora, la pregunta inmediata aquí es, bueno, ¿qué pasa con la invalidez? ¿Y qué pasa con mis derechos? Ya sabes, ¿qué pasa con mis inserciones, actualizaciones y eliminaciones? ¿Mis consultas de manipulación? ¿Qué sucede con esas? Entonces, Polyscale inspecciona en tiempo real cada consulta y determina si es una consulta de selección o mostrar. ¿Es una consulta de reconsulta? Y si no lo es, entonces lo envía a la base de datos de origen. Entonces, la transaccionalidad de tu base de datos nunca cambia. No estamos cambiando nada en ese comportamiento. Entonces, todas esas inserciones, actualizaciones, y eliminaciones se envían y tu consistencia se mantiene igual. Tu base de datos de origen sigue siendo la misma.

Y lo otro interesante de esto, si consideras, ya sabes, y lo veremos y lo demostraremos, y hay un lugar. Esto... Invalidez. Entonces, si Polyscale ve una de esas consultas de manipulación, una inserción, una actualización o una eliminación, automáticamente invalidará esos datos de la caché en tiempo real a nivel global. Entonces, si enviamos, ya sabes, actualizar tabla X, establecer nombre de usuario igual a foo, eliminará esos datos de la caché a nivel global automáticamente. Entonces, nuevamente, la próxima vez que se realice una lectura, se obtendrá desde el origen y se llenará la caché. Y siempre obtienes los datos más actualizados. Entonces, eso es una gran parte, vemos eso como una gran parte de la ingeniería que, los desarrolladores no tienen que construir. No tengo que preocuparme por ese aspecto de la invalidez. Y luego la inteligencia artificial también es muy inteligente en cuanto a, monitorea los cambios en la carga que provienen de una base de datos. Entonces, si vemos cambios en la base de datos, ajustamos el tiempo de vida en caché en consecuencia. Entonces, si hay cosas sucediendo, en la base de datos que no podemos ver, entonces somos bastante inteligentes en cómo la IA maneja eso también. El escenario clásico es, tomemos algo como una agencia de viajes, donde pueden estar recopilando datos de numerosas fuentes de datos diferentes. Entonces puede haber cosas sucediendo, en la base de datos que no podemos ver. Hablando también del futuro, también tendremos la capacidad de conectar, cambiar flujos de captura de datos en Polyscale, si eso es algo importante para tus semánticas de caché. Así que sí, automatización completa. Si no lo estás, si quieres, quiero decir, para ser claro, también puedes anular completamente la automatización. Puedes desactivarla globalmente y decir, hey, sé lo que quiero establecer para esto. Y puedo hacerlo yo mismo. Ya sabes, si quieres seguir ese camino, te recomendaremos lo que creemos o lo que la plataforma piensa que deberías establecer como valor de caché. Así que esa es una característica agradable en la que te ayudamos, pero puedes ir y sobrescribir estas cosas. No es una, ya sabes, no es una caja negra completa sobre la que no tienes control. Y luego, finalmente aquí abajo, una de las características que tendremos próximamente es lo que llamamos calentamiento predictivo. Entonces, este es un caso de uso clásico de personalización en el que inicio sesión en un sistema y quiero, ya sabes, cargar, nuevamente, mi proveedor de telefonía celular, mostrarme mi factura o mi uso del mes, o inicio sesión en, ya sabes, algo como iTunes o lo que sea y mostrarme mi vista personalizada. Entonces, podemos, ya sabes, acelerar esa carga en segundo plano. Entonces, estamos buscando agrupaciones de consultas que típicamente se ejecutan juntas y podemos ejecutar esas y asegurarnos de que la caché esté activa para ese usuario en particular, lo cual es realmente emocionante. Y luego la parte final, que es el meollo de esta charla, realmente es, ¿cómo escalamos? Sí, genial, me estás dando una caché para mi base de datos, pero ¿cómo se escala eso? Y como dije antes, tenemos puntos de presencia a nivel mundial y los colocamos lo más cerca posible de la capa de aplicación donde sea que estés escalando. Entonces, eso mueve el cálculo de la consulta y mueve los datos físicamente más cerca de la capa de aplicación. Otra característica que tendremos muy pronto, de hecho, es el agrupamiento de conexiones. Entonces, para poder, si consideras, por ejemplo, quiero ejecutar funciones en el borde, esas son de muy corta duración, como ya hemos hablado, y puede haber miles de ellas ejecutándose simultáneamente. Ese es exactamente el caso de uso para el agrupamiento de conexiones, donde, digamos que tengo una instancia de Postgres en ejecución, que se ejecuta en París, Francia, y ahora estoy usando Polyscale para servir eso a nivel mundial, también estoy usando mi proveedor de funciones favorito, y estamos iniciando muchas conexiones TCP.

Por ejemplo, sé que en el momento de esta presentación, Cloudflare, son una plataforma de trabajadores, están a punto de introducir soporte TCP. Por ejemplo, podrías estar ejecutando muchas funciones a nivel mundial conectándote de nuevo a Polyscale en esa capa de datos, y Polyscale gestiona la agrupación allí. Así que tendrás un pequeño número de conexiones de larga duración que vuelven a tu base de datos de origen, y luego un número muy, muy alto de conexiones efímeras y de corta duración que llegan a Polyscale.

Y luego el otro gran problema que vemos en la escalabilidad de estos sistemas de datos es cómo hacer el particionamiento. Muchas bases de datos tienen excelentes características en torno al particionamiento, pero tienes que decidir qué datos viven dónde. Y eso no siempre es una decisión fácil. Entonces, un caso de uso que me viene a la mente es una gran empresa de juegos que gestiona clasificaciones, y eso es algo que cambia constantemente. Y también es algo que cambia constantemente a nivel mundial. Entonces, por ejemplo, una clasificación no es algo, quiero decir, obviamente puedes tener clasificaciones regionales, pero una clasificación global que cambia constantemente con miles de actualizaciones cada minuto. Y la gente quiere esos datos más recientes, no es suficiente tener eso distribuido y que no sea preciso. Entonces, ¿cómo haces el particionamiento de esos datos? ¿Cómo, ¿almaceno todo en todas partes? ¿O separo esas lecturas en una plataforma como Polyscale? Y así particionamos esos datos según la demanda.

Y la diferencia es que Polyscale no es una base de datos. Entonces puedes escalar terabytes de datos a cada región de Polyscale de manera increíblemente económica y sin degradación del rendimiento. Entonces, Polyscale puede admitir decenas de miles de consultas concurrentes sin mostrar ninguna degradación en absoluto. No estamos golpeando índices. No estamos haciendo todas las cosas complejas que necesitamos de nuestra base de datos. No tenemos que hacer eso. Por lo tanto, podemos ser muy rápidos y consistentemente rápidos también. Pero solo para darte una idea. Entonces, si tienes alguna consulta de base de datos que está en caché, Polyscale la servirá en menos de un milisegundo, un milisegundo o menos a gran escala. Y esto es enormemente beneficioso, obviamente, porque lo que realmente está sucediendo es que estás separando tus lecturas de tus escrituras, lo que luego le da a tu base de datos de origen más rendimiento para gestionar esas escrituras y Polyscale puede compensar las lecturas por ti. Entonces, sí, y creo que eso cubre todo de manera agradable aquí en cómo pensamos en el mundo y simplemente haré una pausa, he hablado mucho oficialmente, pero sí, alguna pregunta, algo en la mente de las personas que quieras escribir en el chat o desactivar el silencio y presentarte y lo discutiremos. Hola. Hola. ¿Cómo estás? Encantado de conocerte. Igualmente. Y tú, gracias por unirte. Gracias. Entonces, tengo una pregunta sobre cómo, básicamente, intentar ver cómo integrarías Polyscale para, digamos, una empresa con, digamos, los siguientes objetivos para ese backend. ¿Cómo integrarías Polyscale para manejar grandes volúmenes de, cuando necesitas manejar grandes volúmenes de respuestas automatizadas? Con la capacidad de manejar los datos que necesitan ser enviados a las API que manejan verificaciones OTP y notificaciones a los clientes. Además, canalizar esos mensajes a los destinatarios correctos. Y por último, la capacidad de crear registros y automatizar la generación de informes. Mm, sí, bien, has mencionado muchas cosas interesantes. Y veo que también hay un par de buenas preguntas en el chat, a las que nos referiremos más adelante. Entonces, sí, creo que, si intentara abordarlo de manera muy general, creo que hemos hablado de que hay algunas respuestas de formato corto que cambian con bastante frecuencia. Y son bastante recientes, por lo que son respuestas a mensajes de chat y respuestas a clientes, hasta cargas muy grandes que se ven en casos como inteligencia empresarial e informes y cosas por el estilo. Entonces, creo que hay dos áreas en eso. Si tomo primero el caso de inteligencia empresarial, y he hecho mucho trabajo en mi historia con cosas como Tableau y la creación de informes enormes. Y me he sentado allí y he visto cómo tardan 50 segundos en renderizarse, porque están ejecutando todo tipo de consultas de base de datos no optimizadas que se generan a través de la herramienta que elijas. Y, por supuesto, una vez que eso se almacena en caché por Polyscale, nuevamente lo serviremos en un milisegundo o menos, no importa el tamaño de la carga. Lo que realmente estamos haciendo es una caché basada en disco. Entonces lo estamos dejando en el disco. Tenemos l1, l2, pero el núcleo de esto es una caché basada en disco. Por lo tanto, si esa carga puede ser muy grande, realmente no importa para Polyscale para servir mejor eso. Entonces, en ese caso de uso de inteligencia empresarial y ese caso de uso de análisis, si estás utilizando un cliente pesado como Tableau o cualquier otro, el usuario solo cambia su nombre de host para conectarse a Polyscale en lugar de su base de datos de origen y nada cambia. Y luego puedes decidir, bueno, como veremos más adelante, cuando entremos en el producto, puedes almacenar en caché cosas de forma totalmente automática, puedes establecer reglas individuales por consulta SQL o incluso puedes establecer reglas a nivel de tabla. Y eso funciona muy bien en el mundo de la inteligencia empresarial, donde puedes decir, mira, sé que mi tabla de productos, la voy a almacenar en caché durante 10 minutos. O sé que solo se actualiza una vez al día, así que vamos a almacenar en caché durante unas horas. Por lo tanto, realmente puedes mejorar el rendimiento muy rápidamente en esos mundos de inteligencia empresarial e informes. Y son los que típicamente hacen consultas costosas, ¿verdad? Ya sea que estén consultando un almacén de datos o lo que sea. Y luego, si vuelvo a la primera parte de tu declaración, estás hablando de datos que cambian rápidamente a los que estás respondiendo a los clientes, tal vez mensajes de chat o...

Y, ya sabes, esas son realmente, de nuevo, si vemos las invalidaciones que pasan por PolyScale, si PolyScale puede ver esas inserciones, actualizaciones y eliminaciones, qué tan rápido están cambiando, simplemente eliminará esos data por ti para que siempre sirvas lo último.

Ahora, un caso de uso genial que tenemos en este momento estamos trabajando con un cliente es similar a esto, es una reserva en línea. Y en el mundo de las reservas en línea, tienes muchos, en este ejemplo en particular, hay un momento del día en el que todos intentan reservar. Hay un evento en el que todo está disponible y todos intentan reservar en ese momento específico. Y lo que ves es, ya sabes, pensarías que la caché no funciona muy bien en ese tipo de mundo. Pero lo que realmente está sucediendo es que cuando un espacio de reserva se agota, ves esa invalidación en la caché. Y luego, ya sabes, una vez que se vuelva a almacenar en caché en los próximos milisegundos, luego obtienes aciertos. Y en realidad puedes aliviar una gran cantidad de ese tráfico de esta especie de estampida que ocurre cuando llega a una database. Incluso en entornos de escritura intensiva, porque PolyScale es muy rápido en rehidratar la caché e invalidar una caché, puedes obtener beneficios significativos.

Y luego la última parte de la que hablaste, escalando las API y demás, vemos mucho eso donde, vale, ya sabes, no quiero sonar frívolo aquí, pero realmente me encanta, ya sabes, el JAMstack es increíble, me encanta eso, pero tienes que centrarte en cómo escalar mis API en esa situación? Y eso es, ya sabes, un caso de uso simple es, vale, necesito autenticar mi llamada a la API. Y eso normalmente vuelve a una database. Y eso es un clásico para Redis, ¿verdad? Almacenemos en caché todo en Redis para no validar esos, esos, ya sabes, esos tokens cada vez que alguien hace una llamada. Y eso es un gran ejemplo para PolyScale. Simplemente conéctalo, no hay código que escribir, escala tu API, ya sabes, sin tener que preocuparte por cómo se invalida eso. Así que sí, espero que eso responda tu pregunta. Y sí, podemos hablar más sobre eso más adelante.

¿Cómo se calculan los costos? Sí, vamos a hablar de eso. A alto nivel, número de conexiones, conexiones concurrentes, simplemente compras un plan, hay un plan gratuito para desarrolladores y si estás, ¿es Ignis o Ignes?, visita el sitio web ahora y consulta los precios y verás que hay un plan gratuito para comenzar y puedes escalar desde allí y hay un costo de salida por gigabytes transferidos por mes.

Perfecto. Solo estoy viendo una pregunta más antes de pasar a una demostración porque no puedo esperar para jugar con una demostración Pero tengo algunas preguntas sobre la caché de data. ¿Quién tiene acceso a los datos en bruto en cada nodo y los datos se almacenan cifrados? Buena pregunta. Y la segunda pregunta es la función de recomendación ¿se basa en las consultas o en los datos en bruto? Buenas preguntas. Para darte tranquilidad en cuanto al almacenamiento de datos. Hay dos opciones, puedes simplemente venir a PolyScale y utilizar nuestro servicio SaaS y nosotros almacenaremos esos datos en caché para ti. O puedes implementar PolyScale, las grandes empresas implementan PolyScale en sus propias redes para que puedan alojarlo dentro de su propia red. Por razones de cumplimiento, eso puede ser esencial. Y lo que sucede es que los datos, esos puntos de presencia dentro de una enterprise se conectan al plano de control de PolyScale que está completamente anonimizado. Por lo tanto, la administración de la caché se realiza de forma centralizada pero el alojamiento de los datos y los datos nunca abandonan tu red. El segundo punto es ser muy claro acerca de qué es lo que realmente almacenamos. No es como si fuéramos una réplica de lectura. No vamos a buscar tu database y replicar eso en algún lugar. Lo que realmente almacenamos son los resultados de las consultas. Así que si digo seleccionar todo de productos donde el nombre sea como Nike, obtengo un conjunto de resultados y eso es lo que PolyScale realmente almacena. Es ese conjunto de resultados. Por lo tanto, en cuanto a la validez de los datos y dónde se encuentran esos datos, la capacidad de interrogar esos datos de manera maliciosa, es una propuesta muy diferente a mantener una database. Oh, ya sabes, una réplica de lectura completa de esos datos. En tercer lugar, sí, podemos cifrar los datos en disco. Puedes decidir si quieres hacerlo. Pagarás una penalización en milisegundos por hacerlo, pero es completamente válido si eso es algo que deseas hacer. Y luego hay opciones de redes en cuanto a cómo aseguramos con SSL y listas de permitidos y todas esas cosas buenas que podemos cubrir y que también se encuentran en nuestro sitio de documentación. Así que definitivamente te insto a que te sumerjas allí y, ya sabes, podemos hacer todo, desde VPC peering y puntos finales hasta PolyScale dedicado completo. Así que puedes venir y decirnos, hey, me gustaría un PolyScale dedicado, por favor y podemos implementarlo rápidamente para ti. Y luego, sí, ahora pasaremos a la parte del análisis pero una respuesta rápida a esa pregunta es que analizamos en función de cada consulta SQL individual y eso es lo que recomendamos y se hace en tiempo real de manera continua. Pero sí, vamos a mostrarte una demostración rápida si está bien. Ahora lo que tenemos es un ciclo de demostración en playground.polyscale.ai y vamos a ampliar esto un poco y esto tiene tres pasos. Ahora tenemos una base de datos MySQL completamente pública y ese es un usuario de solo lectura pero sé amable con él. No es una instancia grande y lo que podemos hacer es tener un servidor de aplicaciones que es este playground. Se está ejecutando en una región de EE. UU. Este y tenemos una database que se ejecuta en la UE Oeste. Creo que eso está en París. Y si hago clic en este botón aquí, se ejecutará una consulta aleatoria durante 20 segundos y eso va directamente, como puedes ver, directamente a esa database. Y esto es, esto está fuera de nuestra VPC, es una aplicación web real legítima que se ejecuta en, creo que se ejecuta en Heroku, no tiene nada que ver con los entornos de PolyScale, y esto se está ejecutando, si nos desplazamos hacia abajo, se está ejecutando la consulta SQL lo más rápido posible de forma secuencial y simplemente estamos variando este nombre de departamento. Así que si quieres iniciar sesión en esa database y echar un vistazo, tenemos este esquema de empleado, y tiene un montón de tablas, este es un esquema público abierto que está vinculado aquí abajo, puedes jugar, y simplemente estamos variando este departamento y eso es lo que puedes ver en estos archivos de registro aquí, estamos cambiando este departamento y puedes ver, mira, la consulta promedio tomó alrededor de 400 milisegundos para esas dos regiones.

Ahora, paso dos, simplemente actualizamos literalmente nuestro nombre de host y el nombre de usuario de la database. Vamos a ver cómo conectarse a Polyscale en un segundo, pero eso es literalmente todo lo que hacemos, y luego se conectará automáticamente al punto de presencia más cercano, porque resuelve my sql.polyscale.global a donde sea que esté el pop más cercano. Así que si me conecto a Polyscale, lo que verás es que todo se almacena en caché, y luego todo, estos destellos de cosas que se almacenan en caché, aunque sean eliminadas, y luego todo se sirve en uno o dos milisegundos, y esta medida aquí incluye la latencia de la red entre la ejecución y la devolución de esos data a esta aplicación web. Así que eso es inclusivo. Y luego lo que puedes ver aquí, es como directo, hicimos 48 consultas, y a través de Polyscale, hicimos 17,000 consultas. Así que eso es genial, espero que eso te ayude a visualizar lo que hacemos, con un solo cambio de configuración, sin desarrollo, sin escribir código, sin implementar servidores. Puedes mejorar tus lecturas a nivel global, con grandes mejoras de performance. Y eso es, sí, así que juega con el Playground, que es completamente público, y ahora, pasaremos al producto, y te mostraré lo que sucede bajo la superficie. Y como usuario, ¿cómo hago esto? ¿Cómo me uno? Así que volveré, sí, vamos a sumergirnos, y echemos un vistazo a los productos.

Entonces, sí, si quieres, cualquier persona que quiera registrarse, y jugar, y jugar desde casa, adelante. Así que es completamente gratis registrarse. Como digo, puedes ver los precios aquí, y lo que hacemos es que tenemos una cuenta de desarrollador básica, 10 conexiones concurrentes, regístrate gratis. Y, si haces eso, simplemente iniciaré sesión, con mi cuenta de GitHub. Y luego eso nos llevará al panel de control. Y lo que verás es, tenemos el concepto de espacios de trabajo, donde puedes invitar a miembros del equipo, y puedes asociar múltiples cachés con eso, y voy a abrir mi caché predeterminada. Y, lo que verás es que ya tienes una caché de demostración, configurada y lista. Así que ya hay una configurada. Y lo genial de esto, solo un buen truco. Si haces clic en este botón, ejecutar consultas de muestra, te llevará de vuelta al playground, pero esta vez, cargará tu panel de control actual aquí. Así que todas estas estadísticas y cosas volverán a tu panel de control, para que las puedas ver. Así que solo una rápida, si quieres jugar, regístrate para obtener una cuenta, haz clic en ese botón de ejecutar consultas, y eso te llevará a un entorno de playground dedicado en lugar del compartido con el que estábamos jugando. Pero sí, empecemos desde el principio. Así que digamos que tengo una database, y quiero conectarme con PolyScale. En realidad voy a usar nuestro playground, que es la instancia de RDS con la que acabamos de jugar. Y si quieres esas credenciales, siempre están en la página de inicio del playground. Así que siempre están aquí si solo quieres jugar con la database. Y voy a hacer clic en nueva caché. Entonces, el escenario es, tengo una database MySQL en este caso, y quiero conectarme con PolyScale a mi aplicación web. Así que haré clic en nueva caché. Y como puedes ver aquí, le das un nombre a la caché. Seleccionamos qué tipo de database estamos soportando aquí. Así que puedes ver que hasta hoy, soportamos MySQL, Maria y Postgres. Microsoft SQL Server vendrá después. Y tenemos, ya sabes, la lista continúa después de eso. Voy a pegar mi nombre de host de origen y eso se ejecuta en el puerto 3306. Tengo un par de opciones interesantes aquí. De hecho, puedo, si quiero desactivar completamente la caché. Ahora, la razón para hacer esto es que mucha gente se registra y dice, bueno, en realidad, solo quiero poner Polysql en modo de observación. Quiero que solo observe mis consultas y muestre lo que está sucediendo en la database sin cachear nada por ahora. Y esa es una opción realmente buena. Así que lo dejaré activado en este caso. Y también puedes establecer el comportamiento predeterminado de la caché. Entonces, básicamente esto está diciendo, como cuando veo una nueva consulta, ¿debería cachearla? ¿Debería manejar eso y dejar que Polysql haga su trabajo? ¿O quiero establecer eso manualmente, no hacer nada? Y puedes configurar reglas personalizadas si quieres. Pero sí, déjame mostrarte cómo funciona la IA y cosas así. Y dejaremos esto activado. Una vez que tenga eso configurado, lo único que necesitas hacer ahora, para integrar Polysql es cambiar el nombre de host y también cambiar el nombre de usuario. Ahora, una advertencia aquí, esto es para MySQL. Sobrecargamos el nombre de usuario de la database y debes pasar tu ID de caché. Eso es lo único que necesitas hacer. En Postgres, funciona de manera ligeramente diferente en el sentido de que pasas tu ID de caché como el parámetro de nombre de aplicación. Y para dejarlo claro, solo voy al sitio de documentación. Y si vas a la sección de cómo conectarse, puedes ver que hay un, cómo nos conectamos con MySQL MariaDB, que es pasando tu nombre de usuario de database y tu ID de caché separados por un guión. Pero si estoy en el mundo de Postgres, paso un nombre de aplicación con mi ID de caché. Así que dependiendo de qué database estés usando, debes pasar tu ID de caché de una de las dos formas. Y estos datos siempre están aquí. Si, si estás, ya sabes, abriendo tu caché, tienes la pestaña de configuración aquí. Vamos a bajar un poco, supongo que hay mucha actividad, pero siempre tienes tus detalles de conexión aquí. Siempre están disponibles. Así que, ya sabes, tienes el host, el puerto y la cadena de usuario.

Sí, lo genial es que simplemente actualizan tus aplicaciones cliente para usar eso. Normalmente es un cambio de conflicto. Y lo que haré ahora es ejecutar un poco de código y simplemente mostrarte cómo podemos hacer esto.

Así que tengo un poco de código y digamos, eres bienvenido a hacer esto también. De hecho, he configurado rápidamente un repositorio de Node Congress aquí. Así que si quieres conectarte y tener una copia de tu instancia, o simplemente ver la demostración, tú decides. Y literalmente puedes elegir la opción que prefieras, ya sea, ya sabes, Prisma o PG, o, ya sabes, tengo un ejemplo de Kinect aquí para MySQL. Y, ya sabes, simplemente abre esto y juega y te mostraré cómo configurarlo.

Así que lo que tengo aquí es ese repositorio. Es súper simple. Y tengo mi ejemplo de MySQL con Kinect. Pero, ya sabes, como espero que entiendas, no importa qué opción estés usando o cómo te conectes, solo tienes que cambiar estas variables de configuración. Así que configuré mi nombre de host como, ya sabes, MySQL.PolyScale.global, que es lo que he copiado de aquí. MySQL para PolyScale está en el puerto 3306. Así que si estás usando un puerto diferente, asegúrate de configurarlo. Y luego lo importante es el nombre de usuario de la database. Así que lo que estoy haciendo aquí es pasar ese ID de caché, que es el identificador único de nuestra caché aquí, junto con un guion, y luego el nombre de usuario real de la database. Así que vamos a repasar ese ejemplo. Digamos que mi nombre de usuario real de la database, en este caso me estoy conectando a esa demo database. El nombre de usuario es PolyScale. Así que ese es mi nombre de usuario real de la database. Ahora lo que necesito hacer es simplemente poner un guion ahí, copiar mi conexión, mi ID de caché, y pegarlo delante, y ese es el único cambio que tengo que hacer, es el nombre de host, el puerto y el nombre de usuario.

Y como puedes ver, ya sabes, cuando estábamos configurando esa caché, si recuerdas, no pedimos tu nombre de usuario y contraseña de tu database, lo cual es una buena medida de seguridad, como PolyScale no puede ver tu nombre de usuario y contraseña de la database. Todo se cifra y se envía directamente a la database de origen. Así que, ya sabes, si me estoy conectando como de costumbre, ingresaré mi contraseña de la database, que es Playground. Y mi database aquí es la de los empleados. Y para ser claro, nuevamente, sé que sigo repitiéndome, pero todo está aquí en la página de inicio de Playground si quieres obtener esas credenciales. También está en el archivo readme de este pequeño repositorio de demostración. Así que aquí puedes ver que tenemos la, solo la instancia de RDS de demostración que tenemos en funcionamiento. Así que sí, si nos conectamos... Oh, lo siento, estoy un poco desordenado. Si tenemos eso configurado, eso es básicamente todo lo que necesitamos hacer. Ahora, lo que voy a hacer, antes de adentrarnos en algo más interesante aquí, es simplemente ejecutar una consulta rápida. Así que voy a comentar esto aquí. Vamos a tomar una consulta. Y voy a decir seleccionar count star from salary por diversión. Y ejecutemos ese código en mi SQL y eso hará una conexión. Oh, selecciona count star from tables employee. Así que ahí lo tenemos, cometí un pequeño error tipográfico. Lo que haré es poner node monon. Verificar que la tabla exista, creo que tenemos empleados. Bastante seguro de que existe. Ahí lo tenemos, genial. Así que ejecutamos una consulta, fantástico. Ahora, si volvemos a donde se pone interesante, verás la pestaña de observabilidad. Y la observabilidad nos mostrará cada consulta que se ejecuta a través de la plataforma. Así que aquí podemos ver que es nuestro ejemplo que ha llegado. Podemos ver que lo ejecutamos una vez, está en modo de caché automática. Así que, y PolyScale nos está diciendo actualmente que eso es altamente cachable. Ahora hagamos algo un poco más interesante.

Si hago where id equals one. id equals one. Y hagamos eso. Oh, no teníamos un id. Porque creo, oh id, escríbelo allí. Realmente debería mirar este esquema antes de empezar a jugar con él. Pero sí, lo que voy a demostrar aquí es simplemente tomar esta consulta aquí. Esto es un poco más interesante.

Entonces esto dice seleccionar count star average salary from salary. Entonces, si ejecutamos eso una vez. Lo que haremos. En realidad, no, vamos a abrir esto. Lo que voy a hacer es ejecutar esa consulta en un bucle y ejecutarla 30 veces. Veamos qué sucede cuando lo ejecutamos. Así que voy a guardar eso. Se va a conectar y está ejecutando eso. Ves 1.8 segundos, porque iniciamos una nueva conexión. Ahora ten en cuenta, estoy en mi máquina de casa aquí. Estoy en el área de la Bahía, en la costa oeste, área de San Francisco. Así que veamos qué pasó allí. Así que puedes ver que hicimos la conexión. Obtuvimos una consulta runtime de aproximadamente 1.6 segundos, un segundo, 1.2 realmente variado. Y luego mira lo que sucedió un poco más tarde. De repente bajamos a 36 milisegundos y, ya sabes, 44 milisegundos. Y eso fue PolyScale interviniendo y diciendo, bien, esto es algo que estamos viendo varias veces. Es una consulta muy simplista. Podemos establecer un alto tiempo de vida en este valor y comenzar a almacenar en caché esos data. Y veremos esto en nuestras analíticas aquí. Y un par de cosas que también notarás aquí es que anonimizamos los datos SQL data que pasan por aquí. Entonces, si tuviera un parámetro aquí que dijera, seleccionar número de tarjeta de crédito, de donde el nombre es igual a lo que sea, o donde una tarjeta de crédito es igual a este nombre o ID, en realidad anonimizaríamos eso por completo y lo sacaríamos de la consulta. Entonces nunca almacenamos ningún SQL o los parámetros se anonimizan para PII. Entonces nunca verás eso aquí. Pero espero que haya suficiente en eso para que puedas identificar las consultas.

Ahora, si por ejemplo, quisiera establecer una regla específica en esta consulta y decir, bueno, en realidad no quiero que polyscale lo gestione. Vamos a sobrescribir eso. Puedo entrar aquí y realmente puedo establecer una regla allí. Y puedo establecer eso en manual y puedo crear una consulta. Puedes ver aquí, tenemos un par de opciones. En realidad puedo crear una regla a nivel de plantilla. Y una plantilla es efectivamente una consulta SQL similar, pero donde los parámetros han cambiado. Entonces, si dijera, seleccionar estrella de usuarios donde ID es igual a uno, seleccionar estrella de usuarios donde ID es igual a 10. Es efectivamente la misma consulta, pero es semánticamente diferente. Y PolyScale clasificará eso en una plantilla, por lo que solo verás una fila aquí. Entonces, si quieres establecer un tiempo de vida específicamente, puedo hacer eso, y podría configurar esa regla aquí. Y puedes ver, presioné el botón de establecer recomendado, y ahora mismo PolyScale está recomendando un tiempo de vida de 30 segundos para esa consulta que acabamos de ver, porque no sabe más. Solo ha visto una especie de ráfaga de esos data que pasaron. La otra opción también, incluso puedo establecer reglas en tablas específicas. Y nuevamente, este es un caso de uso ideal para casos de uso de BI realmente simplistas o incluso casos de uso de e-commerce donde digo, mira, quiero que mi tabla se almacene en caché durante 10 minutos y sé que eso es lo que quiero hacer. Y esa es la otra opción que tienes. Así que eso es a grandes rasgos.

Cuando esto se vuelve más interesante es cuando empiezas a trabajar con sistemas más complejos. Puedes profundizar en esta sección de detalles. En realidad, déjame iniciar sesión como un usuario diferente, para mostrarte un conjunto de datos diferente que será un poco más interesante con algunos datos allí. Hagamos eso. Y voy a cargar este sitio de prueba de Drupal que hemos estado utilizando durante un tiempo, y en realidad no hay mucha actividad aquí, pero es un sitio de Drupal en vivo que acabamos de conectar y con el que hemos estado probando, y está tardando un poco. Debería ser bastante rápido. Vamos a probar eso. Ahí podemos verlo. Este es un informe de resumen bastante interesante donde puedes ver la cantidad de consultas que has ejecutado o has ejecutado en los últimos siete días, el tiempo de ejecución real que se ha utilizado, el tiempo de la base de datos, y luego los ahorros reales, los ahorros posibles si todo está almacenado en caché, y cuál es la eficiencia. Ahora, si miramos estos datos, voy a entrar en esta sección de detalles aquí y lo que obtienes entonces es el desglose completo de toda la observabilidad que está ocurriendo. Entonces, puedes ver, este es un buen ejemplo donde puedes ver estos signos de interrogación aquí donde hemos reemplazado los parámetros. ¿Ves qué tablas se han accedido? ¿Esta consulta es una DQL, un lenguaje de consulta de datos? ¿Es una consulta de lectura? ¿Es un show o un select? En comparación con una consulta DML, que es una manipulación e inserción, actualización o eliminación. Y para ser claro, de forma predeterminada, nuevamente, nos esforzamos por ocultar esta complejidad. Ocultamos las consultas de manipulación. Entonces, lo que estás viendo aquí son solo las consultas que se pueden almacenar en caché. Entonces, puedo entrar en esta opción de filtro y puedo decir, muéstrame las consultas almacenadas en caché versus las no almacenadas en caché, pero específicamente, ¿quiero solo las DQL? ¿Solo quiero los shows y los selects? Y puedo desactivarlo y luego puedo ver todas las lecturas, las inserciones, actualizaciones y eliminaciones también. Y puedes ver estas categorías amplias en la parte superior. No te sientas abrumado por los detalles aquí. Pero, puedes ver mis consultas. ¿Cuántos aciertos y fallos he tenido? ¿Cuántos son distintos? Así que ese concepto de una plantilla de consulta donde puedo tener, ya sabes, 5,000 consultas únicas, la misma consulta, pero con diferentes parámetros, eso es lo que estás viendo aquí. Y la razón por la que es un decimal, por cierto, es porque estamos en el intervalo de 15 minutos. Así que estamos dividiendo esto. Puedes ver aquí, esta consulta en particular no está en caché. Como, hemos desactivado la caché en esta. Podemos ver nuestras tasas de acierto, y así sucesivamente. Puedes ver los tiempos de ejecución totales en segundos en comparación con los tiempos de ejecución promedio en minutos. Y si vamos al playground público de datos aquí que acabamos de ejecutar, veremos algunas estadísticas interesantes aquí. Dejemos que esto se cargue. Esto es solo para los últimos 15 minutos y las consultas que estamos ejecutando a través de la plataforma. Eso es bastante lento. Mira eso. Sí, y esto es interesante. Esta es la consulta del playground que ejecutamos, de la que hablamos antes, y puedes ver ese nombre de departamento ahí siendo anonimizado, y podemos ver que ejecutamos 12,000 de esas. Y si empiezas a mirar luego el tiempo ahorrado, eso en realidad ahorra poco menos de 80 minutos de tiempo de ejecución de la base de datos. Esa ejecución del playground que todos hemos estado haciendo en el sitio, donde ejecutamos 12,000 consultas, bueno, eso parece ser solo una ejecución en los últimos 15 minutos, que en realidad ahorra casi 80 minutos de tiempo de ejecución de la base de datos. El tiempo real y el tiempo nominal, y luego puedes ver aquí los desgloses de los tiempos de ejecución promedio también. Así que realmente puedes profundizar en todos los detalles de exactamente qué consultas están ocurriendo, y como dije antes, polyscale mostrará las que se almacenan en caché en gran medida en comparación con las que no se pueden almacenar en caché. Así que sí, espero que eso sea útil, y solo para resumir aquí, en la página de Configuración, puedes cambiar tus valores predeterminados sobre cómo se comporta la caché. Puedes purgar, así que volviendo a una pregunta que tuvimos antes, puedo iniciar una purga global si quiero, por cualquier motivo. Si he configurado algunas reglas manuales en mi caché, y he dicho, bueno, vamos a almacenar en caché estas pocas consultas manualmente, o estoy ejecutando cosas automáticamente, en realidad puedo ir y eliminar esas reglas. Así que puedes restablecer cómo estás gestionando las reglas cuando llegan. Y finalmente, puedo eliminar esta caché si quiero borrar todo y deshacerme de esto. Así que sí, eso es un breve recorrido de una descripción general de alto nivel de Polyscale y cómo funciona. Y solo un par de casos de uso en los que nos enfocamos mucho es el regional, del que hemos hablado mucho, pero el otro también es, si solo quieres escalar una base de datos, trabajamos con muchos clientes que se centran en eso y el rendimiento de las consultas de lectura es la otra parte clave de esto. Así que realmente son las áreas en las que nos enfocamos. Entonces, nuevamente, voy a hacer una pausa aquí. Eso es prácticamente todo el material que quería mostrar y sí, me encantaría cualquier pregunta, cualquier cosa que no haya cubierto y que te interese, o si hay algo que hayas visto que despierte interés, entonces sí, definitivamente desactiva el silencio, avísame. Hola. Hola Nishant.

Hola señor. Hola. Quiero preguntar, ¿funciona solo con MySQL o este lenguaje como trabajo con MongoDB, el lenguaje de Mongo. ¿Cómo funciona con ese lenguaje? Sí, aún no. Mongo no es compatible en la actualidad. Entonces puedes ver que tenemos MySQL, Maria y Postgres, SQL Server es el siguiente y probablemente luego MySQL. En lo que nos estamos enfocando en este momento son las bases de datos basadas en TCP puro que son difíciles de escalar. Ahí es realmente donde ha sido nuestro enfoque. Y más adelante este año agregaremos soporte para HTTP con GraphQL y, ya sabes, avanzando hacia cosas como Elasticsearch y Mongo también.

Sí, señor. Como el lenguaje principal, Elasticsearch y Mongo son muy fáciles de responder a estos lenguajes. Exactamente. Así que sí, gracias. Por ahora solo los tres son compatibles, esperamos que Microsoft SQL Server, solo porque tenemos una gran demanda. Esperamos que sea alrededor de marzo. Esa es la ETA actual.

Hola. Hola, Jean. ¿Es Jean o Jean? Es Jean. Jean, un gusto conocerte. Un gusto conocerte. Bueno, felicitaciones por el producto que ustedes han desarrollado. Es increíble. Bueno, trabajo en un producto a gran escala que hemos distribuido en cinco regiones a nivel mundial. En las mejores semanas del año, llegamos a tener hasta 33 millones de visitas. Cuando me uní al proyecto hace un par de años, una de las primeras cosas que hicimos fue trasladar la infraestructura, ya sabes, de local a estar completamente gestionada en AWS. Estamos utilizando Atlas y en Rackspace estamos utilizando SQL Server. Así que me alegra mucho escuchar que definitivamente están considerando admitir SQL Server. Sí. Y me gustaría agregar que Mongo sería increíble para nosotros también, porque honestamente, la forma en que hemos arquitecturado nuestro producto es básicamente Mongo para los derechos y luego SQL Server para los informes. Eso significa que realmente no necesitamos caché para SQL tanto como la necesitamos para Mongo, que utilizamos para, por ejemplo, obtener datos de Mongo para imprimir, bueno, para renderizar páginas de inicio y estas deben renderizarse en 200 milisegundos o menos. Y realmente no estamos cumpliendo con ese objetivo y tener algo como esto, como hemos pasado por varias iteraciones utilizando Redis y cosas así, definitivamente mejoraría significativamente nuestra vida. Así que realmente voy a estar atento a Polyscale por esto, hay varios miembros de nuestro equipo que están mirando esto y nuestras mentes han explotado y eso es genial. Es genial escuchar eso. Es genial escuchar que la empresa está considerando una solución como esta si ustedes implementan Mongo y SQL Server. Definitivamente. Como dije, SQL Server está en proceso y ya hemos comenzado a trabajar en eso, y Mongo estará disponible poco después. Sí, hemos escuchado lo mismo de muchas personas, definitivamente hemos escuchado eso. Gracias por compartir tus casos de uso. Creo que, sí, en ciertos lugares la caché tiene mucho sentido cuando necesitamos una latencia muy baja y medio segundo no es suficiente o cinco segundos no son suficientes. Y es genial escuchar que estás en ese mundo donde tienes esos dos sistemas diferentes. Estás en ese mundo políglota y eso solo va a, supongo, basado en el éxito de tu negocio, eso se escalará. Necesitas llegar a diferentes regiones y a más personas y los datos están aumentando de tamaño. Así que el problema no desaparecerá. No sé si es algo de lo que quieras hablar, Sean, pero tus experiencias con Redis y obviamente Redis es un producto fantástico. ¿Y encontraste que eso no iba a funcionar o simplemente no has intentado ese proyecto o se volvió demasiado complejo o en qué punto llegaste con Redis? Hola, soy- Todavía estamos en medio de eso. De hecho, como dije, hemos hecho varias iteraciones. Incluso hay una iteración antigua en este momento que nos está volviendo locos porque tiene una pequeña fuga de memoria en un nodo. Eso se debe a que es un servidor heredado que debería ser eliminado pronto. Pero sí, agregar Redis no es tan sencillo como la gente podría pensar cuando se trata de escalabilidad. Por ejemplo, estamos utilizando AWS con Fargate y Fargate solo permite exponer el puerto 80. Entonces, cuando intentas agregar Redis internamente, porque eso es una de las cosas que estábamos intentando hacer, como poner Redis directamente en la imagen de Docker para que la aplicación pueda comunicarse directamente con él, sin complicaciones y tener todas nuestras aplicaciones como réplicas de lectura del maestro, eso no tuvo éxito debido a eso, o simplemente agregó complejidad. Esas son las cosas que generalmente descubrirás que sería mucho mejor simplemente dárselo a alguien como tu equipo y dejar que la inteligencia artificial se encargue de ello. Nos encantaría algo así. Sí. Fantástico. Es genial escuchar eso. Gracias por compartir eso. Y solo quiero responder rápidamente una pregunta en el chat. ¿Hay alguna forma de realizar anulaciones manuales a través del código? Absolutamente. Entonces, si consultas la documentación, tenemos una API completa a través de la cual puedes, sí, todas las funciones están expuestas allí para que puedas hacer lo que quieras hacer. Así que nuevamente, eso va en contra de nuestra estrategia sin código, pero sí. Hay situaciones en las que definitivamente necesitarás o querrás, tú sabes mejor que la máquina, y es posible que solo quieras invalidar en el momento adecuado. Así que sí. Bien, ¿alguien más tiene alguna pregunta? ¿Es Mabeko? ¿Estás sin silenciar? Sí, tengo una pregunta. Disculpa si me lo perdí.

Te escuché al final. Estabas hablando de que esto es básicamente un servicio al que apuntas cuando tienes una gran database, y eso es algo en lo que quería aclarar. ¿Qué sucede cuando tienes muchas bases de datos diferentes? Digamos que tienes cientos de departamentos que algunos pueden tener sus propias bases de datos, y otros pueden tener bases de datos que desean mantener completamente separadas, ¿necesitas entonces cuentas diferentes que sean completamente separadas para cada uno de ellos, o hay una integración que se puede hacer?

Creo que lo que estás describiendo aquí es que Polyscale tiene el concepto de espacios de trabajo. Te lo mostraré rápidamente, iniciaré sesión como un usuario diferente, y un espacio de trabajo es efectivamente una entidad que puede tener una o más cachés. Entonces podrías usar un espacio de trabajo para un departamento. Podrías usar, aquí estoy en mi espacio de trabajo predeterminado, y cada espacio de trabajo está asociado con la facturación. Entonces puedes configurar una o más cachés en ese espacio de trabajo, y podría entrar y crear una completamente nueva que podría ser para un departamento, lo que sea. Y allí, podría crear diferentes cachés, y luego puedes establecer permisos en tus espacios de trabajo, a quién invitas... Si voy a los accesos, a quién invito a estos espacios de trabajo y establezco sus permisos. Entonces puedes configurarlo para ser una gran enterprise o diferentes departamentos o lo que necesites. ¿Eso responde tu pregunta?

Sí, sí, creo que responde la pregunta. Así que solo una cosa más con esos espacios de trabajo, ¿se te permite tener diferentes bases de datos en ellos? ¿Podrías decir que tendría una base de datos de administrador?

Sí, absolutamente. Entonces, cuando creas una caché, sí, cuando creas una caché, cada caché es una base de datos diferente, ¿verdad? Es independiente, pero simplemente seleccionas tu database y puedes tener... En mi cuenta de demostración, en la que estaba hace un minuto, teníamos Postgres, MySQL, MariaDB. No importa, todos están bajo el mismo espacio de trabajo. No hay problema. De acuerdo, bien. De acuerdo, muchas gracias. Gracias. Hay un par más en el chat, echemos un vistazo. No hay repositorio de congreso. Parece ser privado. Oh no, qué fallo. Veamos si puedo cambiar eso rápidamente. ¿Puedo interrumpir? Por supuesto, sí, por favor. Sí, tengo una pequeña pregunta. Básicamente estoy ubicado en India. Sí. Fue muy agradable interactuar contigo en la aplicación de Polyscale. Y tengo una pregunta muy pequeña. ¿La aplicación de Polyscale qué impacto podría tener en una base de datos a gran escala, cualquier impacto en el performance al intentar operar en una base de datos pequeña? Entonces, si entendí bien tu pregunta, el rendimiento de las bases de datos pequeñas versus las bases de datos grandes, esa es el área en la que estás pensando. ¿Era eso lo que querías decir?

Sí. Sí, quiero decir, con respecto a la base de datos de origen, Polyscale es algo así como agnóstico, no importa, es solo una caché de paso. Entonces, la carga que tu base de datos de origen está manejando hoy, no le importa a Polyscale. Ya sea que estemos sirviendo algo desde una caché o permitiéndole llegar a la base de datos de origen. Entonces, nada cambia con tu base de datos de origen. Puedes ejecutarla en una cuenta de RDS de $10 al mes, una cuenta de $30 al mes, hasta clientes que tienen instancias únicas de $25,000 al mes. Entonces, la base de datos de origen no tiene nada que ver con Polyscale aparte de que somos un paso de vuelta a ella, si eso tiene sentido.

Sí, gracias. Genial. Otra pregunta en el chat, ¿hay un paquete para desarrolladores estudiantes? No, nada específico para estudiantes. Obviamente, tenemos cuentas gratuitas y definitivamente podemos hacer cuentas sin fines de lucro, pero no, creo que la plataforma es la misma para todos y se escala para todos, pero sí, avísanos si tienes algo específico en mente y veremos cómo acomodarlo. De acuerdo. Sí, tengo una pregunta más también. Sí. Sí, acabo de pensar en esto. No estoy seguro si es posible. Lo que entiendo es que, básicamente estás tratando de posiblemente reducir la cantidad de integraciones que necesitarías hacer a los costos de la base de datos y entonces, ¿sería posible eliminar completamente algo como Redis o necesitaría una integración al mismo tiempo?

Sí, quiero decir, vemos casos de uso donde la gente elimina completamente Redis así que no quiero hablar específicamente de Redis porque me encanta el producto, es genial, pero los detalles de ejecutar caché en la capa de aplicación se pueden eliminar. Entonces, estás dando un paso atrás, lo estás almacenando en esa capa de datos en lugar de hacerlo en la capa de aplicación y solo piensa en el lujo de no tener que preocuparte por esa sobrecarga de código y las complejidades allí. Ese es realmente el beneficio que brindamos. Acabo de hacer que la repetición sea pública, por cierto así que siéntete libre de probar, pero eso es exactamente correcto.

Eliminamos esa complejidad de tener que escribir tu propia lógica y mantenerla a lo largo del tiempo. De acuerdo, sí, bien. Ahora, creo que entiendo. Genial.

Entonces, ¿cuál es el nombre del repositorio nuevamente? Es, déjame mostrar la diapositiva. Simplemente busca polyscale en GitHub y es node congress 2022, ese es el que está ahí.

Tengo que hacer un poco de publicidad descarada, estamos contratando y nos encantaría hablar con cualquier persona si está interesado. En este momento, estamos contratando un defensor del desarrollador, un ingeniero full stack de React y TypeScript, y un ingeniero de backend enfocado en C++. Y puedes leer más sobre la empresa en el sitio web, pero somos una empresa pequeña y somos 100% remotos. Sí, nos encantaría hablar con cualquier persona que esté pensando si esto le parece interesante y estamos cambiando la forma en que se escalan las bases de datos, esa es realmente la misión en la que estamos. Así que sí, echa un vistazo al sitio web y la sección de carreras allí y puedes leer más sobre los roles.

Echemos un vistazo. ¿Alguna otra pregunta en el chat? Echemos un vistazo. Gracias por compartir el enlace. Sí, ¿alguna otra pregunta de alguien? Señor, ¿hay alguna oportunidad interna también? Lo siento, Nishant, ¿puedes repetir eso? Pasante, como ingeniería de software adecuada- Oh, pasante, sí, y no en este momento, probablemente el próximo año, más adelante este año. Sí, en este momento no, solo estamos contratando posiciones a tiempo completo, pero sí, definitivamente estaremos buscando realizar un programa de pasantes en los próximos seis meses aproximadamente. Lo siento.

De acuerdo, eso es bueno. Entonces dijiste que esos puestos son remotos en primer lugar, ¿verdad? Así es, somos una empresa con enfoque remoto. No tenemos oficinas, estamos completamente distribuidos. Tenemos personas en todo el mundo en todo tipo de lugares geniales. Sí, damos la bienvenida a eso. Somos una empresa con enfoque remoto.

De acuerdo, bien, sería bueno investigar eso. Genial, fantástico. Me alegra que haya sido útil, y sí, de acuerdo. Concluiremos, todos.