SPEAKER_00 0:00

Oscar, ¿qué son los microservices? Microservicios, next. Gracias por habernos acompañado. Gracias, contenido de calidad. ¿Qué son los microservicios? Primero explícame en qué contexto has escuchado esa palabra. Microservicios. No tengo la menor idea. He escuchado la palabra flotar alrededor del ambiente tech, pero no sé qué son los microservicios. Empezamos por definir qué es un servicio. Un service. ¿Has escuchado esta idea de que en los... en la industria tech o en un ecosistema de una aplicación de un producto tenemos el concepto de client and server server side client side ¿sí? service ¿qué te suena? algo que hace el server algo que hace el server entonces el servidor ofrece un servicio ya ¿no? ok ok en esencia un servidor puede tener código que está corriendo que hace muchas cosas ¿no? ¿cuál es la desventaja o el argumento hacia tener microservicios que ahorita voy a explicar eso es o más bien lo voy a abordar por otra parte ¿cuál es el problema de tener un solo servidor? que si falla algo dentro del servidor todo truena todo truena si tienes la base de datos en el mismo servidor que tienes tu aplicación web en el mismo servidor que tienes tu gateway en el mismo servidor que tienes todo si falla algo ahí se te puede caer toda la aplicación. Entonces, un servidor ofrece un servicio. Ahora, el cliente se conecta a un servidor para consumir un servicio. Y hace algún tipo de procesamiento o eso que acabas de decir, storage. Imaginémonos una aplicación como Facebook. La red social de los viejitos. Imaginémonos una la red social. Tú tienes tu cliente que es donde ves los posts, pero los posts no viven en tu teléfono. Los posts, los consultas del servicio y el servidor te los ofrece, te los sirve a través de su servicio para que los consumas en tu cliente. Ahora, ¿dónde entra el concepto de microservicios? ¿Cuál es el concepto de microservicios? Básicamente fue o es una corriente de pensamiento, vamos a ponerlo así, que dice, oye, tal vez no nos convenga tanto tener todo en el mismo lugar. No nos conviene tener todo en el mismo lugar. ¿Por esto que dices? Por lo que digo, porque si algo truena, truena todo. Si algo nos hackean, nos hackean todo. Entonces, más bien, ¿qué pasa si, regresando a episodios pasados, utilizamos el single responsibility principle, el principio de responsabilidad única, y lo aplicamos a los servidores. Donde entonces empezamos a hacer un decoupling del servidor para que cada área del servidor que sea relevante para la aplicación esté manejada por un servidor particular. Esté manejada por un servicio, por un servidor independiente. La idea de microservices, si la entiendo bien, asterisco, es que haya redundancia alrededor de esos microservicios. O sea, que dos servidores o dos servicios hagan lo mismo. Que puedas tener la posibilidad de que dos servidores hagan lo mismo por si uno falla y tienes un respaldo. Entonces hay redundancia. La idea también de los microservices, de los microservidores, microservicios, es que es más barato reconstruirlos, prenderlos y apagarlos si algo falla. Porque, por ejemplo, si tú quieres reiniciar un servidor y tienes un monolito, un monolith, pero lo que te está, vamos a poner el ejemplo, lo que te está fallando es el sistema de login y se resuelve prendiendo y apagando el servidor. Para resolver ese problema vas a tener que apagar y prender el servidor y te vas a llevar de corbata a todos los que no tenían el problema en primer lugar. Entonces, si tu servicio de login es un servicio independiente al servicio para las fotos para comentarios y demás, tú puedes prender y apagar tu servicio de login sin afectar al resto de tu aplicación. Entonces, se vuelve más modular. Hablabas y quise hacer aquí como que fluye. Sí, yo vi una onda. Una onda. Y como lo único que sé de grandes servidores es que están en el mar. A lo mejor tienen algo que ver, pero hay que no. No, no, no. Pero esa es la idea, ¿no? O sea, tú tienes un servicio que es micro, tiene una responsabilidad única y si algo le pasa, está contenido el problema ahí. Ok. Ahora, esa es la ventaja. Esto está... Perdón, adelante. No, va a haber pregunta. Esto tiene que ver algo con tecnología serverless. 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 mil 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 te doy la bienvenida a nuestra comunidad, bye bye porque entiendo por serverless que es yo tengo un negocito aquí tengo mi servidor, verdad pero creo que me convendría tener más estos servicios en la nube o estoy completamente equivocado vas en la dirección correcta, o sea están en el mismo código postal, vamos a decir microservices y serverless ahorita vamos a hablemos de eso, ahorita en lo que sigue esto que te acabo de contar es el beneficio ¿no? de microservices que tienes independencia ahora mi mi opinión al respecto es que no sirven no, no, no si sirven tienen un objetivo pero todo se trata de un balance ¿no? no tenerlo todo creo que no no tenerlo todo como microservice porque entonces ya no tienes un problema tienes diez mil problemas ya que resulta resolver y hay miles de historias en internet de compañías que se fueron full microservice que después dijeron tal vez esto ya no es tan óptimo porque entonces por ejemplo cuando tienes un microservice cuando tienes un sistema de microservicios es muy difícil y es muy complejo mantenerlos todos sincronizados por ejemplo ¿y cuál sería la contraparte entonces de los microservicios? el monolito todo en un solo lugar que también tiene sus downsides como ya te lo acabo de decir y lo que tú propones entonces es un sistema híbrido lo que yo propongo es que se utilice la arquitectura correcta para el problema que tienes enfrente o sea ejercer un poquito de pensamiento crítico así como no decir como estaría mal decir el monolito tener un monolito es la arquitectura más eficiente creo que es igual de peligroso decir los microservices es la mejor arquitectura del mundo o la más óptima. Depende mucho del contexto. ¿Qué tipo de servicios tú consideras que deberían estar en un En un servidor propio y otro en la... Yo empezaría por la distinción más... O sea, por la parte más core, que es la base de datos y la aplicación tienen que estar en servicios separados. Ok. ¿Sí? Y entre esos servicios tienen que hablarse. ¿Sí? Porque no quieres comprometer la integridad de tus datos por código de aplicación. Ya. Esa sería como la primera separación que yo haría. Los datos que es lo sensible es tuyo, entonces... tú lo tienes acá. Correcto. Y el procesamiento es fuera. Exactamente. Entonces, esa podría ser ya, podríamos decir, eso ya es un microservice que maneja la base de datos. Ya cuando te empiezas a meter mucho más en cuestiones mucho más complejas, puedes tener un microservice, por ejemplo, que nada más se encargue de authentication. No de login. Es diferente. Authentication. Claro. Sí, porque el servicio de login tendría un UI. El servicio de authentication sería un servicio que está entre el UI y el backend y la base de datos. Y lo que hace el servicio. Entonces, ahí es cuando te empiezas a dar cuenta, mientras más microservicios tienes, más complejo se vuelve tu sistema. ¿Sí? Porque entonces, ¿cómo sabes cuál es la fuente de verdad del estatus de tu aplicación? Si tienes 10 mil microservicios corriendo, cada uno haciendo una parte muy específica, sí, pero los datos los tienes regados por todos lados. Entonces empieza a haber capas de complejidad que los ingenieros tendríamos que analizar para ver si nos conviene, si no nos conviene, si tenemos el bandwidth para atender esa responsabilidad, si tenemos la capacidad para atender esa responsabilidad. Y este tema da para hablar de lo que sigue, de lo de serverless. Entonces, microservices microservices there you go