SPEAKER_00 0:00

Hablábamos de microservicios y tú me preguntaste que qué era serverless. Serverless. Less. Less. Sin. Server... Servidor. No hay servidor. No hay servidor. Qué curioso, ¿no? Que para que no haya servidor necesitas un servidor. Exacto. Y es que esa es la realidad. O sea, serverless es un término de marketing. Porque sí hay un servidor. Porque no puedes tener algo sin un servidor. Es más como la aplicación que tú vas a tener, que tú estás teniendo, no necesita un servidor físico. Ni siquiera físico. Hace mucho... A ver, vamos a hablar de esto. Es que Antes... Tienes que acordarte de que yo vengo del 2000, ¿verdad? Donde era un webmaster. Es que ya no hay de esos. Y entonces hay que reiniciar el servidor y tú le dabas a tu del... Reiniciarlo. Es que justo es a lo que iba. O sea, antes vamos a hablar de 2000... Madre santa, vamos a hablar de los 2000. ¿Sí? Vamos a hablar de los 2000. Cuando tú querías tener una aplicación, necesitabas rentar un servidor físico. Ajá. Hasta mucho tiempo, un tiempo después, vamos a decir 2010, en los 2010, empezó esta revolución, si mi timeline no me falla, de los VPS, que son Virtual Private Servers. Virtual Private Services. VPS. Servers. Virtual Private Services. Servers. Servers. No. No services. Virtual Private Servers. ¿Qué era un Virtual Private Service? ¿Server? Ya nos hicimos bolas. Un VPS. ¿Qué es un VPS? Básicamente es... Antes tenías que tener, como tú decías, una computadora por servicio. Dedicada. Dedicada. Un servidor dedicado. Así se llamaban. Servidor dedicado. Ahora dentro de un mismo... Dentro de un servidor, una computadora física, puedes tener diferentes servidores virtuales. muchas máquinas virtuales corriendo dentro del mismo servidor físico ese es un VPS después entró esta idea de que vámonos a la nube después a tener un VPS esto tiene que ver con esos tweets que ya no son tweets, ahora son posts son touches son touches son exis son cis no sé como se dice quiere Elon que le llamen pero este cuando la raza viene y dice no manches dejé prendido no sé qué servicio y le están cobrando a la empresa un chorro de varo es por este serverless situation con un microservice que dejaron prendido es que es que justo justo para allá vamos este porque después del VPS llega esta idea de irnos a la nube y cuando hablamos de irnos a la nube básicamente significa que ok ya no ya estoy todavía más removido del hardware ok si antes empezabas otra vez un servidor dedicado tú tenías tú tenías una computadora física en un en un cuarto en un cuarto de lado ajá ahora cuando nos pasamos a los VPS es cuando empezaron cuando empezó la tendencia de que ya había compañías que te manejaban te administraban el hardware y te daban acceso a una máquina virtual privada si ahora cuando hablamos de irnos a la nube que fue como que la siguiente iteración de todo esto pero que yo me lo me lo me lo imagino como esa escena final de Matrix donde Neo regresa al Source y ahí están todos los servidores así es una empresa que te renta un VPS es una empresa que te renta un VPS y si no han visto Matrix ¿cómo es posible? es que la raza no manches si es cierto o sea hay raza que probablemente tiene 19 años 20 años que no ha visto Matrix. Ya les arruinaste el jale. Pero bueno, cuando hablamos de irnos a la nube, fue básicamente una abstracción de esto. Tú ya no te preocupas ni siquiera por el VPS, te preocupas por tu servicio. ¿Pero cómo lo conceptualizas? O sea, ya no es un pedazo de hardware. Es marketing. Es lo mismo, pero con un hombre bonito para vendértelo más caro. El concepto de la nube es ya no nada más abstraer el concepto del servidor, sino abstraer el concepto de qué hace el servidor. Entonces, por ejemplo, tienes una nube de fotos, tienes una nube de videos, tienes una nube de documentos. Está en la nube. Es una capita arriba de un VPS que vive en servidores. Ahora, eso, lo de la nube, es más conocido en el el user space, los usuarios finales, final user space. Sí, porque no sabemos qué es lo que está pasando realmente. Pero todo mundo sabe que, ah, está en la nube. Es que lo subía. No es algo etéreo. Ajá. Todo el mundo lo dice, está en la nube. Hola, ¿qué tal? Soy Darwin y en menos de un minuto regresamos con este episodio. Pero antes, quiero hacerte una recomendación. Si estás escuchando este podcast, claramente estás buscando mejorar tu inglés a nivel profesional. Ya sea para conseguir un mejor puesto dentro de una organización o para tener clientes en el extranjero o probablemente aplicar a esa vacante que te pide un nivel alto de inglés o sencillamente porque quieres entender más de cómo hablan los devs alrededor tuyo cualquiera que sea el caso déjame invitarte a que te unas a nuestra comunidad de inglés para devs en donde cientos de personas ya están haciendo networking y al mismo tiempo están mejorando su inglés con nuestras rutinas y ejercicios diarios de práctica así como nuestros círculos de conversación semanales para practicar tu inglés tanto escrito como oral y gozar de feedback mío y de mis teachers en tiempo real. Formar parte de nuestra comunidad es súper sencillo. Estamos en todas las redes sociales como Darwin English o Inglés para Devs. Solo manda un mensaje directo y dime literal quiero ser parte de la comunidad. Y voilà, listo. Recuerda que todo esto es 100% gratis y lo único que te pido es que nos ayudes a compartir los consejos para mejorar tu inglés en alguna de nuestras redes sociales. Ex o antes llamada Twitter, Facebook, Instagram, TikTok y hasta en LinkedIn. Sin más, te dejo escuchar el resto del episodio. De antemano ¡Adiós! sino llevarlo a nivel función. ¿Me explico? Tu servicio en la nube es una aplicación que tiene muchas funciones. La idea de serverless es que tú puedas escribir una función sin necesidad de configurar un servidor. Entonces, cuando hablamos de serverless, no estás corriendo servidores, estás corriendo servicios, funciones específicas. tú a la plataforma serverless le pones tu código literal no haces git push no haces nada de eso bueno, a lo mejor sí pero tú pasas código una función de 20 líneas que hace algo bien específico y el servicio de serverless se encarga de configurarte todo todo lo que necesitas para que esa función funcione. O sea, puedes apagar y prender funciones de manera individual. Pero es la siguiente abstracción entonces, porque ya no estás pensando en servidores, estás pensando en servicios. El tema aquí es Sigue habiendo un servidor. Pero se supondría que debería ser como invisible o que el usuario final no debería pensar en él. El developer no se tiene que preocupar por el servidor. Se tiene que preocupar por su servicio. Y el servicio está expresado como funciones. ¿Y quién te configura eso? O sea, al principio cuando haces el contrato, supongo, de renta, del fin, no sé, algo, le pasas ahí los parámetros que vas a necesitar. Es que esa es la cosa. O sea, tú puedes contratar serverless o tú puedes contratar servicios serverless dependiendo de tu stack. O sea, por ejemplo, hay serverless para Go, hay serverless para Swift, hay serverless para Java, para Kotlin, para bla, bla, bla. Entonces, dependiendo del stack que tú traigas, empresas como Amazon, como Google Cloud, como todos estos, te ofrecen estos servicios de Cloud Functions, por ejemplo. Creo que así se llama en Amazon, Cloud Functions. Que básicamente es tú pegas tu código y le dices que esta madre este código te dan una URL y cuando quieras pégale a esta URL y nosotros nos aseguramos de que jale lo que tú pusiste aquí. ¿Cuál es el reto? Es muy caro. Es muy caro porque ahí te empiezan a cobrar por ciclos. Te empiezan a cobrar por cada corrida de función. Ah, eso te iba a decir. O sea, cada vez que accesas a la función, cuando dije este ciclo, dije, ¿qué será? Te empiezan a cobrar por cada corrida por cuántos datos transmites. Te empiezan a cobrar como por cosas que no puedes controlar necesariamente. Si tienes un usuario que se la pasa dándole refresh, refresh, refresh, te están cobrando cada llamada de API. Entonces, es una abstracción que como todo, diría, no significa que serverless sea algo necesariamente malo. ¿Pero sabes cómo estructuran ese... ¿Ese costo de estas empresas? O sea, por uso de procesador, por espacio... Cuando dices estas empresas, ¿te refieres a las empresas que prestan el servicio? Sí, como Google Cloud. Muchas veces lo que se hace es una proyección de cuánto cuesta tener el servidor encendido. Y se hace la proyección. Y es que te hablaba de... de estos tweets, de estos posts que la gente dice recibimos un ataque, pero el mismo servicio no te previene de estos ataques, el mismo servicio no te avisa de esos ataques porque creemos y ahí entra un poco la raza conspirafóbica, porque creo que hasta están coludidos o a ellos les conviene no avisarnos, pero yo creo que eso pues no. La empresa debe empieza a perder credibilidad y entonces dice, pues ya no vamos con ellos. Es que es un tema también bien delicado porque, por ejemplo, si tú eres una empresa que ofrece servicios serverless y tu garantía es que la función va a estar siempre disponible, Google no tiene concepto del negocio que tú estás manejando. Entonces Google no sabe cómo saber si es un API request verdadero o no. O sea, para eso tienes que poner middlewares. Para eso tienes que poner otras capas de abstracción. ¿La empresa Google? No, no, no. El que está decidiendo usar un servicio de esta magnitud. Siempre la responsabilidad es del... Estos son los requests y si pasa de esto debería de apagarse la cosa. Exactamente. Sí, sí, sí. O sea, deberías tener filtros tú. A lo mejor desconozco. A lo mejor empresas como Google, Amazon ofrecen este tipo de filtros. La verdad desconozco. Pero yo creo que sí es responsabilidad de el arquitecto de la solución definir cuáles son esos parámetros de hasta aquí llegamos. Porque serverless es muy caro. Si lo comparas con VPS... ¿Te acuerdas que ayer te dije todo cuesta? Sí, claro. ¿Qué prefieres pagar? ¿A Google o un ingeniero que te administre? Te va a salir igual, brother. Casi, casi. Te va a salir igual. Pero es... Que te da uno, que te da otro y demás. Entonces, ahí es otra vez un poquito más del business case. Muy abstraído, pero... Nada que ver acá. Digo, ya terminamos el serverless, pero quiero en este mismo episodio preguntarte esto, que no tiene nada que ver. Pero ahorita que dijiste Kotlin, un cuarte me decía, ¿sabes qué? No puedo entrar a mis clases de inglés porque estoy tomando un bootcamp de Kotlin. Y me hizo el comentario, es que esta industria no para, hay que actualizarse y esto. Kotlin es tan solo un lenguaje de programación para backend, para frontend, para todo. ¿Tienes contexto de esto? Kotlin es un lenguaje de programación que corre en la máquina virtual de Java y esencialmente se compila a bitcode de Java. Dije muchas cosas que no entendiste, pero... Más o menos. No creo así últimamente. Pero, a ver. Kotlin, y a lo mejor este ya es otro episodio. Kotlin es un lenguaje de programación. Originalmente fue diseñado, o la primera implementación, si no me equivoco, fue para Android. Fue para desarrollar aplicaciones de Android. Y fue, digamos, el equivalente de Swift de Apple, pero es la versión de Google, que está muy enfocada en Type Safety, está muy enfocada en Memory Safety y demás. Escalabilidad, programación funcional y todo eso. El tema aquí es que Kotlin lo construyeron sobre la base de Java. Entonces, sí es un lenguaje diferente de Java, pero la cuestión con Java es que tienen lo que se le conoce como una máquina virtual. Java es un lenguaje de correr máquina virtual, se le conoce como la JVM entonces tú puedes compilar Java a un tipo de lenguaje particular que lo puede interpretar la JVM, así como puedes construir Kotlin o escribir Kotlin que se compila a Bitcode que esencialmente corre en la misma máquina virtual de Java hay otros lenguajes que también se compilan a ese Bitcode por ejemplo hay un lenguaje que se llama JRuby, no sé si lo habías escuchado nunca escribes como si fuera Ruby on Rails bueno como Ruby no Ruby on Rails como si fuera Ruby pero se compila a Java entonces son como diferentes flavors ¿y por qué la raza hace esas cosas? porque son porque son abstracciones o sea por ejemplo tú el compilador de Kotlin si tú escribes Kotlin puedes escribir código que puede ser mucho más type safe que si escribes algún otro lenguaje que se compile la JVM. ¿Qué significa type safe? Que puedes encontrar errores más a nivel al tiempo de compilación y no necesariamente el tiempo de ejecución. Entonces, mientras más cerca del proceso, mientras más al inicio del proceso puedas encontrar errores, quiere decir que tu aplicación va a tener menos problemas cuando esté ejecutándose. Entonces, Google dijo, Android ya corre Java. en vez de cambiar completamente de runtime y empezar desde cero, construimos otro lenguaje que corra sobre la misma plataforma, pero que a nivel de compilación nos ofrezca ciertas garantías, más ergonomía, mejor sintaxis, mejores APIs y demás. Pero son diferentes abstracciones. Bueno, termina el paréntesis entonces ahí.

UNKNOWN 16:41

Va. Gracias.