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:00)
En ese aspecto Douglas creo que definitivamente es una opción muy atractiva el hecho de ya no tener que preocuparme por todas estas cosas que
aún si lo sé hacer, pues ya me quito ese trabajo de encima. lo veo, digamos, positivo. No sé qué opinas vos.
Douglas (00:14)
suena atractivo Juan, suena atractivo es como cuando te llaman esas personas y dicen que ganaste un premio y vos pensas es demasiado bueno para ser cierto, probablemente no es cierto.
Juan (00:29)
Bienvenidos sean todos a un
más de nuestro podcast Dev&Ops. El día de hoy vamos a estar hablando de unos temas, un tema muy interesante que creo que va ser muy importante para algunas personas y va a ser muy provechoso para otras. Para eso tengo aquí a mi buen amigo Douglas, nuestro amigo que siempre nos aporta un punto de vista diferente para los que no somos tan
en la parte de servidores y operaciones. Aquí tengo a mi buen amigo Douglas. Douglas, ¿qué tal? ¿Cómo has estado?
Douglas (01:07)
Juan, ¿qué tal? No muy bien, gracias a Dios. El día de hoy desde un lugar no habitual para mí, con un setup un poco diferente, pero estamos bien. La verdad es que las ganas y la intención de tener esta conversación y poder aportar valor a las personas que nos ven y nos escuchan, eso no cambia. Yo creo que eso es lo importante.
Juan (01:29)
Excelente, excelente, Me gusta tu nuevo setup, aunque sé que es temporal. Pero bueno, vamos a estar hablando el día de hoy sobre serverless. Este es un topic que...
Douglas (01:36)
si es temporal.
Juan (01:47)
se popularizó a mediados del 2014-2015 con AWS y desde entonces la verdad es que siempre es un tema que vale la pena investigarlo, incluso probarlo, ¿por qué no? Y por eso queremos darles nuestros puntos de vista con las diferentes experiencias que hemos tenido. Cabe recalcar que no...
somos tan expertos en el tema, sin embargo, sí hemos tenido un acercamiento con este tipo de infraestructura y diseño de aplicaciones. Así que, bueno, vamos a tratar de darles algunos consejos y nuestros puntos de vista sobre lo que representa una aplicación de este tipo. Creo que...
Douglas (02:34)
Juan, tal vez
para aclarar, que tal vez poca experiencia como tal puesto en práctica, una razón importante de ello es que para muchas soluciones se ha evaluado fuertemente y al final se ha decidido utilizar soluciones distintas, ¿verdad? Entonces, tal vez aclarar a las personas que nos ven y nos escuchan de que...
de que si bien es cierto no hay una experiencia profunda de años implementándolo, ¿verdad? Hands-on experience, como se dice, no significa porque estamos alejados del tema. Por el contrario, en la mayoría de los casos hemos optado por implementar soluciones diferentes y eso es que ha causado eso, ¿verdad? Pero yo creo que vale la pena aclarar lo que vos mencionás para que las personas que nos ven y nos escuchan sepa desde qué perspectiva hablamos.
Pero definitivamente es un tema que sí hemos evaluado bastante.
Juan (03:32)
Sí, sí, tenés toda la razón, vale la pena mencionarlo. Y creo que vale la pena siempre que escuchamos opiniones en internet saber de dónde vienen, la persona qué experiencia ha tenido, cuáles son sus inclinaciones sobre ciertas tecnologías. Así que, para los que ya nos han seguido en episodios anteriores, creo que ya tienen una idea formada de cómo nosotros solemos abordar este tipo de tecnologías y el desarrollo en general. Para los que estén llegando a este episodio,
por primera vez. Yo soy un desarrollador principalmente de backend y Douglas es un SRE, un DevOps Engineer que tiene una alta experiencia en lo que es el manejo y el diseño de infraestructuras en servicios y sistemas muy grandes. que por ese motivo creo que también nuestra experiencia con soluciones serverless ha sido limitada porque muchas veces
estas compañías en las que hemos trabajado se orientan más por otro tipo de soluciones como ya lo mencionaba Douglas pero pero bueno Douglas eso me da pie para empezar a hablar sobre el tema me gustaría empezar con número uno vamos a definir qué es lo que nosotros entendemos por serverless y qué es lo cual ha sido nuestra experiencia con esto y también me gustaría empezar por diciendo que no es ni la solución
no es la bala de plata que vamos a por ahí pero tampoco es una mala solución vamos a ir viendo sobre eso primero que nada es excelente es una solución siempre hay algo ninguna solución va a ser perfecta siempre es así bien Dulas vamos a empezar entonces por qué es serverless y
Douglas (05:11)
es una solución.
Juan (05:28)
Contrariamente o irónicamente no significa que no hayan servidores. Sí existen servidores. Sin embargo, es un servicio backend del cual nosotros no nos vamos a preocupar por la escalabilidad o el tiempo de respuesta o dónde vamos a hacer el deployment de esta máquina que va a estar corriendo en el backend. Así que, principalmente es eso.
Hay de dos tipos de soluciones serverless. Al menos yo así lo veo. Está la solución donde tenemos toda la plataforma a nuestra disposición y consumimos un servicio. En este caso me estoy refiriendo a soluciones como Firebase, SuperBase y muchas otras bases que hay por ahí. Pero yo personalmente recomendaría esas dos. Me parece que son muy completas, dan todas las soluciones que necesitan.
y luego están las otras que también se ejecutan sin que nosotros estemos tan pendientes del servicio de backend, sin embargo creo que requieren un poquito más de planeación y un poquito más de entendimiento de cómo funciona la infraestructura y me estoy refiriendo a soluciones como AWS, Lambda y...
el equivalente en Google se llama Cloud Functions creo, ok lo siento lo olvide pero Google también tiene su solución también Azure tiene una solución muy similar son como las lambdas de, perdón, las lambdas de Google, las lambdas de Azure así que
principalmente Douglas, yo lo separo en esas dos categorías porque unas, ambas son fáciles de iniciar pero creo que hay unas que son mucho más fáciles como en este caso Firebase y las otras pues requieren ciertos ajustes y también la manera en que abordamos el desarrollo del código que se va a ejecutar también cambia.
Yo personalmente Douglas, he tenido más experiencia y he hecho más proyectos con estas dos que menciono, Firebase y SuperBase. En tu caso creo que me comentabas que has tenido cierta manejando algunas aplicaciones en Lambda.
Douglas (07:53)
Sí, sí, en mi caso sería mayormente experiencia, obviamente no como alguien que las ha desarrollado, sin embargo, administrando la parte del deployment y la parte de la conectividad hacia estas diferentes funciones, mayormente con Lambda. Y fíjate, Juan, que también he trabajado con los servicios de Cloudflare. Cloudflare tiene una muy buena plataforma para serverless con sus workers y tiene funciones.
Juan (08:00)
mmm
Ok
Douglas (08:23)
Y aparte Cloudflare tiene todo un set de soluciones y herramientas casi que listo para trabajar con serverless, incluyendo storage tipo S3, que se llama R2 dentro de Cloudflare. Tiene diferentes servicios de base de datos, tiene de base de datos SQL, key value, databases. Y tiene, obviamente, los servicios de Cloudflare que actúan como CDN o como API Gateway.
en frente de los servicios. Entonces también he tenido experiencia trabajando con las diferentes serverless de Cloudflare, pero en general mayormente AWS y Cloudflare en ese sentido.
Juan (09:07)
Excelente. Y...
Bueno, lo que me llama la atención es cómo estas diferentes soluciones tienen servicios muy similares entre sí. Y eso tiene sentido porque el pionero en esto fue AWS con sus Lambdas. Ellos fueron los que empezaron y luego se fue popularizando y muchas otras plataformas empezaron a sacar sus propias versiones. Pero en este caso lo que es
Firebase tiene un código que se ejecuta similar a los lambdas y SuperBase también. Así que en este caso, ya que mencionabas las bondades que trae, lo que es Cloudflare, creo que vamos a pasar entonces, me gustaría hablar de qué conlleva estas soluciones serverless,
lo que es Firebase, SuperBase y también todas estas soluciones como AWS, lo que nos ofrecen es un código que se va a ejecutar en nuestro backend, ya sea un código que reacciona a un evento o que reacciona a un webhook y se ejecuta solo. También tenemos lo que es el sistema de autenticación y autorización.
proveen muchas veces, como ya lo mencionabas, este storage de objetos también nos permite guardar archivos de manera muy fácil, muy sencilla. que todas estas soluciones, lo que nos dan es todo lo que tiene que ver con el backend o los servicios a los que se va a conectar nuestro frontend. Y ojo, frontend aquí no solamente es la página web, también puede ser una aplicación móvil.
Entonces todo lo que se va a hacer en nuestro front-end y se va a conectar a los servicios, todo eso ya nos lo proveen. Incluso con las bases de datos, en el caso de Firebase, tienen una base de datos que es no relacional. En el caso de SuperBase, utilizan Postgres, pero ellos tienen una capa de abstracción que nos permite utilizarla de manera más fácil. Y en el caso de AWS, también nos permite utilizar nuestra base de datos, bueno, de las bases de datos que ellos ya proveen que también
escalan solas, se actualizan solas si no me equivoco, bueno se puede configurar y nos dan ya todo listo para que nosotros nos preocupemos en teoría sólo por la lógica de nuestra aplicación, de nuestro negocio.
Douglas (11:38)
Mm-hm.
Juan (11:52)
En ese aspecto Douglas creo que definitivamente es una opción muy atractiva el hecho de ya no tener que preocuparme por todas estas cosas que
aún si lo sé hacer, pues ya me quito ese trabajo de encima. Yo lo veo, digamos, positivo. No sé qué opinas vos.
Douglas (12:12)
Si
suena atractivo Juan, suena atractivo es como cuando te llaman esas personas y dicen que ganaste un premio y vos pensas es demasiado bueno para ser cierto, probablemente no es cierto. Mira entiendo, si es atractivo definitivamente y yo creo que la parte que yo quisiera resaltar aquí Juan es definitivamente todo tiene un
costo.
Todo tiene un costo y esa es la parte que tenemos que entender. Esto es una tendencia que viene desde hace muchos años y se hizo popular entre desarrolladores, entre developers. Y ese fue el objetivo desde que AWS lanzó Lambda. Era para facilitar deployments a programadores para que ellos pudieran enfocarse únicamente en su código y facilitar el despliegue de
Juan (12:40)
Sí, sí.
Sí, sí, sí.
Douglas (13:09)
de funciones, así inicialmente eran funciones. Pero atrás de esto, definitivamente hay un costo, siempre se sacrifica algo. Realmente, al día de hoy, aún con Inteligencia Artificial, no puedes reemplazar 100 % un equipo completo de desarrollo que incluya backend, frontend, especialistas en bases de datos, especialistas en los diferentes tiers.
especialistas en seguridad porque algún layer, alguna capa va a terminar mostrando algún problema en algún punto o varios problemas, verdad? Entonces lo mismo ocurre con serverless. Definitivamente es muy atractivo. El target, la audiencia es para programadores que no tengan que preocuparse por la configuración del lado del servidor y es ahí el nombre serverless.
Juan (14:04)
No,
Douglas (14:06)
es despreocuparme por la configuración del servidor. Obviamente sabemos que de la misma manera que la nube realmente no son nubes en el cielo, es una terminología, sabemos que serverless no es que que corre en el aire, es una terminología, Entonces definitivamente es muy atractivo para programadores, Juan, que no tienen que preocuparse por configurar estos servicios porque
Juan (14:23)
claro
Douglas (14:32)
antes de esto y si vos buscas un tutorial y quieres hacer una aplicación en PHP digamos, tenes que investigar como instalar MySQL o el servicio Postgres si vas a usar Postgres y configurarlo tenes que instalar PHP la version que necesitas, instalar el NGINX encima y hacer la configuración y luego hacer el despliegue y tenes que empezar a mantener eso y si tu sitio se pone lento tenes que empezar a debuggear
estos servicios e intentar solucionar tu problema. Entonces definitivamente serverless se vuelve atractivo para programadores que no tienen que preocuparse por ello y hasta en estas plataformas que nos estás contando vos que ya tienen los servicios listos solo para consumirlos. Y ese es esa es la gran ganancia. Son servicios donde sólo los vamos a consumir y vamos a desplegar nuestra aplicación. Entonces
Juan (15:20)
No,
Douglas (15:30)
Quiero que a medida avancemos con la conversación, mantengamos en mente esa audiencia. Es serverless, está orientado a programadores solos o a equipos de solo programadores. Mantengamos eso en mente a medida avanzamos con la conversación. Eso no es algo malo necesariamente, Solamente es importante tener la audiencia clara y eso nos va a ayudar a entender a medida progrecemos con la conversación qué tipo de aplicaciones
o qué tipo de soluciones son realmente buenos candidatos para arquitectar en serverless.
Juan (16:08)
Correcto. Sí, definitivamente hay...
puntos negativos y los vamos a mencionar definitivamente pero también me gustaría resaltar estos puntos que son como mencionaba atractivos y realmente son algo bueno dependiendo de la aplicación que estamos haciendo algo que puedo recomendar yo es que destinemos un tiempo prudente para planificar cómo vamos a hacer una aplicación vamos suponiendo no que
estamos
empezando desde cero. Si estamos empezando desde cero, planificar bien cada una de estas cosas que conllevan al momento de hacer un sistema. El lenguaje que vamos a utilizar, tanto en frontend como backend, porque bueno, una aplicación móvil la podemos hacer en múltiples, en diferentes lenguajes. Hay muchas opciones hoy en día. Lo mismo en frontend es JavaScript, hay muchas opciones de frameworks y también cómo vamos a solucionar la parte del backend.
es necesario tener en cuenta esto dependiendo de nuestra aplicación. Si tenemos una aplicación que de entrada sabemos que va a tener muchos usuarios
y más si son usuarios que van a estar repartidos en diferentes partes del mundo. Bueno, eso requiere una solución que vaya acorde a esas necesidades, Que ahí la parte serverless también nos da esa ventaja porque ya de entrada tenemos, bueno, hoy en día se le llama edge computing donde tenemos... Estas soluciones nos proveen servidores que van a estar más cerca del usuario o en teoría, ¿no?
y de una manera muy fácil, más fácil que si le tuviéramos que hacer todo configurado con la máquina virtual en una región de AWS y nosotros vamos controlando este tipo de cosas como ya mencionaba Douglas con NGINX y todas estas otras opciones.
pero igual Douglas, me gustaría también resaltar estos puntos que creo que son positivos y pueden ser muy atractivos más cuando venimos empezando. De hecho te menciono que mi primer acercamiento con Firebase y toda esta mentalidad de aplicaciones serverless fue al momento de realizar un proyecto para la universidad, un proyecto que lo hicimos con un pequeño grupo de
de
compañeros pero la mayoría de mis compañeros no tenía experiencia desarrollando aplicaciones. Y mi experiencia era también muy limitada. Yo lo único que conocí era JavaScript, PHP y .NET.
y para el tipo de aplicación que queríamos realizar, el cual era como una red social de... Bueno, de hecho siempre me ha parecido una aplicación que debía haber lanzado realmente, era una red social sobre tiendas de café, coffee shops. Hay muchas personas que les gusta el café y el concepto era muy interesante en su momento.
Pero bien, este caso Douglas nos permitió, o bueno, me permitió ya que yo era el que llevé el proyecto en la parte de programación, infraestructura, mis compañeros se encargaron de todo lo demás,
fue muy beneficioso para mi el hecho de enfocarme en una sola cosa, aprender el framework que estaba utilizando de JavaScript y el código que realmente era muy poco, el código que se ejecutaba en el backend que como mencionaba son funciones declaradas dentro de esa plataforma, el código también lo podía hacer con JavaScript, así que era muy fácil transicionar de un lado al otro.
manera en que accedía hacia la base de datos de Firebase tanto de la función Lambda como en el front-end era prácticamente la misma así que todas estas cosas hicieron que el desarrollo fuera muy muy rápido estamos de acuerdo que un proyecto de tarea realmente no te dan tanto tiempo para desenvolver
o 2 meses por mucho y cuando venimos empezando pues eso es poco tiempo así que definitivamente fue algo muy positivo y yo creo que hay muchas personas que también les sacan un buen jugo cuando son... se me va la palabra freelancers así que en ese aspecto creo que estos servicios serverless brillan bastante para
Douglas (20:46)
Sí.
Juan (21:08)
para estos casos donde nuestro set de habilidades son limitadas, es la verdad. Yo pude desplegar una aplicación en producción con SSL, con todas estas caching que nos dan una base de datos pues ahí, en regulera, y sin tener un conocimiento real de lo que estaba pasando por detrás. Tenía un conocimiento bien abstraído,
Douglas (21:35)
Uh-huh.
Juan (21:38)
bien abstracto y me permitió enfocarme en la parte del frontend que esa la que sí manejaba y la que pude pulir así que definitivamente eso para mí es algo muy bueno hay que tener cuidado con algunas cosas que ya vamos a ir mencionando pero sí creo que es algo bueno Douglas por ejemplo en tu caso como decías no no soles codificar esta parte de la aplicación pero suponiendo que por algún motivo tuvieses que hacer algo una aplicación
tal vez en apariencia simple, seguro que esto sería una solución que permite avanzar muy rápido en el desarrollo.
Douglas (22:20)
Sí, fíjate
que realmente que estoy muy de acuerdo, muy de acuerdo con vos. Yo creo que si definitivamente hablamos de las bondades y beneficios de serverless, lo que he mencionado, son beneficios muy reales, muy válidos. Justo el ejemplo que nos diste es la audiencia específica para serverless. Son developers, ya lo dijimos, que quieren enfocarse en su código. Entonces, si tenemos que mencionar beneficios, yo creo que...
Juan (22:39)
Exacto.
Douglas (22:48)
tal cual como vos dijiste eso resulta muy atractivo para programadores, para personas nuevas que quieren enfocarse en el código y no es una solución mala no es una solución mala en lo absoluto cuando tu aplicación encaja ahí, verdad? ya vamos a hablar luego que aplicaciones encajan bien o no ya lo dijimos pero quiero dar ese punto porque de nuevo a nivel personal
Juan (23:01)
mmm
Douglas (23:16)
Cuando pienso en soluciones a gran escala y aún en soluciones pequeñas, yo no pienso en serverless. Definitivamente soy alguien que tiene experiencia con la parte de infraestructura. Y entonces pienso en el costo, porque un minuto de serverless cuesta muchísimo más dinero que un minuto de una instancia on demand. Y esas cosas son importantes. Entonces, claro.
Juan (23:33)
jejejeje
que
hay idublas el contra argumento siempre es que dicen bueno pero si tu aplicación ya tiene miles de usuarios en teoría podés costearte estas soluciones no es el mejor argumento pero pues por ahí va
Douglas (23:57)
No, no, no.
No, no, mira,
yo creo que sí es un buen argumento, o sea, y ya vamos a entrar en esa parte, no quiero adelantarme tal vez a las cosas, es un muy buen argumento, es un argumento válido, definitivamente cuando ya estás a ese punto, vas a entrar a una solución diferente y vas a salir de serverless. Solo quiero decir que desde mi perspectiva tengo poca mentalidad de inclinarme hacia arquitectar algo serverless porque yo puedo configurar la parte de sistemas.
Juan (24:25)
Mm-hmm.
Douglas (24:30)
Pero viéndolo objetivamente, yo no soy audiencia para serverless, eso no vuelve malo a serverless ni para mí, ni para los programadores. Entonces quiero realmente reconocer todas las bondades y beneficios que vos has mencionado con respecto a serverless, sobre todo para programadores.
Juan (24:48)
Si, si, correcto. Bueno, incluso en mi caso yo me especializo actualmente en backend. que digamos que para mí pues no tiene un atractivo, pero de nuevo cuando somos alguien que tiene que crear un sistema en su totalidad y probablemente sólo somos una o dos personas, definitivamente son una gran ayuda.
También hay que tener en cuenta que nos dan muchos otros beneficios como mencionaba lo que es la autenticación la podemos utilizar. hecho Firebase nos permite utilizar la autenticación de Firebase con otra, no tiene que estar alojado en su servicio específicamente. Podríamos tener nuestra aplicación que está corriendo en DigitalOcean y con su backend de toda la vida y conectarnos a Firebase.
authentication creo que se llama y lo mismo creo que sucede con AWS si no me equivoco el de AWS es Cognito me parece que ese es... si verdad ok también lo podemos utilizar con otras aplicaciones
Douglas (25:58)
Sí.
Juan (26:06)
así que bueno no estamos tan amarrados en eso aunque bueno ya vamos a hablar sobre lo que es el vendor locking también hay que tener en cuenta eso pero nos dan muchas más soluciones que realmente bueno como ya lo mencionaba para un developer se vuelve muy muy atractivo el hecho de tener algo simplificado generalmente tienen mucho hay soluciones que tienen mucho
éxito, tiene mucho éxito cuando son bien simples de utilizar por ejemplo se me viene a la mente Bersel, Bersel si no me equivoco por detrás utiliza AWS al final del día nuestros servicios en Bersel están ocurriendo en AWS pero ellos lo hacen mucho más fácil de manejar y configurar y ya no tenemos que aprendernos todo aquel montón de servicios que
forma parte del stack de AWS. que ese siempre va a ser el atractivo y más para los developers que casi siempre verdadulas los developers como que no quieren salir de su mundillo de bueno yo programa en react y eso lo que me interesa lo demás pues lo puedo lo puedo dejar ahí en serverless
Douglas (27:28)
Sí,
y lo entiendo, es su rol. Igual podría dar el mismo argumento de mi parte, de pensar, yo no quiero programar, no quiero salirme de mi mundo. Lo entiendo, de nuevo lo entiendo, lo importante es tener mente abierta, reconocer cuál es la solución apropiada para cada área y que las personas que trabajan con Cerberless, si van a arquitectar algo de una escala más grande...
Juan (27:32)
Mm-hmm.
⁓ cierto,
Douglas (27:58)
pues puedan buscar la solución correcta porque es que mira Juan se volvió como una moda serverless y yo recuerdo muy bien incluso compañías grandes moviendo soluciones enteras de servicios y microservicios a serverless y hacían sus papers y publicaban blog posts de cómo lo hicieron y los beneficios y a medida pasó el tiempo
Juan (28:13)
Mmm.
Douglas (28:26)
algunos no hicieron bulla y se regresaron de nuevo a instancias o a contenedores, otros sí contaron su historia de por qué se regresaron. yo creo que hoy en día no es tan moda como lo fue antes, pero yo creo que el mensaje que yo quiero transmitir es no nos dejemos llevar por los buzzwords y por la moda en tecnología, sino que acomodémonos.
a la solución correcta y cuando serverless es correcto usar es fabuloso.
Juan (29:02)
De hecho, ya que lo mencionas, Amazon Prime Video.
ellos se movieron de un montón de microservicios, Lambdas, que tenían, a un monolito. Ahora, el monolito, si no me equivoco, creo que sigue estando en una Lambda, me parece que algo así vi. Pero, se movieron y redujeron, lanzaron su paper de cómo redujeron una gran cantidad de costos. Y es interesante porque es Amazon, ellos son los que promueven Lambda y aún así se salieron de ese barco, se bajaron del barco.
muy interesante, definitivamente hay que tener en cuenta todas estos datos al momento de hacer algo y bueno eso me da pie a pasar a antes de ir a los puntos negativos porque hay puntos negativos, gustaría hablar un poco de cómo es la mentalidad del developer que empieza a hacer arquitectura o arquitectar un software serverless definitivamente cambia, no es lo mismo
Y es gran problema nosotros.
muy fácil hacer una aplicación rápido pero también es muy fácil hacer una mala aplicación con arquitectura serverless y bueno ahí ya es responsabilidad nuestra para poder crear algo que no nos disparen el pie como dicen verdad porque puede pasar puede pasar definitivamente el punto positivo que yo le veo Douglas a esto es que sí tenemos no tenemos un entendimiento tan
level o tan profundo de lo que está sucediendo por detrás. Sin embargo, creo que es una buena introducción, diría yo, para ir pensando en todo lo que implica nuestra aplicación. bueno, regresando al ejemplo que te daba de la primera vez que hice esto, nuestro... Yo lo único con lo que tenía experiencia era haciendo la parte del front-end. Sin embargo, con el servicio server,
me permitió explorar las partes de base de datos, los archivos, dónde voy a guardar los archivos y todas estas cosas que realmente...
al inicio no las tenemos tan claros, así que creo que es una buena forma de tal vez iniciar podría decir o al menos empieza a formar nuestra mente para ir pensando en todo lo que conlleva el sistema. Eso creo que podría yo rescatar de al momento de arquitectar una aplicación serverless.
Douglas (32:17)
Si Juan, mira definitivamente, yo estoy de acuerdo con vos en esa parte, es una buena introducción para las personas que quieren comenzar a, los programadores que quieren comenzar a ⁓ arquitectar soluciones enteras. Ahora, mira esto es lo que yo te mencionaba al principio, donde todo tiene un costo y donde siempre hay un nivel en el cual...
No todo es tan bueno como parece. Si bien es cierto para los programadores se abstrae el conocimiento de configurar el servidor, siempre hay algo que tienes que entender y manejar muy bien al momento de arquitectar tu solución. Y yo soy de acuerdo con vos y tu punto es, me sirve para ir viendo conexiones a bases de datos, autenticaciones y los diferentes niveles.
pero me toca entender algo que vos dijiste por ejemplo los tiempos de ejecución tengo que ver cuánto tiempo de ejecución timeouts tengo que entender cómo voy a almacenar la información porque es algo que va correr por 30 segundos 40 segundos y luego se va pagar por completo se ocupa guardar información para la siguiente vez donde va a estar guardado cuántas veces voy a estar corriendo lo que estoy haciendo
Juan (33:38)
Sí.
Douglas (33:42)
porque ya dijimos que el segundo es más caro. Idealmente, como va correr menos tiempo, aunque el segundo es más caro, es donde compenso, porque va a correr solo algunas cuantas veces. Pero qué pasa si tengo un proceso que me toca estarlo llamando muchas veces. Entonces, ahí es el caché entra en juego, ejemplo. ¿Verdad? Podemos hacer un servicio que nos devuelva una respuesta.
Juan (34:03)
Sí.
Douglas (34:08)
y si es algo que no va a estar cambiando tanto tiempo lo podemos cachar en el Edge cerca del usuario por 5 minutos, por 10 minutos a veces un caché de 30 segundos o 10 segundos es una gran ayuda, no? hace una gran diferencia, entonces los programadores no van a tener que preocuparse por la parte de configuración del servidor y eso es muy bueno pero van a tener que preocuparse por las diferentes capabilidades
Juan (34:22)
Hace la diferencia.
Douglas (34:37)
que tiene la plataforma que están utilizando en cuestión de cuánto tiempo corre una función. Yo creo que ahora llegan hasta como 10 minutos. Ya casi que es una instancia corriendo, Pero antes yo recuerdo que eran 30 segundos, un minuto, y tenías que considerar eso. La plataforma te ofrece, como vos dijiste, autenticación y la conexión a base de datos. Entonces, siempre.
Juan (34:43)
mmm mmm
Douglas (35:07)
el programador siempre va a tener que aprender algo y esa es la parte donde yo te decía no es tan no es tan como dicen en inglés set and forget it no verdad tengo que investigar siempre bien la plataforma si queremos arquitectar una solución buena si queremos desplegar una solución buena siempre al programador siempre le va tocar invertir tiempo en
Juan (35:18)
Uh-huh.
Douglas (35:35)
entender las diferentes capacidades que tiene la plataforma que está utilizando. Entonces es muy bueno para comenzar. Estoy muy de acuerdo con ello, pero el tiempo de investigar y de entender bien ese tiempo hay que invertirlo siempre sí o sí de repente enfocado. No de repente, yo creo que sí es enfocado más a un ambiente y un lenguaje más amigable para un programador. Sin tener que estarse preocupando por.
cuestiones de sistemas operativos o de redes conexiones etcétera verdad pero si a eso me refería al principio cuando no es tan fácil como parece el tiempo de investigar la plataforma se tiene que invertir sí o sí
Juan (36:06)
mmm
Esto me hace pensar Douglas entonces porque incluso yo lo estaba mencionando que es una buena forma de empezar. mencionabas también que luego se puede transicionar fuera del ambiente serverless. Entonces pareciera que serverless es una solución momentánea, es una solución temporal. Y la verdad es que también viendo los ejemplos de muchas empresas, pareciera que es así.
pareciera que es una solución que nos ayuda, es el empujón que tenemos para lanzar nuestro producto y darnos a conocer más cuando son startups. Darnos a conocer y empezar a conseguir usuarios, pero como que siempre hay que tener la mirada puesta en que más adelante hay que migrar y hay que salirnos del serverless. Tal vez no siempre dentro de la nube, pero ya no en esta arquitectura serverless.
Douglas (37:18)
Sí, que mira,
una de las cosas que yo, en su momento cuando quisimos hacer soluciones serverless, en cuestión de costos, lamentablemente no tengo el dato exacto, pero creo que en su momento lo que le tomaba serverless, el costo de correr por cuatro o seis horas, cuatro horas creo, o cinco horas serverless, claro, asumiendo que corre una función y tras que termina vuelve a iniciar y tras que termina vuelve a iniciar.
correr cuatro horas una función es el mismo costo que correr 24 horas una instancia en su momento creo que eran entre cuatro a seis horas para que te hagas idea entonces cuando vos tenés un serverless la intención es procesos cortos y rápidos que no se repiten tantas veces en el día entonces en ese sentido vos ganas con serverless
y si lo analizas no tiene que ser algo que corra cuatro horas en el día, la sumatoria de cada función en realidad entonces tiene que ser algo que corra de una a dos horas en el día para que te compense, verdad, para que te compense el costo realmente y ahí estás consumiendo si corres por una o dos horas en el día la función estás consumiendo más o menos la mitad de lo que te costaría tener una instancia corriendo todo el tiempo
Juan (38:28)
Mm-hmm.
Douglas (38:45)
Y volvemos, claro, tener la distancia, necesito el tiempo para configurarla, esa parte ya está clara, pero eso son de las cosas, Juan, que se consideran al momento en cuando me sirve serverless. Si voy a estar corriendo por mucho tiempo, en realidad me va a salir mucho más caro. A los programadores les recomiendo que invertan mejor el tiempo en aprender un poquito de configuración o que busquen a alguien de sistemas para ser equipo.
y configurar su aplicación en lugar de correr en serverless y es ahí donde por eso decía y vos lo mencionaste es cambia tu código cuando serverless verdad hay que pensar bastante orientado a caché bastante orientado a reutilizar procesos para correr la función lo menos posible al final con serverless el objetivo es correr esas funciones la menor cantidad de veces posibles el menor tiempo posible entonces
de nuevo, ⁓ me disculpo por no tener datos exactos, pero en su momento cuando hice esos cálculos, era no más de seis horas al día corriendo una función y ya superaba el precio de una instancia corriendo por 24 horas.
Juan (39:59)
si si definitivamente los precios ya cuando te empezaste a salir del free tier también porque también muchas veces nos dan un set de créditos o
un tiempo de ejecución gratis pero pero ya cuando empezás a salirte de ahí sí se vuelve complejo también como mencionaba al inicio yo quería también mostrar las bondades del serverless porque creo que ahora que ya no es la moda ya podemos como evaluarlo de una mejor manera pero también creo que más adelante podríamos también dar algunas sugerencias doulas sobre
que opciones hay que pueden ser similares a serverless pero que no son serverless pero bueno antes de ir ahí creo que podemos pasar entonces a cuáles son los puntos negativos y ya los hemos ido mencionando ya hemos ido hablando sobre estas cosas por ejemplo lo que mencionabas de los tiempos de ejecución cortos algo que también afecta son los denominados cold starts significa que cuando
cuando
nuestra función lambda se ejecuta por primera vez, esa primera vez va a más tiempo que las siguientes veces y eso es algo que hay que tomar en cuenta hay que saber que esa primera vez y ojo esta primera vez no es no es que es la primera primerísima vez sino que después de un tiempo si no se ejecuta nuestra la instancia donde se va a correr la
funciona lambda, no recuerdo si es que se elimina o se apaga o se ponen standby pero ya no se utiliza en el servidor de la nube así que después de un tiempo es que cuando ha pasado suficiente tiempo ya se considera que tiene que volver a arrancar y como calentar motores por decirlo así y bueno ahí entonces tenemos que tener en cuenta cuántas veces se va a ejecutar porque no tiene que ser algo tan
corrido, como decías, no tiene que estarse ejecutando tan constantemente, pero también si logramos ejecutar múltiples acciones a la vez o de manera seguida, vamos a tener cierto beneficio en cuanto al tiempo de respuesta. Aquí estamos hablando del tiempo de respuesta, todavía no estamos hablando de la billetera, eso viene después, pero eso puede hacer que al inicio parezca que nuestra aplicación es más lenta, pero a medida se va ejecutando más veces, ganamos tiempo.
esas son cosas que como decía Dulas requiere que investiguemos, leamos la documentación, leamos las opiniones de otras personas que también ya han utilizado estas soluciones porque definitivamente pasa. Lo otro que quería mencionar es que puede ser complicado, puede ser un poco complejo el debuggear estas aplicaciones. Cuando tenemos múltiples lambdas y
y de nuevo como tal vez no estamos muy familiarizados con soluciones completas tal vez no nos preocupamos mucho por los logs y no entendemos bien cómo funciona entonces de buggear una aplicación lambda puede representar un desafío no sé si alguna vez te tocó tener que buscar algún log o algo así en las lambdas de AWS pero puede ser más o
nos complicado dependiendo de la persona definitivamente más cuando venimos empezando que no tenemos experiencia
Douglas (43:51)
Si, fíjate que
en ese sentido van a agregar, si realmente sobre todo para programadores entrando a esto de serverless y si vamos al caso específico de AWS con Lambda, si se puede volver complicado porque normalmente toca recurrir a enviar estos logs a CloudWatch en AWS para que los logs queden guardados de manera permanente, esto es más costos.
Juan (44:13)
Mm-hmm.
Douglas (44:20)
porque estamos usando un servicio más, si bien es cierto es relativamente cómodo, entre más se usa, se paga y requiere otro conocimiento más por adquirir el saber enviar logs a otro lugar y el saber luego hacer el debugging de las aplicaciones entonces entre más discutimos el tema más conocimiento va saliendo a la luz, verdad
Juan (44:33)
Así.
Douglas (44:48)
Entonces, de nuevo, no con intención ni de hablar mal ni de desanimar a nadie, simplemente tratar de poner las cartas sobre la mesa y hablar la realidad, ¿verdad? Entonces, en cuestión de debugging, un programador es muy probable que tenga que invertir un poco de tiempo en entender bien qué herramientas tiene a su disposición para poder acceder a los logs de la aplicación.
Juan (44:56)
Mhmm.
Y ya de por si, siempre debuggear una aplicación de backend representa un cierto desafío, porque hay que tener de antemano, hay que haber preveído qué tipo de logs vamos a mostrar, el nivel de logs, todas estas cosas. Pero bueno, con una capa de abstracción extra puede representar un desafío extra.
lo siguiente que me gustaría mencionar bueno vamos a hablarlo como es son las facturas altas definitivamente al inicio puede ser muy barato incluso gratis de hecho todas estas soluciones que yo he hecho nunca han salido del free tier porque no han sido aplicaciones grandes pero una vez nuestro sistema aplicación crece lo suficiente como para que ya nos toca
de nuestra bolsa, es donde puede representar un verdadero desafío el cómo malabar a estos costos porque ya no se trata solamente de alquilar una máquina virtual o un servidor en la nube, ya no se trata solamente de cuánto storage estamos agregando, no, ya son cálculos bien complejos porque nos van a cobrar dependiendo del tiempo de cómputo, nos van a cobrar por
la transferencia de datos, nos van a cobrar por también el storage que estamos utilizando tienen demasiados pequeños apartados que hay que tener en cuenta que bueno de hecho por eso hoy en día tienen esos calculadoras para para poder saber más o menos cuánto vas a gastar al mes pero sí se vuelve bien complejo estar cuidando esos costos y estar cuidando que no sobrepasen
pasemos
nuestros, bueno, nuestros presupuestos. Y que hoy en día también ya nos permiten, hay ayudas por parte de la plataforma, permiten setear o configurar un presupuesto límite, porque hay muchas historias de terror, Donde algo, no sé, sufrieron un ataque o la aplicación entró en un ciclo infinito y luego les llegan facturas de miles.
dólares entonces y es un solo developer así que ya ahora también nos permite configurar un presupuesto límite y la aplicación sólo puede llegar hasta ahí pero pues nuevamente definitivamente el aspecto económico es uno de los problemas más grandes diría yo creo que ese es definitivamente siempre el dinero es el mayor de los problemas creo
Douglas (48:07)
Si, fijate Juan, que para
ser justo con Serverless, realmente que cuidar los costos, los gastos cuando trabajas en la nube en general es crítico y te puede pasar aun con instancias o con servicios, cualquiera de los servicios que te ofrecen los diferentes proveedores de nube.
porque realmente que los servicios de nube son caros sobre todo cuando trabajas con soluciones mas grandes entonces para ser justos con serverless ese cuidado hay que tenerlo siempre eso es muy importante, es muy critico lo que si cabe resaltar con serverless es que es fácil perder el norte porque como ya lo mencionamos es mas caro el minuto de serverless
Juan (48:41)
Sí.
Douglas (48:54)
que el minuto de las instancias on demand es mucho más caro y todavía estamos hablando de por ejemplo AWS instancias on demand si usas spot instances por ejemplo que para quienes no sepan spot instances son instancias que AWS te las da a un tercio a veces o mucho menos del tercio del precio de una instancia on demand con porque él te lo da de espacio reservado
como al final son servidores físicos, entonces va teniendo como espacitos reservados entre los diferentes servidores físicos ellos pueden dar esos, esas spot instances a un precio mucho más barato pero la contraparte de ellos es que esa instancia te la van a quitar en cualquier momento la van a quitar, la van a matar sí o sí y ellos te dan dos minutos de preaviso te mandan dos minutos de preaviso y te dicen
esta instancia, spot instance que pediste se va a ir sí o sí. Entonces vos tenés vos tenés que tener tu self healing, tus procesos internos que se encarguen de mover tus tus tus en esos dos minutos tu workload, tu trabajo a otro spot instance. Adquirí otra instancia, movés tus servicios ahí y ya al pasar los dos minutos se le entrega de nuevo a AWS. Pero con instancias on demand de hecho se vuelve súper barato.
Juan (49:51)
Parate.
Douglas (50:16)
si trabajas con Spot Instances o con Instances on Demand. Pero volviendo al punto, la parte de cuidar los costos, Conserveables, ese es el cuidado, que el minuto es mucho más caro y si no tenemos esa mentalidad apropiada, tenemos que switchar nuestra mente a que estamos trabajando con Conserveables, a que vamos a procurar trabajar con procesos que duren idealmente segundos. Si perdemos esa mentalidad.
Juan (50:27)
Mm-hmm.
Douglas (50:45)
y lo tenemos como un servidor y hacemos que cada llamado esté corriendo y esté corriendo y esté corriendo vamos a terminar ejecutando horas y horas al día de serverless y es ahí donde va a ser un problema entonces quiero resaltar esa parte no quiero solamente mostrar eso de tenerle cuidado a los gastos algo solo como serverless porque pasa en toda la nube pero si serverless recordemos que el minuto es más caro
y entonces se vuelve exponencial el problema si no le prestamos atención.
Juan (51:20)
sí es que yo creo que el minuto es más caro porque bueno definitivamente tratan de sacarle el jugo pero bueno ahí es donde estamos viendo el costo-beneficio porque nos dan una escalabilidad automática entonces ahí es donde se justifica que nos están cobrando pero pero bueno las facturas pueden ser
Douglas (51:41)
es que es más caro
mira es más caro porque es más fácil para mí, pero es más automatizado, es más trabajo para la plataforma, para brindarte ese tipo de experiencia, es más trabajo para ellos, por ende es más caro el servicio, por eso te decía, alguien hace ese trabajo y lo que estoy haciendo yo es pagar por no hacerlo yo, y está bien, no hay ningún problema.
Juan (51:46)
Sí.
mmmm... si
Sí.
Sí.
Douglas (52:06)
Pero esa es la razón por la cual es caro. Es lo mismo, por ejemplo, las bases de datos administradas como RDS. ¿Verdad? Es cuestan como el triple de lo que te costaría una instancia. En nuestro caso, en mi trabajo con nuestros clientes, por ejemplo, nosotros trabajamos con MariaDB y nosotros hacemos los clústeres de galera en instancias de EC2 y nosotros los administramos. Es muchísimo más barato. Y de hecho, hasta tenemos mucha experiencia y nos...
tenemos un mejor rendimiento que el que puedes alcanzar con RDS, bueno, a menos que seas Aurora, Aurora realmente que tiene un muy buen rendimiento, pero es extremadamente caro, mi punto es, caro porque le estamos pagando a alguien más por lo que lo administre, ese es el punto conserverless.
Juan (52:57)
si estamos pagando a Jeff Bezos. Bueno queda claro que las facturas pueden ser
Douglas (53:00)
Sí.
Juan (53:06)
muy muy grandes pero pero bueno hay muchos hay muchas recomendaciones en línea Douglas para cada uno de estas diferentes puntos que en lo que nos cobran hay muchas recomendaciones en línea así que yo les recomendaría que busquen y se informen de cada uno de los aspectos que se pueden optimizar porque algo que si tiene el serverless es que tiene una comunidad que siempre busca optimizar todo así que comparten mucho ese tipo de información no es
infalible, es que ya con eso las facturas van a ser cero siempre, pero podríamos llegar a postergar esta migración de la que hablábamos, se puede postergar una migración a otro servicio por más tiempo, podríamos mantenernos ahí y darnos más tiempo también, no sólo de no pasarnos porque no queremos sino prepararnos, prepararnos para porque siempre migrar datos, migrar servicios es complicado.
Y hablando de migrar, ese es otro punto negativo en las soluciones serverless y es que directamente estamos cayendo en un vendor locking. ¿Qué significa esto? Estamos amarrados a la plataforma. De hecho, creo que todas, creo que tanto Azure, Google y AWS.
Creo que los tres tienen programas de ayuda a start-ups. Si tenés una start-up y querés aplicar a un programa de beneficios que ellos tienen, puedes aplicar, llenar un formulario. Realmente no conozco el proceso completo, pero si te lo aprueban, te dan, no recuerdo si es un año o si es una cantidad de créditos limitada, pero te dan muchos, muchos beneficios.
que básicamente te permite trabajar por mucho tiempo sin pagar nada te permiten hacerlo pero por qué lo hacen porque lo que quieren es que construyas una aplicación y que esté dentro de su plataforma y luego va a ser muy difícil migrar hacia otro lado por ende te vas a quedar y vas a estar ya más adelante pagándoles lo que corresponde así que eso sucede mucho es muy difícil salir de ahí
No es imposible, simplemente requiere más planeación y planificación de cómo se va a hacer pero realmente es muy complicado y también a veces Douglas es difícil porque uno se acostumbra más si es un equipo pequeño pues ya tenés todo listo, tenés todo resuelto y uno puede decir bueno pues me ajusta para pagar la factura, entonces por qué me voy a mover pero bueno como mencionábamos
Lo ideal sería transicionar fuera del serverless a medida nuestro sistema y aplicación está madurando y ya está creciendo. Pero se vuelve complicado. muchas cosas. Salir de ahí es complicado. Incluso, bueno, va a depender de caso a caso, pero algo que yo veo siempre difícil, Dulas, es el sistema de autenticación. Migrar eso es complicado. Recuerdo un proyecto en el que estuvimos, donde estuvimos pasándonos a
a otro sistema de autenticación y pues era complejo, era complicado. que siempre el vendor locking es algo que hay que tenerlo muy en cuenta junto con las facturas.
Douglas (56:46)
Si, eso es
algo, hay un grado en el que es imposible vendor locking de cierta manera porque o estas usando una herramienta o estas usando un proveedor X y toca construir o desarrollar alrededor de ello y de hecho bueno, ese no es el tema principal de Conserverless
Pero en la parte de infraestructura es bien complejo no estar vendor log porque estás desarrollando automatización para un vendor en específico. Por ejemplo, el uso de Terraform, ejemplo, comparado con algo como CloudFormation, es el CloudFormation, es el infraestructura code específico de AWS. Y entonces te dicen, hey, usa Terraform para que no seas vendor log. Pero aún ahí tu código de Terraform.
Juan (57:23)
Sí.
Douglas (57:39)
Es específico para levantar recursos de AWS. Entonces, si tuviera que migrar luego a Azure, tendría que rehacer la gran mayoría porque el provider es diferente y los recursos en Azure son bien distintos. Pero no quiero salirme del tema, solo lo quiero marcar como ejemplo de que, de hecho, también en infraestructura a veces es más fuerte. Pero si bien es cierto, hay un... Sí.
Juan (57:45)
Sí, sí.
pero
perdón, que, pero sí, tiene que ver, fíjate, porque, por ejemplo, Firebase tiene su CLI que te permite hacer el despliegue y crear nuevas funciones, crear nuevas tablas, bases de datos, entonces se puede automatizar, se puede crear el despliegue de la página web, ¿no? El cliente. Y todo eso viene en archivos de configuración, entonces, ya tenemos toda la configuración para
esa plataforma, entonces es similar, solo que tal vez en una escala menor.
Douglas (58:40)
Si, no,
no, y de acuerdo, justo hacia ahí va mi punto. Hay un nivel en el que es casi imposible no estar vendor locked y definitivamente pasa muchísimo más en serverless. Pasa muchísimo más porque no es lo mismo tener, a nivel de programación, no es lo mismo tener tu código que puede ser desplegado en un contenedor a cualquier solución, ya sea Docker Swarm, sea Kubernetes, sea en...
en AWS, sea en Azure, sea en Google Cloud, no es lo mismo tener eso a trabajar dentro de un framework de serverless, donde tu mismo código muchas veces usa un SDK o un framework específico para poder funcionar dentro de esa plataforma, sino que aparte las diferentes herramientas para deployment como vos decís. Entonces, el punto final acá que yo quiero hacer es, es imposible estar cero vendor log en todo.
es imposible, pero procuremos en la medida de lo posible arquitectar soluciones que puedan o fácilmente ese código ser convertido a cualquier otra herramienta o vendor o definitivamente que pueda correr en cualquier vendor. Hagamos nuestra parte, seamos diligente en hacer nuestra parte y evitarlo en cuanto dependa de nosotros.
Juan (1:00:04)
Sí, claro, hay diferentes maneras de arquitectar la aplicación, siempre se puede, pero bueno, puede ser complejo en cierto momento. Otro punto que me gustaría resaltar en cuanto a los puntos negativos de serverless es la seguridad, Douglas.
Douglas (1:00:13)
Sí.
Juan (1:00:24)
Hace poco salió una noticia de una aplicación, la verdad no estoy muy al tanto de cómo funcionaba la aplicación, que era un sitio donde diferentes mujeres podían investigar a hombres.
o era algo de citas, no recuerdo. Pero esto surgió a la luz porque se filtró o sí se filtró podríamos decir toda la base de datos. Esta era una aplicación que corría precisamente en Firebase y en Firebase la base de datos la protegemos con lo que ellos tienen los llamados Firestore Rules. Entonces tenemos diferentes reglas que es para tanto para los archivos como para
la
base de datos. Al parecer estaba mal configurado. alguien logró identificar esto porque estos son APIs que se ejecutan desde el cliente. que con simplemente inspeccionar nuestro navegador podemos ver qué se está llamando. Así que alguien identificó esto y pues toda la base de datos estaba al descubierto. Toda la información de cientos, si no es que miles de mujeres y también hombres.
donde tenían un perfil para este tipo de aplicaciones fue descubierto entonces es muy muy fácil meter la pata en este tipo de cosas porque la seguridad no es como en una aplicación tradicional por decirlo así donde probablemente la base de datos ni siquiera la exponemos hace poco nosotros hicimos un directo con Douglas por si no lo han visto y hablábamos sobre cómo estaba
Douglas (1:01:54)
Mm-hmm.
Juan (1:02:11)
aquí te da una solución, una aplicación y en ese diagrama que mostramos que lo hizo Douglas podíamos notar que la base de datos no podía ser accedida desde afuera, sólo era a través de la aplicación y claro hay otras formas, está el famoso SQL injection y muchas otras formas de hacerlo pero es más complejo que con estas otras soluciones cuando se hace mal
claro se puede protegerlo, podemos hacer reglas que nos ayuden a proteger los datos y hacer muchas cosas pero ⁓
definitivamente es un punto que, bueno no sé si considerarlo negativo pero si es un punto que hay que tener muy en cuenta al momento de hacer este tipo de aplicaciones porque puede pasar como ya lo vimos esta era una aplicación muy grande lamentablemente no recuerdo el nombre pero era algo referente a citas o investigación no recuerdo y se filtro todo y esto también si nos ponemos a googlear vamos a encontrar muchos casos así entonces requiere que tengamos un
una mentalidad diferente al momento de crear estas soluciones porque puede pasar y eso sería perjudicial desde todos los aspectos tanto como publicidad mala como los usuarios pierden credibilidad o hasta afrontar acciones legales así que es algo que tener en cuenta
Douglas (1:03:44)
Si
Juan, mira, que esto vuelve a circular y regresa al punto que hemos mencionado de investigar y entender bien la plataforma en la que estamos porque vos mencionaste, hay maneras de protegerlo el hecho de que exista una base de datos no importa cuantas reglas le pongas pero una base de datos que su endpoint sea público para mi es de miedo, para mi...
Juan (1:03:56)
Sí.
Red Flag
Douglas (1:04:12)
Sí, para mí realmente es algo preocupante. Sin embargo, como vos decís, estas plataformas tienen diferentes reglas, diferentes formas de asegurar. Y circulamos a lo mismo. Toca invertir el tiempo para entender bien lo que se está haciendo, para leer bien la documentación, qué capacidades, qué funcionalidades están a nuestra disposición para proteger e implementar lo correcto. Y esto aplica a todo, Juan. Quiero aclarar aquí.
Muchas veces encontramos tutoriales en línea, son muy buenos, son muy buenos. Pero recordemos gente que esos tutoriales son un punto de partida. Ninguno de esos tutoriales son para darnos algo listo para producción. Es la realidad. No siempre o muy poquitos casos realmente sería así. Entonces creo que la seguridad es algo bien crítico y aquí aplica
los mismos de los otros puntos dediquemos el tiempo para ver bien porque es algo muy serio y esto que vuelve que los servicios sean administrables y fáciles para cualquiera también normalmente suelen ser más fáciles de vulnerar de vulnerar vulnerable
Juan (1:05:28)
Sí.
sí es que cuando ya es la puerta está abierta es bien difícil es bien difícil asegurarlo pero bueno es es otra mentalidad es otra forma de hacer las aplicaciones que se puede hacer y pero bueno me realmente quería mencionarlo para que lo tengan en cuenta por último en cuanto a este tema Douglas me gustaría mencionar que este tipo de aplicaciones o servicios mejor dicho tiene limitantes
realmente no es... funciona para la gran mayoría de aplicaciones
pero van a haber unas cuantas que no las vamos a poder hacer aquí o al menos podríamos decir que no es la mejor opción para ciertas aplicaciones. Por ejemplo, una aplicación que requiera que esté ejecutándose un proceso en el background constantemente, pues ya de entrada no. Ya la parte serverless queda descartado porque realmente no va con ese objetivo.
Entonces hay que tener en cuenta, por eso mencionaba, vale la pena sentarnos y analizar qué es lo que queremos hacer para luego poder decidir en qué soluciones vamos a tomar. Porque definitivamente hay limitantes o tal vez la base de datos que queremos utilizar no es la mejor opción. Por ejemplo, Firebase es una base de datos no relacional.
las bases de datos no relacionales son muy buenas, a mi en lo personal me gustan, pero hay cosas que se complican más adelante comparado con una base de datos relacional y viceversa también pasa, ¿no? Una base de datos relacional es complejo a veces comparado con una no relacional, por eso es necesario. Incluso es necesario comparar los servicios, por eso mencionaba Firebase tiene una base de datos no relacional.
SuperBase tiene una base de datos relacional AWS, podemos elegir MariaDB, Postgres, entonces es necesario revisar este tipo de cosas y analizar qué es lo que va ser nuestra aplicación. No solamente lanzarnos porque es fácil y no me voy a preocupar por el backend. No, si tomamos la decisión incorrecta...
incluso nos vamos a preocupar incluso más por todo lo que está sucediendo por detrás de la aplicación. que sí, definitivamente Douglas, hay aplicaciones o mejor dicho las plataformas a veces simplemente nos limitan para lo que queremos hacer.
Douglas (1:08:15)
Yo creo que esas claves de Juan y solo quiero hacer eco, analicemos bien que tipo de aplicación estamos pensando implementar en serverless porque definitivamente cualquier aplicación que tenga procesos, yo diría no solo algo en el background constantemente, que bueno eso por si solo ya es una bandera roja de que no se puede, pero cualquier...
que tenga que estar corriendo por más de dos o tres horas al día en la sumatoria del proceso, en la sumatoria del proceso, cualquiera que tenga que estar corriendo por más de dos o tres horas al día, muy probablemente ese tipo de aplicación ya no es un candidato para serverless, entonces consideremoslo bien.
Juan (1:08:51)
Ajá, ajá.
correcto, correcto. Bien, creo que entonces Douglas...
Me gustaría pasar a lo que había mencionado al inicio. Me gustaría dar algunas recomendaciones sobre bien. Tal vez con todo lo que dijimos, en vez de alentar, alguien se desanimó y ya no quiere utilizar serverless y es válido, no pasa nada. Así que me gustaría acomodar algunos ejemplos de que también hay otras soluciones, hay otras cosas que se pueden hacer para solventar estas bondades que nos da,
estas plataformas porque al final del día un auto scaling se puede hacer lo podemos hacer requiere investigación sí pero se puede hacer entonces me gustaría bueno si te parece doulas voy a dar una recomendación que siempre la doy siempre la doy
Y lo que queremos es no preocuparnos por estar creando las bases de datos, estar creando los endpoints, algo que nos permita guardar los archivos, las imágenes y todo de manera fácil. Yo considero que una solución muy buena hoy en día puede ser dos. Una dos. Una es SuperBase, ya que SuperBase nos permite self-hosting.
permite implementarla en un servidor privado. Este servidor puede estar en la nube claramente, Pero la desventaja que yo encuentro con SuperBase es que es bien complejo de configurar. Así que aquí viene la otra opción que yo siempre doy y que para mí es la mejor de cuando venimos empezando y es PocketBase. PocketBase es un binario, literalmente descargado un archivito y eso empieza a correr.
y pocketbase ya te da todo esto, da autenticación, incluso autenticación con terceros, te da la base de datos, un dashboard para crear tablas, etcétera, diferentes colecciones, una serie de vistas para la base de datos, ojo, la base de datos es en SQL, perdón, SQLite, te da pues los endpoints, son automáticos, así que uno crea la tabla y ya tenés los endpoints listos.
así que es muy muy fácil y también tiene un SDK tanto para javascript como para flutter la última vez que revisen pero si no querés utilizar el SDK porque tu lenguaje no estaba soportado también tiene los HTTP calls de toda la vida
Así que yo creo, Douglas, que una solución como esa nos brinda estas bondades de no preocuparnos tanto por el backend, no preocuparnos tanto por la implementación de autenticación, que siempre lleva su complejidad, ya está hecha. Y al mismo tiempo tenemos un control más grande y ya la factura no depende de estos cálculos raros de estas plataformas. Simplemente tenemos
nuestro servidor y en caso que necesitemos más recursos le agregamos más RAM, más CPU que puede ser mucho más barato que estar pagando un servicio de AWS o Google.
Douglas (1:12:33)
No.
Juan (1:12:34)
Así que de mi parte yo les recomendaría que investiguen una solución como ese tipo porque puede ser muy buena para iniciar y es muy similar a tener tu propio serverless en tu servidor. Antes de iniciar me comentaba las dublas de unas opciones en Kubernetes. Pero no sé si tal vez te entendí mal, pero me gustaría que tal
nos comentaras un poco sobre eso
Douglas (1:13:08)
Si, fíjate que antes de entrar a Kubernetes, para los programadores, me gustaría también recomendarles la suite de Cloudflare. Lo mencioné al principio, verdad, pero Cloudflare tiene los tiers gratis de Cloudflare con workers y como te mencionaba, tiene su solución para object storage que se llama R2, que es su equivalente a S3 y tiene bases de datos. Aparte,
Juan (1:13:17)
Cierto, ok.
Douglas (1:13:38)
el tier gratis del CDN, el cual podemos aprovechar para cachar muchas de estas respuestas y ejecutar la menor cantidad posible. Entonces, para personas que quieran usar serverless como tal, de manera general y con un tier gratis amplio, yo les recomiendo bastante la suite de Cloudflare.
Yo no personal soy un gran fanático de los diferentes servicios de Cloudflare. Me parece muy bueno, muy sólido. Esto no es patrocinado bajo ninguna circunstancia. Simplemente es una herramienta que yo uso mucho y se la recomiendo en ese sentido. Con respecto a Kubernetes, con Kubernetes se pueden hacer soluciones serverless, pero siempre ocuparías un equipo de infraestructura detrás.
que te configure y te administre y se lo entrega a los programadores para que ellos puedan hacerlo porque lo que ocurre...
Juan (1:14:40)
Es como una
opción más avanzada para alguien que ya sabe de Kubernetes o tenés un equipo específicamente para Kubernetes, ¿verdad?
Douglas (1:14:49)
Exacto, ya sea o manejas mejor la parte de infraestructura, tienes conocimiento de Kubernetes o tal como dijiste, un equipo lo maneja. Tenes tu equipo que lo maneja y entonces yo te puedo dar un clóset de Kubernetes y diferentes soluciones porque podés desplegar un servicio que escale a cero instancias dependiendo tu proveedor de nube, no todos lo permiten, pero ese servicio vos lo desplegas con cero instancias mínimo.
y hasta que recibe tráfico va a levantar la primera instancia y entonces eso lo vuelve serverless te reduce costos verdad y entonces tenés serverless en el sentido para el developer que no tuvo que preocuparse por la configuración verdad un equipo si lo está haciendo por esa parte pero tenés esa bondad de poder escalar a cero y entonces eso te ayuda a reducir costos igual en AWS por ejemplo tenés servicios en
Juan (1:15:27)
Ok
Douglas (1:15:48)
para Kubernetes como un backend como Fargate se llama. Usualmente en Kubernetes los worker nodes que son los nodos donde corren los pods o los contenedores al final son instancias de EC2, verdad? Que no las administro yo, las administra el servicio de Kubernetes de Amazon pero al final son instancias EC2, pero también existe algo que se llama Fargate.
Juan (1:16:04)
A
Douglas (1:16:16)
que no te crea en las instancias, sino que él está creando Compute Power o poder computacional a medida lo pedís. Entonces, aún con Fargate y Kubernetes podés tener esa bondad de trabajar de cierta manera como serverless para tus equipos de desarrollo, pero ocupás ya un equipo como tal grande que está administrando la infraestructura para que los developers puedan enfocarse solamente en.
en desplegar sus aplicaciones y el equipo de infraestructura puede encargarse de estos servicios corriendo y óptimos.
Juan (1:16:53)
Me llama la atención lo de las instancias 0. Por defecto, Kubernetes siempre mantiene al menos una instancia corriendo. Se configura así. O esta solución que me está dando es un plugin o algo extra.
Douglas (1:17:10)
No, vos podes poner las replicas, los pods a cero y se configura algo que se llama Pod Autoscaler, es la de acuerdo al tráfico va incrementando la cantidad de replicas que tienes de tu servicio. A nivel de infraestructura vos vas agregando instancias a tu clóset de Kubernetes
Juan (1:17:21)
Ok
Douglas (1:17:36)
Si estás teniendo suficiente tráfico y te estás quedando sin poder computacional, entonces necesitas nuevas instancias. Esas instancias se van a agregar al cluster cuando tenés más tráfico para que en esa instancia se levanten más contenedores o más pods. Y cuando reducís el tráfico, vas quitando esa instancia del cluster y vas salvando costo, verdad? Pero también está a nivel de pods con pod autoscaler.
Juan (1:17:55)
mmmm... ok
Douglas (1:18:03)
vos desplegás tu servicio donde el mínimo de instancias es cero. Entonces si tenés cero tráfico no tenés ninguna instancia corriendo. Pero a medida que empiezas a tener tráfico eso puede escalar a 5, 10, 20, 50 pods. A la cantidad de pods que necesites. Pero entonces dentro de Kubernetes tenés la escalabilidad de los nodos que son parte del clóset de Kubernetes, las instancias que se vuelven los worker nodes.
y tienes la cantidad de replicas o la cantidad de que corre tu servicio dentro de Kubernetes. Entonces a ese me estoy refiriendo que los pods o las replicas de un servicio pueden ser escaladas a cero.
Juan (1:18:48)
Ok, entiendo. Creo que eso no lo mencionamos, pero bueno, de los puntos atractivos del serverless es el hecho de que solo vamos a pagar por el tiempo de ejecución. Y eso es que mencionábamos también, que eso es lo que se cobra los minutos que se está ejecutando. Pero tal vez no lo habíamos dicho de manera tan explícita. Pero sí, en serverless, cuando no hay tráfico, pues no estamos utilizando nada, entonces
teoría es más barato pero bueno entonces sí se puede lograr algo similar es conociendo Kubernetes que bueno muy interesante no tenía idea de eso bueno realmente estamos llegando al punto final lo que queríamos era mostrar las partes buenas de una arquitectura serverless y las partes malas como ya vi
primero tenemos cierta opinión al respecto y eso no quiere decir que sea malo o sea mejor simplemente nosotros hemos tenido ciertas experiencias y eso es que queríamos compartir tanto la parte buena como la parte no tan buena así que bueno para los que han llegado hasta aquí me gustaría agradecerles definitivamente verdad Douglas las personas que siempre
nos alegra cuando hay alguien que notamos que se quedó hasta el final. sí, definitivamente muchísimas gracias y les recordamos si nos pueden regalar un like, una compartida o compartir el vídeo, eso nos ayudaría muchísimo para poder seguir con este proyecto que tenemos entre nosotros. Pero bueno, Douglas, no sé si te gustaría algunas palabras para después
Douglas (1:20:22)
Así es.
Juan (1:20:47)
despedirnos
Douglas (1:20:49)
Sí,
por supuesto, realmente solo para cerrar, mencionar si alguien que nos ve y nos escucha se sintió desanimado a usar Serverless después de escuchar esta plática. Eso significa que lo que estabas pensando, Serverless no era el hosting adecuado para ti. Entonces considerarlo como algo positivo en el cual te ahorramos el tiempo de invertirle a Serverless.
Juan (1:21:03)
No,
Douglas (1:21:18)
Y luego a mitad del camino darte cuenta que no era la solución correcta. Para los demás, animarlos, tienen sus bondades, ¿verdad? Hagan la prueba, usen las herramientas que Juan les recomendó, usen Cloudflare y implementenlo o pruebenlo donde sea correcto implementarlo. ¿Verdad? Al final lo que buscamos hacer es simplemente traer el tema a la mesa, traer la conversación a la mesa, dar...
pro y contra, ha sido nuestra experiencia y ustedes toman la decisión final y si serverless es la solución adecuada para lo que están haciendo, saquen el jugo.
Juan (1:21:59)
Correcto, la decisión es de ustedes y bueno, déjenos en los comentarios si utilizan o han utilizado soluciones serverless, nos encantaría conocer su punto de vista. que bueno, muchísimas gracias por llegar hasta aquí y bueno, nos vemos a la próxima. Bye.