Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Juan (00:03)
Muy bienvenidos sean todos a nuestro nuevo episodio en Demenops, el podcast favorito de todos en cuanto a tecnología, al menos es mi favorito. El día de hoy me acompaña como siempre o como casi siempre mi buen amigo y co-host Douglas. ¿cómo tal? ¿Cómo estás Douglas? Hoy ando un poco trabado, lo siento.
Douglas (00:25)
Juan.
No, siempre hay días así. es que realmente que, sobre todo en la actualidad, tratar de estar al día con todos, lo que tiene que ver con inteligencia artificial, más el trabajo y cómo van evolucionando las herramientas locales y las herramientas de colaboración entre equipos, etcétera, como que nos deja la mente un poco trabada. ¿Podemos hacer más cosas? Sí, podemos hacer más cosas en un día, pero la mente, pues al final sí no descansa.
Juan (00:50)
revuelta.
Douglas (00:57)
Pero sí, fuera de eso, realmente como siempre, contento de una conversación más con vos y pues saber qué valor podemos aportarle a todas las personas que nos vengan y nos escuchan.
Juan (01:09)
Es correcto. La idea siempre es traer algún tema que sea interesante para todos, los que nos ven y nos escuchan, para que de alguna forma estén ya sea actualizados o sepan qué hacer en ciertas situaciones en este mundillo de tecnología que nos encanta tanto a Douglas y a mí. El episodio de hoy va a ser un episodio un tanto experimental dentro de nuestro canal, ya que vamos a revisar algunos
artículos que nos han llamado la atención. Esta ocasión los he elegido yo, así que Douglas no sabe muy bien qué le traigo a la mesa, pero estoy seguro que Douglas, como siempre, nos va a aportar cierta información y un punto de vista muy interesante para todos. La idea es, nuevamente, hablar sobre lo que está sucediendo en la actualidad y poder dar nuestras opiniones de manera muy personal con la experiencia que hemos tenido en
en nuestra carrera a lo largo de los años. que, ¿qué te parece si comenzamos este nuevo episodio?
Douglas (02:16)
No, comencemos. La idea me gusta bastante. Es algo que hago todo el tiempo, todos los días. De hecho, estar viendo noticias y artículos relacionados con tecnología. Y el día que estoy más enfocado en tareas bien complejas, el artículo de instalar algo en mi local es el que me llama la atención. Y el día que estoy haciendo cosas simples, aquellos artículos de cosas súper complejas son los que me atraen. Así funciona la mente de maneras extrañas. Pero el simple hecho de que vayamos a...
a reaccionar a estos diferentes artículos y noticias me genera emoción.
Juan (02:50)
que bueno yo también paso leyendo y para los que estén interesados bueno vamos a dejar los enlaces de los artículos que vamos a tocar en la descripción de los vídeos y bueno también les recomiendo yo esto los he sacado de una aplicación que se llama app.daily creo que se llama así app.daily también lo puedo dejar en el enlace si les parece donde yo voy leyendo artículos y los que me llaman la atención los voy marcando
Así que, bien, vamos a ver el primero. El primer artículo lo tengo por aquí, Douglas, y se llama o dice el título, Python, perdón, usa Python para scripting. Aquí se refiere a reemplazar Python contra lo que es bash scripting o shell scripting, como le quieran llamar. Y ya hemos hablado en ciertas ocasiones, ¿no Douglas?, sobre utilizar bash o incluso nos has compartido que también has...
incursionado un poco o bueno a estas alturas creo que mucho más en utilizar python para estas tareas así que creo que va ser un artículo donde nos vas a poder compartir muchas de tus experiencias y bueno voy a ir leyendo para los que sólo nos están escuchando pueden también pasarse al modo de vídeo si nos están escuchando por ejemplo en spotify spotify tiene un modo de vídeo
y bueno, los que no importa, a ir leyendo y voy a ir dando el resumen de lo que tenemos por aquí.
Douglas (04:22)
pueden darle click al link y que traten de seguir la lectura también como un apoyo.
Juan (04:27)
es correcto porque yo voy a ir leyendo ciertas partes pero pues ahí pueden ir leyendo un poco más por su propia cuenta y bien el autor del artículo habla un poco sobre cómo los shell scripts son muy importantes para muchas cosas ya sea para alguien que lo utiliza en su ambiente y para provisionar infraestructura como para los developers que simplemente estamos tratando de hacer el build de una aplicación
y bueno en el artículo él detalla un ejemplo que utiliza para ejemplificar este tipo de cosas, valga la redundancia donde él trata de hacer el build de una aplicación pero sabe que este script lo quiere ejecutar desde cualquier parte del directorio entonces empieza a detallar cómo él haría este bash script y vemos, para los que estamos leyendo aquí
vemos que él detalla muchos ejemplos y también está agregando líneas de código líneas de código para mi Douglas que no conozco mucho bash siempre son un poco intimidantes por ejemplo tiene aquí una línea que dice fine buildgen menos type f contrapleca y empieza a listar muchas cosas ⁓
El punto de esta parte o de esta sección del artículo es que él menciona que si bien funciona como lo tiene, tiene ciertos problemas o tal vez no problemas pero ciertos, no sé cómo traducir esta palabra Douglas, issues, vamos a llamarlo como problemas, me gusta. Dice que para él funciona pero para usuarios en Mac
Douglas (06:09)
problemas, inconvenientes problemas.
Juan (06:17)
estos pasos van a fallar porque tiene ciertos llamados a ciertas librerías o comandos que no funcionan del todo bien en versiones que no son de Linux. En el caso de Mac van a fallar y también lo que él menciona este otro sistema operativo, BSD, también va a tener ciertos problemitas. Entonces, uno de los mayores problemas que él relata en este artículo
es el hecho de que la portabilidad de los bash scripts simplemente con bash es más complicada luego es donde aquí es donde él muestra que la solución para esto sería python ¿por qué python? bueno python viene instalado en ciertos o bueno casi todos los sistemas de hoy en día muchos desarrolladores están familiarizados con el lenguaje de python
y Python tiene muy buenas lo que es el Standard Library, lo que viene ya por defecto en Python es lo suficientemente grande como para hacer casi prácticamente cualquier script que se te ocurra y bueno el código de Python es más fácil de leer. Esto es lo que él menciona Douglas, la verdad es que aquí creo que podríamos hacer la primera pausa para comentar este artículo.
el hecho de que la portabilidad sea un problema como tal con el bash script yo tengo mis opiniones no se vos que me podrias decir al respecto sobre el hecho de hacer bash scripts que van a funcionar en linux pero no van a funcionar en otros sistemas operativos o hacer un bash script que se acomode a diferentes sistemas operativos no se que
¿Qué opinas en este primer punto que él relata?
Douglas (08:17)
Fíjate que mira, voy a dar una respuesta larga, que no... procurar cuidar el tiempo, pero una respuesta larga para que las primeras palabras que salgan de mi boca no se consideren como la respuesta final, sino que va a ser un todo. Comparto lo que le está diciendo.
Juan (08:21)
Perfecto, perfecto.
Douglas (08:36)
definitivamente existen esos problemas de portabilidad con bash entre diferentes versiones dentro del mismo Linux, no digamos que estamos haciendo entre el Linux subsystem dentro de Windows y Mac y diferentes distros de Linux, eso en realidad existe y con Python ese problema se reduce bastante porque no es que es cero
porque si yo hice el script en python 3.15 y lo muevo a un equipo que solo tiene python 3.9 es muy probable que voy a tener problemas porque no tengo python 3.5 disponible entonces hay que también ver ese tipo de cosas ¿se resuelve con un upgrade de python? sí, pero si el sistema operativo
de ponerle estoy corriendo en un centro de 7 o algo no puedo instalar la versión nueva entonces caigo en lo mismo de portabilidad sí o tenés otros scripts y otras cosas que te funcionan en esa otra versión y no puedes actualizar entonces no es que la portabilidad es cero sin embargo se reduce mucho se reduce por por montón verdad entonces en esa parte estoy 100 % de acuerdo
Juan (09:36)
o si el usuario por algún motivo no quiere actualizar.
Douglas (09:53)
lo que veo este artículo que tiene su punto válido pero está orientado a scripting para procesos personales o locales, tu local, para el ejemplo que pone ahí era sin mal no recuerdo el código book.
Juan (10:12)
hacer un build.
Douglas (10:13)
Ajá, y buscaba los gem files o los build gems parece y mira, build gem y busc por nombre y luego le es el en primer la lista y el otro que dice ex-arcs lo va a borrar, lo que encuentra y entonces está haciendo ese tipo de cosas y son para algo más local.
Entonces, en ese sentido, si te estás moviendo entre diferentes ambientes o si es un script para que haga un build local y se lo estás pasando a otros programadores, va a generar esos problemas de incompatibilidad. Pero cuando nos vamos a orquestración...
Juan (10:46)
correcto
Douglas (10:51)
Normalmente los servidores en una empresa corren la misma distribución de Linux en su gran mayoría. su vasta mayoría, empresas trabajan con distribuciones Debian Ubuntu o trabajan con distribuciones Red Hat, Rocky Linux, Fedora. Y entonces en ese sentido, Batch se vuelve...
con pocos problemas de portabilidad porque estás lidiando con la misma distribución.
Juan (11:22)
Si, normalmente
se busca tener un estándar, si vamos a hacer máquinas virtuales pues que siempre tengan una o dos variaciones por mucho, la misma imagen.
Douglas (11:34)
a lo mucho, a lo mucho, una o dos versiones y siempre te vas a topar con el escenario de que si trabajas con Red Hat vas a ocupar aquella máquina Ubuntu por X y Y emotivo siempre se dan esos escenarios o al revés, si trabajas con Ubuntu siempre va a haber una necesidad de una Red Hat pero sin embargo aún ahí el script
Juan (11:49)
Por ahí hay una red.
Douglas (11:53)
va a ser portable porque sobre todo hoy en día casi que manejan el mismo administrador de servicios y ese tipo de cosas. a nivel de servidores y en mi experiencia, bas scripting, he tenido muy poco problema de portabilidad. ⁓
Ahí está la idempotencia, se dice en español, la idempotencia, que tenés que tener cuidado con un script para repetirse, que si lo haces con Python, pues como funciona como un lenguaje de programación, tiene librerías y clases y cosas que te van a ayudar con ese tipo de problemas, pero en general, ya nivel de servidores...
Juan (12:17)
Sí. Sí.
Douglas (12:36)
En mi opinión y mi experiencia eso no aplica. Yo dije hace unos cuantos episodios que vos me preguntabas de cómo me iba con Python ahora que trabajo mucho más. Yo he sabido Python por muchos años pero le he dedicado en el último año más tiempo y me ha permitido hacer automatizaciones con cuestiones en Kubernetes y operadoras de Kubernetes y ese tipo de cosas. Pero mi scripting sigue siendo en Bash. No he tenido la necesidad de hacerlo. Entonces a nivel de
lo que este artículo dice no afecta tanto. A nivel personal sí puedo ver que lo que este artículo está diciendo puede ser un problema y definitivamente yo también recomendaría Python para scriptings locales, personales o de desarrollo.
Juan (13:26)
Yo también, eso es que pensaba, a nivel de servidores, a nivel de orquestración de servicios y todo, pues no es el fin del mundo, la verdad no pasa nada, es muy raro lo que va a cambiar y pues supongo que Python sería para ciertas cosas, luego él habla de los otros temas y aquí tengo el artículo, habla sobre
luego el artículo sigue hablando sobre cada uno de ellos, lo que es el hecho de que está instalado en casi todos los sistemas, tiene una librería estándar muy fuerte. Sin embargo, aún con esto, yo sigo teniendo mis dudas. ¿A qué me refiero? ¿Python está instalado en casi todos los sistemas? ¿Qué tan cierto será eso?
hasta donde yo recuerdo en Windows no viene instalado por defecto no sé si ahora ya sea así yo creo que no hay que instalar Python
Douglas (14:27)
Sí, no que yo sepa, no que yo sepa.
Juan (14:28)
Sí,
yo no recuerdo.
Douglas (14:30)
Pero ahí Juan, una automatización que sea entre diferentes plataformas, sobre todo en el caso de Windows, Linux, sí lo veo un poco más difícil. Pero si tenés tu Linux Subsystem, verdad que podés tener eso en Windows hoy en día, y ese Windows, ese Linux Subsystem interactúa con tu File System en The Windows, entonces pudieras aprovechar eso para usar tus scripts de Python por ese lado.
Juan (14:47)
sí.
Si es correcto. Yo lo que pienso Douglas, si alguien está pensando en utilizar Python para automatizar ciertas cosas de su máquina local, por ahí estuve leyendo muchos comentarios, la gente hablaba que Python tiene un modo script y por lo que entendí, porque no estoy familiarizado con esto, hablan que Python te deja hacer un script que ya tiene todo lo que necesita.
por ende corre casi de manera standalone eso puede ser una gran solución sin embargo bueno yo en lo personal cuando necesito este tipo de cosas yo lo que suelo hacer es crear un script bueno ya no sería un script sino más bien un binario que esto para mí es un poco mejor pero claro aquí ya tendríamos que hacer un build para linux para mac y para windows
en el caso de Go o SIG es relativamente fácil pero bueno, Python es un lenguaje que cada vez se vuelve más popular y más importante en la industria que también vale la pena entonces yo diría que bueno, si tratamos de darle una puntuación al autor del artículo quedaría como que bueno, tiene razón un 10 de 10 en ambiente local
pero un 0 de 10 en ambientes de servidores.
Douglas (16:31)
yo le daría un 5 de 10 en servidores, 10 de 10 en ambiente local, 5 de 10 en servidores porque no quiere decir que está malo el que haga scripting en python para servidores y te va funcionar más dinámico y mejor que vas, supuesto. Lo que ocurre es que llega a un nivel en el que si un script no te resuelve, normalmente ya es otra tipa de herramienta de orquestración más grande la que necesitas y salirte del universo de scripting.
Juan (16:40)
buen punto, ¿cierto?
Sí.
Douglas (17:01)
verdad
Juan (17:02)
ok
Douglas (17:03)
y comenzar
a orquestraciones diferentes. lo que ocurre y ese es el motivo, ese es el principal motivo por el cual lo que tiene que ver con scripting yo nunca me aviso la necesidad de usar Python porque cuando va más allá te salís de esa realidad de scripting y te vas ya a herramientas más complejas. Pero si alguien usa Python va a poder hacer más con scripting. Entonces no es mentira. Sin embargo, no te topás con eso de la portabilidad y lo que vos decías, no Python, yo creo que te estabas refiriendo a que podés hacer
un paquete de pip, has visto que le das pip install y la requerimiento, entonces lo puedes hacer como un pip package y con instalas local de esa manera y corres tu script y de esa manera de hecho se publican utilities entre servidores y servicios en un ambiente local, tienes tu repositorio interno de paquetes de pip y los están instalando y así lo utilizas.
Juan (17:36)
sí.
Douglas (17:59)
pero con bash puedes hacer lo mismo que te funciona como un comando, guardas al script lo puedes guardar con esta extensión si queres .sh, ponle que tenes un script que te mira cuanto lo ejecutas y cuanto espacio en logs tienes de nginx por ejemplo, el director de nginx cuanto espacio está utilizando, entonces vos le puedes llamar nginx-size.sh o solo nginx-size, lo guardas así.
y guardar el script en tu pad, vos sabes que los directorios Linux no tienen diferentes, la variable pad en todo en mayúscula y guarda diferentes directorios que lo que sea que esté en esos directorios lo va a tomar como ejecutables.
Juan (18:33)
Sí.
Douglas (18:43)
Entonces si vos guardas tu script en uno de esos directores del pad, te funciona como un comando de linux, verdad? Entonces con bash también puedes hacer ese tipo de cosas y de nuevo no es que estoy queriendo forzar bash, sino que tiene razón en 5d 10 a nivel de servidores porque sí puedes hacer más con python pero normalmente cuando ocupas más se convierte para nosotros en sistemas a que ocupamos otro tipo de herramienta y no scripting.
Juan (19:13)
Si, si tenes razón. Y bueno, otra cosa que tal vez puedo verle a favor a Python es que trabajar con ciertos archivos o ciertas cosas puede ser un poco más elegible o fácil de leer, no? Como el caso de tal vez manipular un JSON o un Jammer. No es que no se pueda en Bash, puede ser que incluso para alguien que viene empezando sea más fácil, tal vez con Python. Eso es lo único que se me ocurre.
Douglas (19:42)
Mira, pero es que ahí Juan, y aquí de nuevo, ¿no? Para alguna cosita rápida, sí, pero si ocupas mucho manipulación de Jason y Jamal, ¿en realidad es un script lo que ocupas o en realidad es una aplicación diferente? Ya puede ser incluso irse más allá del mundo de CLI.
que ya no es un script, es diferente entonces por supuesto prefiero Python que yo he hecho varios CLI en Bash ¿verdad? pero sí si vas a ocupar bastante JSON, bastante Jamal que conectarte a Redis y ejecutar tareas dentro de Redis cosas como eso por supuesto que necesitas Python pero yo vuelvo a mi... este es mi argumento ¿no? en realidad ya es un script o en realidad ya es una lógica de programación que se requiere más pero si solo es que agarras un
Juan (20:03)
Sí, sí,
Douglas (20:32)
endpoint que te revuelve un JSON y en base a eso vos vas a buscar uno o dos valores y hacer algo en tu script, bash lo puedes seguir haciendo y no tenés que invertir el tiempo en reemplazar todo un script que ya hace un montón de cosas por python sólo porque ahora querés manipular una respuesta en JSON
con la IA definitivamente es rápido, IA te convierte ese bash a python, no ese python a bash y te lo convierte a lo que sea y no tienes problema, hay que instalar requerimientos en los servidores, hay que hacer pruebas, etcétera, entonces porque vas a ver la respuesta de un JSON, vas a convertir todo un script a python, yo te sugeriría que no, verdad.
el esfuerzo, pero cada quien que lo pueda valorar de esa manera, sí quiero recalcar que él tiene toda la razón en el ambiente local, no queremos aquí pretender que sabemos más que nadie, simplemente estamos remarcando que el artículo va orientado por lo que estamos leyendo a ambientes locales.
Juan (21:36)
correcto, me gusta tu conclusión, me gusta, por cierto hemos dicho él pero no sé si será
hombre o mujer quien posteó esto bien el autor o la autora
Douglas (21:51)
El autor.
es que el autor pudiera aplicar ambos.
Juan (21:58)
podría... ok. Pasemos al siguiente artículo que tengo por aquí Douglas, es uno que me llama mucho la atención y aquí tengo como sentimientos encontrados con lo que habla. El artículo dice la trampa de utilizar la herramienta correcta. ¿A qué se refiere? Bueno, el artículo habla sobre utilizar diferentes bases de datos y acá tenemos una lista, por ejemplo
Elasticsearch para búsquedas, esto se refiere más que todo a búsquedas de texto y texto grande, como cuando tenemos una barra de búsqueda tipo Google, elasticsearch. Tenemos pinecone para vectores, normalmente ahora con la IA y sistema rack se utiliza este tipo de bases de datos. Tendríamos redis para el caché, por ejemplo, Douglas siempre nos ha hablado mucho sobre redis.
y como ha hecho la diferencia en ciertas ocasiones el tener y no tener redis también lista a MongoDB para lo que son indexar documentos esto es para cuando tenemos la necesidad de tablas o bases de datos no SQL tendríamos Kafka para los que use este sí me parece muy interesante que lo nombre
Douglas (23:24)
Mm-hmm.
Juan (23:24)
entiendo
el por qué pero para mí es difícil no hablar de casca ya vamos a ir viendo luego habla otro sobre lo que es influx dv que es para series de tiempo este sí no lo conozco para ser honesto no sé si si lo has conocido esta herramienta esta base
Douglas (23:39)
Sí,
se usa para guardar métricas de servicios. Son series de tiempo porque entonces el CPU vos vas viendo cuánto estaba el CPU cada minuto. Cada minuto. Entonces luego esa base de datos te permite luego, después de que recopilaste la información de cada minuto, poder promediarlo a cinco minutos. O cómo estuvo su CPU la última hora. Entonces es una base de datos usada mucho para métricas de servidores, de clústeres y ese tipo de cosas.
Juan (23:49)
⁓ ok.
y luego lista por último a Postgres SQL para la información que resta entonces habla sobre que bueno ahora tenemos
Douglas (24:17)
Me gusta
cómo lo dice, para lo que sobra.
Juan (24:22)
sí, para todo lo que sobra de eso
y porque sí, es verdad, no? Dice felicidades ahora tenés siete bases de datos que manejar y ese que manejar la verdad es que sí golpea fuerte cuando lo lees de esa manera, no? son siete bases de datos entonces, ¿cuál es el punto del autor de este artículo? Dice simplemente utiliza Postgres
Y es que hoy en día Postgres tiene diferentes soluciones para cada una de estas En el artículo menciona casi, si no me equivoco, cada una de estos Para lo que son búsquedas de vectores Lo cual utilizaríamos Pine Cone Bueno, en Postgres existe una extensión que se llama PGVector y PGVector Scale Yo le he utilizado muy poco, bueno
me reservo los comentarios para lo que es influxdb tiene otra extensión llamada timescale db siempre en postgres redis bueno tendríamos tablas unlogged o sea que no se están guardando en lo que es el Write Ahead Log para lo que es mongo db pues simplemente utilizamos jsonb este es el tipo de dato para una columna en específico
y esto lo podemos utilizar en Postgres y Specialized Gs, este si no estoy muy al tanto a que se refiere al parecer hay otra extensión que lo hace y esto es muy interesante Douglas en este artículo él menciona que la extensión de PG Vector que es para los vectores, embeddings recordemos lo que se utiliza para los LLMs y búsquedas de vectores
utilizar esta extensión de Postgres tiene una mejoría de un 75 % menos costo comparado contra Pine Cone Pine Cone es una base de datos de vectores muy popular ya tiene bastantes añitos en la industria desde que se empezó a poner popular todas las soluciones RAG apareció Pine Cone
y bueno luego trata de mostrar las diferentes métricas con de postgres versus cada una de estas soluciones lo interesante para mí es el hecho de que ahora ya no tenés que mantener siete bases de datos tenés que mantener una esta una tal vez tiene trampa porque necesitamos como diferentes réplicas que están en diferentes servidores etcétera pero bueno es una base de datos que tiene su
una estrategia de backup, un solo monitoreo, los parches de seguridad van dirigidos a ella específicamente, etc. Entonces es interesante, yo tengo ciertas opiniones al respecto de utilizar solamente Postgres para todo. Creo que no vi por aquí en el artículo porque bueno, de nuevo para los que nos están escuchando nada más, no estoy leyendo tal cual el artículo.
pero no vi por aquí lo que creo que por aquí habla sobre Kafka. No sé muy bien cómo reemplazaría Postgres a Kafka. Asumo que con alguna extensión o con alguna funcionalidad que desconozco. Sin embargo, pues tiene sus limitantes, quiero creer. Así que bien, te lanzo la pregunta Douglas. Te animarías a reemplazar todo lo que es Redis?
MongoDB, base de datos de vectores y tener una sola solución con Postgres.
Douglas (28:24)
Buena pregunta, Yo creo que la respuesta corta en general es no. Ahora, quiero mencionar el artículo está súper interesante, o sea, extremadamente interesante para mí. Este es el tipo de cosas que si tuviera el tiempo, me encantaría dedicarle un fin de semana a hacer esta migración en un sistema o a hacer esta prueba en un sistema, ¿no? Eso es el tipo de experimentos.
Juan (28:46)
A comprobarlo.
Douglas (28:51)
que me gusta dedicarles tiempo que al final pues puede que me lleven a nada o a muy poco pero es el tipo de experimentos que me gusta ver, me gusta entender. Ahora, definitivamente ya para producción le encuentro ciertas cosas que me resultan alarmantes, no necesariamente que sea un problema real o no.
Pero hay varias cosas, entre ellas tener una sola base de datos no es tan bonito como se cree. Definitivamente el mantenimiento es más práctico, es más simple, pero ya hemos hablado antes Juan de que lo complejo...
también significa robustez, es complicado, es difícil, es triste, pero lo complejo también significa robustez, entonces hay que tener eso en consideración, eso por una parte. Segundo, que si se me cae esa base de datos, tenés razón, vos dijiste si tiene trampa, obviamente tenés réplicas, porque no vas a un solo servidor, ahí sí sería un problema, independientemente que, pero tenés réplicas, tenés diferencias.
probablemente en diferentes regiones, pero si se te cae esa base de datos, se cae por completo la aplicación, es un single point of failure.
porque todo depende del mismo clúster si lo queremos llamar de esa manera. Mientras que si se me cae Elasticsearch, por ejemplo, pues en la aplicación van a fallar las búsquedas, no es agradable, pero lo demás sigue funcionando, verdad. Entonces si se me cae Redis, se va a poner súper lenta, puede que llegue el punto de crashear.
porque está tan lenta al no tener redis, sin embargo, pues por lo menos se da tiempo para reaccionar porque se pone lenta. está esa parte donde no es del todo ya en la práctica, en arquitectura de aplicaciones vamos a evitar depender de una sola base de datos o de un solo cluster para muchas cosas. Entonces por esa parte yo le encuentro esa preocupación y lo otro vos lo mencionabas un poco Juan, que es el hecho de estos plugins
yo tengo poca o nada experiencia con ellos, quiero aclarar eso, tal vez alguien que nos ve y nos escucha o nos escucha tiene más experiencia y puede dar un veredicto con mayor conocimiento que lo que yo voy a decir ahorita, pero al ser plugins inmediatamente me lleva a pensar por mi experiencia con otro tipo de tecnologías de que no tiene toda la funcionalidad que necesitas
que te daría por ejemplo en lugar de todo lo que te da Elasticsearch no lo tendrías como un plugin en Redis, en Postgres perdón, verdad? Entonces si llegas a depender o a buscar o necesitar de cosas más complejas con Elasticsearch, ese plugin va a terminar siendo una...
obstáculo o un punto de stop para tu aplicación, lo mismo con cualquiera de los otros plugins, no pensaría que si solo ocupas lo básico para cada aplicación y para cada tecnología, perdón, esta forma de querer resolver el problema con una sola base de datos te va funcionar, pero si en ciertas áreas ocupas de funcionalidades avanzadas, de funcionalidades complejas, ahí te vas a topar con un problema muy probablemente porque el plugin se
va a haber limitado. para resumir, es súper interesante el artículo, definitivamente algo que me encantaría tener el tiempo de probar, pero para una aplicación a escala grande, por lo que yo tengo experiencia hoy en día, no me parece la solución más viable en realidad.
Juan (32:51)
Mil disculpas, como pueden notar hay un cambio en mi cámara, tuve un inconveniente, no la cargué lo suficiente, así que bueno, me disculpo, me pido disculpas. Continuando con el tema, el artículo, estoy totalmente de acuerdo con lo que hablabas Douglas, bueno, primero que nada introducir pues single point of failure como que...
me da ñañaras la verdad, pensar en tener solamente eso. Lo otro pues, el rendimiento que tan fuerte puede ser uno con la otra, puede ser algo, no lo sé, contraproducente la verdad. Yo lo que puedo compartir en cuanto a mi experiencia es que hay ciertas cosas que sí creo que son muy buenas en postgres.
La primera es el tema de tener datos como JSONB. El hecho de tener objetos, lo voy a llamar así, objetos o documentos mejor dicho, esta estructura no SQL, en una tabla de Postgres realmente funciona, Postgres es muy eficiente y te provee con muchas herramientas para poder hacer búsquedas bien complejas dentro del JSON.
Que tan intuitivo sea, bueno depende de cada quien, hay algunas que son medio raras donde tienes un arroba y menos que, mayor que Pero la verdad es que es muy bueno, ahora de eso de pasar de tener una columna, noSQL a reemplazar del todo a MongoDB Pues no lo se Realmente no estoy seguro si sea la mejor opción Puede que si, puede que no
Y en cuanto a una base de datos de vectores, yo tampoco estoy tan de acuerdo. Yo he probado algunas cosas del PG Vector, incluso he utilizado Redis como base de datos de vectores y en teoría no son malos, funcionan, pero ya cuando le empezás a escalar a niveles más grandes, estamos hablando que una base de vectores fácilmente puede llegar a tener
miles de millones de de vectores de puntos de vector y eso hace que sea muy muy pesada y pues realmente ya buscando benchmark y buscando información sobre postgres uno se da cuenta que no da la talla en este artículo el autor lo compara contra pinecone
Pinecone como decía ya tiene su tiempo en el mercado y es muy popular sin embargo hoy en día existen otras alternativas que son mejores. No, tampoco voy a hablar cosas que no sé, yo no he utilizado Pinecone en un ambiente profesional pero bueno basándome en los benchmarks y lo que han dicho otras personas y con las comparativas que veo realmente pues no es la mejor comparativa de o la mejor referencia para ver si Postgres
es bueno puede que sí funcione en el caso que si tengas una solución de vectores pero que no estés haciendo tantas búsquedas tantas inserciones constantemente pero pero bueno si realmente necesitas mucha mejor más velocidad y algo más escalable no no da la talla y bueno si es cierto se vuelven siete bases de datos siete sistemas pero pues
Es que así es el mundo corporativo, en una aplicación empresarial vamos a ver con múltiples piezas que se encuentran en el sistema entero. Tenemos Kafka, tenemos RabbitMQ, tenemos la base de datos, tenemos los logs, luego tenemos Grafana, Kibana y tenemos muchas cosas. Así que si bien es un, como decía, es un artículo muy interesante, por eso lo había seleccionado.
Yo en lo personal, ⁓ yo no aprobaría algo como esto. Utilizar solamente Postgres, ⁓ pues no lo aprobaría. verdad es que. No ahora lo que sí me llama la atención Douglas es. Esta conversación de qué tanto necesitarías necesitarías estas otras soluciones? Eso creo que sí puede ser interesante analizar.
más que todo cuando estamos iniciando una nueva, un nuevo producto, nueva herramienta, perdón, aplicación. Sí puede ser interesante hacernos la pregunta ¿realmente necesito agregar Elasticsearch? tal vez no, tal vez no es el momento porque también puede ser que desde el inicio queremos tener todas estas diferentes bases de datos y tal vez no sea necesario. De hecho he escuchado ya varias
Bueno no he escuchado, he leído en varias partes personas que reemplazan Redis con Postgres con las tablas no logueadas. No lo he probado, es interesante, hablan de muchas bondades en el aspecto de que ahora ya no tienes que hacer múltiples consultas, o sea te conectas a Redis y luego te conectas a Postgres, ahora solo también te conectas a Postgres.
es interesante, ahí no tengo una opinión tan fuerte porque ya he visto varias personas que lo están recomendando pero pues no sabría yo cuál podría ser el impacto negativo y bueno en el caso que sea como caché porque bueno el caché no importa si se cae si se cae pues la base de datos perdón, Postgres pues te interesa más el tema de la data no tanto el aspecto del caché puede ser
Douglas (38:46)
Pero
es que fíjate Juan que ahí mira y el tema se vuelve bien interesante, porque vos dijiste algo clave, necesitamos esas siete bases de datos, el artículo y lo entiendo y tiene un punto válido, el artículo te pone el escenario extremista de siete bases de datos contra una, vos dijiste es un sistema complejo, así es, ya lo hemos mencionado antes, un sistema complejo va traer más cosas y ya hemos dicho complejidad es igual a robustez, entonces hay que pagar el precio.
pero pero que tanto necesitamos va a ser en realidad para mí que yo voy a poner en práctica eso va a ser un escenario de 7 contra 1 va a ser un escenario de 4 contra 1 un escenario de 2 contra 1 en realidad miremos eso no verdad
Juan (39:31)
Correcto.
Douglas (39:32)
Y
tercero, lo que dijiste de Redis para Object Cache, tenés esa ventaja que es un solo protocolo para conectarte a Postgres tanto para bases de datos como para...
Objet Cache, verdad, para este tipo de caché. Sin embargo, y aquí voy a hablar desde que no he experimentado un setup como esto porque mi mente no tiene un sentido tan bueno para producción, la idea del caché, del Objet Cache, es evitar que la base de datos se sature.
Entonces, si siempre le voy a dar la memoria a la base de datos, claro, va a estar ya en memoria RAM y va a ser más rápido para devolver. Pero, ¿cuánta memoria RAM necesito para que tenga la información cachada y para que también esté procesando queries para información nueva? Entonces, ¿cómo pierde el propósito? ¿Le puede limitar la memoria que le puede asignar? Me imagino porque no lo he utilizado, pero como que no sé. ¿El propósito dónde está?
Juan (40:14)
Cierto.
Douglas (40:41)
ese sentido, ¿verdad?
Juan (40:43)
tal vez si tenés un cluster de bases de datos tal vez podrías tener alguna especie de routing que redirija ciertas instancias para hacer el cache podría ser y al menos al nivel de código ya solamente tenés una conexión no lo sé es interesante la manera en cómo lo aborda aquí en el artículo
Douglas (41:06)
entiendo ese punto de que puede ser un cluster de hecho
nosotros hay ciertos clientes que no ocupan Ready, sino que usan Memcache, que es bien sencillo y tenemos un cluster de galera y Memcache está corriendo en el mismo servidor donde está corriendo MariaDB, por ejemplo, en cada uno del cluster, ¿verdad? Pero al ser un servicio totalmente diferente, distinto, le asignamos 500 megabytes o un giga al servicio de Memcache y no va a pasar de ahí, ¿verdad? Y si se carga el servicio y tiene que crashear, pues crashea
cache y tener la base de datos activa, entonces hay escenario donde encaja ese concepto, pero de nuevo ya una aplicación más grande, más robusta, ⁓ si tengo Postgres en lugar de usar Memcache y mi aplicación es pequeña, usaría esta extensión, si, ahí encaja, no tengo dos cosas con el mismo servidor, pero si quiero segmentar, si ocupo una aplicación grande que segmenta el tráfico, que no tenga
single point of failure no lo veo de nuevo no es crítica
pero me encanta el artículo, me encantaría poder ponerlo prueba pero no porque me parezca algo listo para producción estos plugins en mi opinión Juan, vos mencionaste es el de JSON entonces si vas a manejar algunos campos en JSON no ocupas MongoDB ¿para qué vas a instalar todo un cluster de MongoDB o una base de datos ya tenés Postgres? Hacelo ahí, es eficiente vos lo has probado pero estoy seguro que si empieza a escalar
algo más grande, aunque sea eficiente en Redis y ocupas otro tipo de funcionalidades, probablemente va a llegar un punto donde te toque migrar esas funcionalidades a MongoDB. Entonces, ahí para mí siempre ha sido el propósito de estos plugins, más allá de intentar forzar una herramienta en la dirección en la que no fue pensada.
Juan (43:05)
Bueno, solo como aclaración, si alguien le interesa probarlo, lo de Jason en Postgres no es plugin, esto si viene nativo built-in en el motor. Tal vez por eso es bastante eficiente. Sí, sí, tal vez. Pero aún así, yo siempre creo que...
Douglas (43:23)
Tiene sentido,
Juan (43:32)
si tenemos una aplicación que ya sabemos que va ser bastante grande y con mucho tráfico yo creo que es mejor tener algo especializado porque bueno si yo tengo una base de datos de vectores y es de postgres pues igual tengo el resto de postgres ahí no pues no está haciendo nada entonces bueno no sé es complicado bueno siguiente artículo vamos al último del día de hoy y lo tengo por aquí
Douglas (43:47)
Sí, sí.
Juan (44:04)
el título de este artículo para los que solamente nos están escuchando dice por qué las aplicaciones local first no se han convertido en algo popular local first se refiere a estas aplicaciones que trabajan o todas las transacciones que ocurren en ellas primero o la prioridad es guardarlas en el dispositivo donde están y eventualmente se van a sincronizar
a una base de datos remota. ejemplo, imaginemos como en el navegador tengo una aplicación, se me viene a la mente Notion, no sé si Notion trabaja así, creo que no. Pero una aplicación estilo Notion donde yo puedo estar trabajando en las notas y pues no importa si estoy conectado o no. Yo estoy trabajando en la aplicación y en algún momento cuando tenga internet
se va a sincronizar y se va guardar. Eso es una aplicación Local First a grandes rasgos porque tiene ciertas cosas, pero el artículo hace la pregunta ¿por qué no son populares? Y el motivo del por qué lo pregunta es porque no sé si aquí tengo un sesgo de confirmación Douglas, pero me da la impresión que últimamente se está popularizando más este término de Local First.
He visto ya varios artículos o varias posts de personas que hablan sobre promover más que las aplicaciones sean Local First por diferentes motivos. Hay motivos que tienen que ver con el rendimiento, hay motivos que tienen que ver con el hecho de que tu información te pertenezca. Algo que se me viene a la mente con este caso es una aplicación que utilizo mucho.
también de notas es obsidian en donde obsidian trabaja en un archivo local y luego eventualmente vos decidís si se sincroniza o no con otros servicios externos entonces ahí la idea es que tu data es totalmente tuya no no es necesario que esté en otro servidor así que bueno el artículo habla sobre eso se hace la pregunta por qué no se han convertido en algo más mainstream y ⁓
de entrada nos da una respuesta bastante simple y es que dice que sincronizar es difícil. Sincronizar una base de datos es complicado. Sin embargo aquí, bueno más adelante vamos a ir viendo, yo ya le di una leidita al artículo. Habla de diferentes desafíos al momento de hacer una aplicación de este tipo Douglas. Uno de ellos es el ordenamiento.
que no es... Siempre olvido la traducción de reliable. Bueno, no es creíble, no es...
Douglas (47:05)
estable, es
robusto, que puede depender de él.
Juan (47:09)
Robusto, vamos a llamarlo Robusto.
No es Robusto el ordenamiento y también esto conlleva a que hayan conflictos. Esos dos son los que él menciona los mayores desafíos al momento de crear una aplicación como esta. Y es que vamos a hablar de si tenemos dos dispositivos. Yo me conecto en mi celular a la aplicación, pero al mismo tiempo me conecto a la computadora.
y en ambos yo hago una operación entonces ¿cuál va primero? refiriéndonos al momento en que se sincroniza la data con la base de datos principal que está en un servidor externo allí es donde entra el mayor desafío de esto él propone una solución y esta solución la verdad es que entiendo el contexto pero nunca había leído el nombre
el nombre del concepto HLC Hybrid Logical Clocks relojes lógicos híbridos básicamente es el hecho de comparar un timestamp o sea el momento exacto en que se hizo una operación versus el momento exacto en el que se hizo otra operación
Aquí estoy buscando un ejemplo que él da sobre este punto en específico y me gustaría leerlo porque creo que nos ayuda para visualizar un poco lo que sucede y lo que él quiere tratar, quiere ejemplificar. Menciona, en la máquina A un evento se registra a las 10 horas exactas con 100 milisegundos. Esto se guarda.
con el evento esa hora exacta y le agrega un índice del orden el índice 0 este es el contador luego en la máquina B se registra otro evento pero esta vez se registró a las 10 horas con 95 milisegundos un poco atrás de la que se hizo allá la primera fue en 100 esta fue en el 95 entonces a esto la máquina
recibe ambos eventos o mejor dicho el servidor recibe ambos eventos y revisa que pues no coinciden que la que está recibiendo o la que está haciendo es antes así que mueve su reloj interno y ahora le agrega o cambia la fecha mejor dicho y en vez de poner las 10 horas con 95 milisegundos le pone las 10 horas con 100 milisegundos pero ahora le pone el orden 1
sucedido después. Entonces de esa manera se reacomoda para que vaya en el orden correcto. Así que tenemos dos eventos que sucedieron a la misma hora, a las 10 y aquí le pone que es con los 100 milisegundos exactos, tienen un orden diferente. Muy complejo la verdad, espero que los que sólo nos están escuchando me hayan entendido, pero realmente funciona porque de esa manera ahora tenemos
ambos eventos en un orden correcto, que eso lo que queremos. Aquí el problema es el orden de cuando se sucedieron los eventos. segundo desafío son los conflictos, porque aún con esto él menciona que pueden suceder conflictos. Siguiente ejemplo, voy a leerlo porque creo que es importante para tener una idea de cómo funciona. Recordemos
estamos en una aplicación que se puede ejecutar de manera offline en diferentes dispositivos así que en el dispositivo A yo tenía el balance o el saldo inicial de 100 y le agrego 20 ahora tengo un saldo 120 en el dispositivo B yo tengo un saldo de 100 pero ahora le resto 20 así que en el dispositivo B yo tengo un saldo de 80 entonces aquí surge la pregunta ¿cómo?
hacemos esto cuál sucedió primero si bien el orden funciona a lo que él se refiere es que en este tipo de casos cuando hay un conflicto lo que se debe hacer es que el último valor en el orden de los eventos ese es el que tiene que ganar así que el último que sucedió ese es el que se toma como verdadero aquí debo recargar que me parece muy riesgoso al menos
desde la poca experiencia de trabajar con este tipo de sistemas parece un poco riesgoso pero bueno esta es la solución que él da con este tipo de lo que él habla es la solución se llama CRDT conflict free replicated data types tipos de datos replicados libres de conflicto eso es lo que lo que dice y bueno entonces él menciona que
hay que revisar básicamente el timestamp, la hora en sucedió y si vemos que el saldo de 120 sucedió a las 10 horas exactas pero luego el saldo de que decía 80 sucedió a las 10 horas con 2 segundos entonces el saldo que para nosotros es el correcto es el último, 80 y de esa manera entonces ahora al momento de sincronizar ambos dispositivos con la base de datos principal vamos a tener el saldo correcto
tal vez no era lo que el usuario esperaba pero así es como sucedió y así es como nosotros lo registramos complejo, al final el artículo menciona que la mejor solución es utilizar SQLite puede ser, la verdad es que SQLite tiene diferentes herramientas que nos ayudan a sincronizar los datos y pues SQLite tiene lo que es el write ahead log así que hay un log de en que momento sucedió cada cosa puedes funcionar
aún así tiene sus complicaciones y no es como que tan fácil como bueno ahora voy a utilizar SQLite y simple no así que es una gran solución pero pues habría que revisar de casos a casos y qué pasa no si estamos en el navegador pues ahí pues lo que tenemos es el local storage o el index db bueno ahí depende pero bueno me gusta este artículo Douglas no lo leía
a cabalidad, vamos a dar los enlaces para que la gente lo pueda leer si gusta, pero yo con lo que me quedo en este caso Douglas y luego te voy a hacer un dar pregunta vos, es el hecho de bueno, si tanta gente habla de local first, aplicaciones que sean primeramente local, ¿por qué entonces nadie más las está utilizando? Esa es la gran pregunta del artículo y bueno ya vemos que es bastante complejo.
hacer estas soluciones Douglas, entonces te pregunto ¿alguna vez has trabajado con una... tal vez en la empresa donde has estado, tienen algunas aplicaciones como este que tienen esta funcionalidad o este comportamiento o qué opinas de aplicaciones que sean Local First no sé si has utilizado aplicaciones que sean de este estilo
Douglas (54:48)
Mira, en cuestión de tener que administrar, si se quiere llamar, porque pues obviamente yo no desarrollo, yo estoy en la parte de infraestructura, administrar aplicaciones que sean local first nunca me ha tocado, ¿verdad? Entonces, por esa parte, comienzo siendo honesto ahí, entonces no tengo experiencia en cuestión del manejo de la infraestructura y los diferentes retos que representan. Ahora, como usuario, he usado este tipo de aplicaciones,
Y te voy a decir lo que pienso, usando como ejemplo, unos comentarios que le escuché a Neil Tyson. Neil Tyson, no sé si lo has escuchado de él, es nuestro físico famoso, ¿verdad? que él, él, correcto, Él hace, para dos preguntas diferentes, él hace una ejemplificación que a mí me gusta. Le preguntaron una vez, qué tan difícil sería
Juan (55:34)
sí, Neil deGreece Tyson.
Douglas (55:48)
desalinizar el agua del bar y él dice no ya se puede hacer pero ¿y por qué no se hace? porque cuesta mucho dinero
Pero ¿y por qué? No, mira, mientras no haya billete por medio y no hace pelea por el agua hacia un recurso, no va a pasar porque es muy caro. Y en otra ocasión le preguntaron, le preguntó a alguien que lo estaba entrevistando, ¿qué posibilidades tengo que en mi vida alcance a ver que el hombre vaya a Marte? Y él dijo ninguna, cero posibilidad. Y él se impresionaba, él dijo, no, mira ve.
no hay billete por medio. Fuimos a la Luna porque había un conflicto político con Rusia y Selva y entonces era una cuestión de poder y política y posible guerra y se fue a la Luna con poquita tecnología. Se llegó a la Luna, se vio que no había peligros ni cosas, entonces se acabó esa necesidad y ya no está ese envío. Son empresas privadas las que están queriendo invertir en eso de ir a Marte. Entonces, ¿por qué traigo este ejemplo? Lo voy a tratar en a Local First.
tener que estar invirtiendo esta cantidad de recursos en tratar de solventar los retos que acabamos de leer y otros para soluciones que no todo el mundo utiliza. La forma en yo miro estas aplicaciones de Local First One, si las quiero ver por motivos de seguridad, las tengo en mi dispositivo local, pero en el momento
En el punto del día del mes del año que yo ocupo sincronizar en otro lugar, en ese momento toda mi información se fue a la nube.
Entonces si va ir una vez a la nube, que esté todo el tiempo en la nube. ¿Para qué voy a estarme complicando con que se bajó, que hubo un conflicto que no se bajó, que a nivel de usuario estoy esperando a que refresque y haga sincronización lo que hice en mi laptop que sincronice lo que está en el celular? Porque te toca esperar, ¿no? Te queda un ratito ahí tres, cinco segundos y pues como usuarios nos volvemos desesperados hoy en día. Entonces a ese punto ya se perdió el motivo de seguridad.
Juan (57:33)
que lo haga de entrada.
Douglas (57:56)
verdad? porque local first es que este es el primero local pero eventualmente va a ir a la nube entonces
si voy a guardar en la nube y parece ser el sentimiento de todos los usuarios de un solo agarramos servicio de nube para que vaya a no ser de que me genere un beneficio local como por ejemplo podemos ver el nuevo office, vos tenes excel local y puedes hacer todo lo que excel te ofrece y una vez que guardas el archivo se sincroniza tu drive y se puede abrir directamente de la nube también si queres y entonces puede ser algo que le llamas local first pero cuando lo trabajas local
tiene el beneficio agregado de la aplicación como tal nativa que tiene más opciones. ahí es algo diferente, pero de manera general en lo que tiene que ver con seguridad compartir, como que los usuarios si va a estar en la nube, que esté en la nube. Y entonces no usan ese tipo de aplicaciones. Entonces las aplicaciones tienen poco auge y son complicadas de desarrollar y mantener.
Entonces, como que no hay que motive a que las aplicaciones Local First se le siga invirtiendo de más y tengan el auge que tal vez esperaba al principio, porque se quería vender la idea de un punto intermedio entre seguridad, entre ser dueño de lo mío, pero a la vez sincronizar entre dispositivos. Pero bueno, entonces sincronizo es porque está en la nube. Entonces, por ahí va mi opinión al respecto.
Juan (59:23)
Si, como que no tiene el valor agregado que uno esperaría. Yo opino muy similar a lo que acabas de mencionar. Personalmente, si le doy como... ¿Cómo decirlo? Como que me agrada mucho cuando una aplicación tiene estas funcionalidades. Por ejemplo, yo utilizo KeyPass para mi gestor de contraseñas. Y KeyPass de la manera en que funciona es que pues tiene un archivito...
y bueno, ya cada quien se las apaña para ver cómo va a hacer un backup de ese archivo y cómo lo va a sincronizar con otros dispositivos. Es así como funciona y en lo personal me gusta, ¿no?
Douglas (1:00:04)
Pero ahí perdón,
pero ahí no es local first, ahí es una aplicación local. Y vos te encargas de sincronizarla a tu manera. Y te arriesgás a que perdés si... Pero es una aplicación local, no local first.
Juan (1:00:09)
buen punto, es... sí, es correcto
Exacto, exacto. eso menciono que cuando tienen esta funcionalidad o ¿cómo decirlo? Creo que el mejor ejemplo sería Obsidian, que te permite sincronizar tus archivos pero pues están en tu directorio. Es interesante, te da la opción de que bueno, tenés la potestad pero también como decías, al final si se va a ir a un servidor externo pues ¿cuál es la diferencia? Yo lo que recuerdo a nivel empresarial
es en una empresa en la que yo trabajaba que distribuía el agua potable de la ciudad. Las personas que se encargaban de ir a campo tenían que ir a hacer lecturas de las casas y llevábamos un dispositivo que no tenía conexión a Entonces ahí sí, ellos hacían todas las mediciones, la utilizaban en el dispositivo y en el momento en que entrara a...
Cuando digo que no tenía conexión a internet me refiero a señal de celular, algo como ese tipo, pero cuando se conectaban a wifi, todo se empezaba a sincronizar con los servidores. Era un caso muy específico y recuerdo que yo cuando entré, a mí no me tocó trabajar con eso, lo hacían otros compañeros y sí recuerdo que era complicado. Así que bueno, al final...
porque no son populares y mucha gente trata de evangelizarlo y todo eso creo que el artículo lo deja muy bien claro desde el inicio si la sincronización es muy difícil tan difícil que no vale la pena invertir tanto tiempo en ella creo que ahí lo podríamos resumir
Douglas (1:02:01)
Sí, y sobre todo para la ganancia que genera, porque si generara suficiente ganancia, obviamente la invertiría en este escenario que vos dices de cuando llegan a los mediadores de agua con un aparato que no está conectado al internet, cuando llegan a la oficina se conectan, no hay en realidad en esos escenarios esa muy poco actividad compitiendo por el mismo registro, ¿verdad? Porque la información de hecho de cada casa
Juan (1:02:07)
Correcto.
Douglas (1:02:31)
y el consumo de agua se actualiza cada vez que llega este. No hay como que mucha competencia en ese sentido y en ese escenario.
es necesario y válido, como las impresoras matriciales, esas que tienen cinta y se saca de gran bulla y pues por muchos años y aún en la actualidad se siguen usando porque ocupas copias de las facturas y esa es la única tecnología que permite que con papel carbón haga copia, diferentes copias, verdad? Y aún hoy en día pues ya las las entes gubernamentales han empezado a aceptar
Juan (1:02:44)
Ok. ¿Sí?
Douglas (1:03:07)
varias impresiones como copias de una misma, pero me explico, son tecnologías de que tienen su uso y por eso prevalecen, pero SYNC is hard dice, y no le va a generar mucho, entonces va perdiendo el auge. Todo de billetes.
Juan (1:03:21)
Incluso con este ejemplo
que di, perdón Douglas, con este ejemplo que di, cuando yo salí de esa empresa ya se estaba empezando a migrar para que tuvieran dispositivos que si estuvieran conectados. Entonces, de todas maneras. Bien Douglas, hemos llegado al final del episodio. Espero que los que hayan escuchado el episodio entero me gustaría que dejaran algún comentario para ver si les pareció interesante.
Douglas (1:03:34)
Sí? Sí, sí.
Juan (1:03:52)
Nosotros queremos seguir haciendo experimentos como este y seguir hablando porque hay muchas... bueno como lo dijo Douglas a ambos nos gusta estar viendo pues las noticias y qué es lo que sucede en la industria del día de cada día ¿no? Así que bien, por ahora eso es todo espero que les haya sido de utilidad y les haya gustado el episodio. Así que bien.
Sin más que agregar, nos vemos el episodio, el próximo episodio de la siguiente semana. Hasta luego.