esta charla es vital para entender el funcionamiento de los microservicios una vez ya has estudiado y entendido todo lo relacionado con ellos. Creo que es la 6ta vez que la escucho, mis dieces.
En resumen es tomar una aplicación que tiene muchas funcionalidades, y dividirla en varias partes y ya, esos son microservicios, adicional a eso cada parte o microservicio puede estar hecha en un lenguaje diferente, ya que funciona de forma independiente, aunque se comunica con los demás microservicios. Cada microservicio es atendido por un equipo, y cada equipo es autónomo, a su vez un equipo puede tener a su cargo uno o más microservicios.
En el trabajo se quieren hacer microservicios con spring, pero se tiene la duda de levantar cada microservicio por contenedor. Entonces están seguros que para poder utilizar los microservicios se necesita de un tomcat en cada contenedor ¿Como sería entonces la arquitectura de los microservicios?
Hola Camilo, si los microservicios los implemenntas con contendores, entonces si, cada contenedor contará con el Tomcat. Cada contenedor tiene, por definición, absolutamente todo lo que la aplicación que corre adentro necesita para correr. Soft de base, web server, variables de entorno, etc. Suerte!
@@sebagoomez Con spring el tomcat ya viene embebido. Mi pregunta es ¿todos los microservicios van en un solo contenedor con tomcat configurado? O por el contrario cada microservicio debe ir en un contenedor aparte. En mi trabajo tienen esa duda debido a que si cada ms tiene su propio contenedor, gastaría en demasía los recursos de la máquina.
@@camiloolivo6719 Esa es una decisión de ustedes. Hay que ver cada escenario, cuántos ms van a tener, la comunicación entre ellos, etc. Tampoco tiene mucho sentido tener una arquitectura de ms con todos los ms en una misma máquina. Yo no tendría varios ms en un mismo container. La caída de un ms te puede tirar otros, y eso es una de las cosas lo que la arquitectura de ms intenta resolver. Si un ms tiene un error fatal que haga que caiga, nada del resto de tu aplicación se debería ver afectada. Incluso quienes se comunican con el servicio fallido tienen que estar preparados ante estas fallas y actuar acorde, por ejemplo guardar el estado de esa transacción en algún storage y volver a intentar más tarde, o devolver un mensaje al cliente/usuario y que este vuelva a probar más tarde. No puede caer todo tu sistema por la caida de un ms, a diferencia de lo que pasaría con una app monolítica. Espero haber ac;arado un poco. Saludos
Hola Sebas,como va? gran exposición! te hago una consulta.Como o donde podría encontrar info sobre el flujo de datos de mi aplicación? osea,según entiendo,guardo mi front en un container, mi backend en otro container,mi database en otro container etc etc(container === servicios) pero como hago que al apretar un boton,el front me muestre datos que le pido a la base de datos? entiendo que los container tienen puertos que puedo dejar abiertos para interactuar con otros containers,pero específicamente el flujo de los datos en la app como funcionaria,osea,explícitamente,como los conecto en código?
Entre más réplicas levantes , más agilidad tendrás en tus servicios, siendo esté más escalable y distribuyendo las peticiones para que no se sobresature un solo servicio
@@darqkomotovlogs pero como se maneja el concepto de una base de datos centralizada, entiendo que en ese punto no sirve tener varias instancias de base de datos
@@bidcar para base de datos existen varias estrategias, una de ellas son las réplicas maestro esclavo, dónde la maestra es la que escribes y las esclavas son de solo lectura, la maestra réplica la información entre las esclavas, como ejemplo, para microservicios , es oportuno tener cada seccion del dominio dividida en una pequeña instancia de bd, así tienes más atomicidad sobre la información y desacoplamiento
@@darqkomotovlogs muy amable por tu respuesta, investigaré más al respecto para tener más control del tema, cómo desarrollador me preocupa el tema de mantener una base de datos transaccional en este tipo de infraestructura, saludos
@@bidcar el tema de una base de datos transaccional no es complicado , a diferencia de tener una transaccionabilidad en microservicios, si tú servicio a depende del servicio b y el servicio b truena, debería ser capas tu microservicios de , deshacer las operaciones transaccionales del servicio a
quizá no estás muy familiarizado con el argot de esta parte del software o el problema está con algunas de sus frases propias de argentino. Yo tuve duda en la palabra Sandbox o algo así. Si quieres comenta en qué tuviste duda y vemos si te puedo resolver algo. Saludos.
Excelente charla!!!! Muchas gracias!
esta charla es vital para entender el funcionamiento de los microservicios una vez ya has estudiado y entendido todo lo relacionado con ellos. Creo que es la 6ta vez que la escucho, mis dieces.
Super claro, muchas gracias excelente presentación, Saludos desde México
Gracias!! la mejor explicación que he visto.
En resumen es tomar una aplicación que tiene muchas funcionalidades, y dividirla en varias partes y ya, esos son microservicios, adicional a eso cada parte o microservicio puede estar hecha en un lenguaje diferente, ya que funciona de forma independiente, aunque se comunica con los demás microservicios. Cada microservicio es atendido por un equipo, y cada equipo es autónomo, a su vez un equipo puede tener a su cargo uno o más microservicios.
que nivel, muy buena explicación para entender como funciona kubernetes
El manager es un policia. Sutil y genial!
Excelente síntesis!. Muchas gracias.
Excelente presentación me ayudo mucho para implementar una solución en mi trabajo, saludos!!!
Excelente explicación!! Muy clara y didáctica!
Muy buen contenido Sebastian. Muy claro y super divertido
mis respetos que explicación tan barbara.
Muchas gracias por tu excelente presentación !
Muchas gracias por tu video.
Excelente ejemplo, gracias.
Excelente presentación. Congrats!
Muy buen video!! Explicado bien APB! :D
Excelente. Muy claro
Perfecta presentación.
excelente información, ya logré entender mas sobre el tema, me gustaría profesionalizarme en estos temas.
Excelente explicación!
Excelente info! Gracias.
Muy buena exposicion del tema!!
Excelente explicación
Increible ¡¡¡
Excelente Sebastian, segui asi!
En el trabajo se quieren hacer microservicios con spring, pero se tiene la duda de levantar cada microservicio por contenedor. Entonces están seguros que para poder utilizar los microservicios se necesita de un tomcat en cada contenedor ¿Como sería entonces la arquitectura de los microservicios?
Hola Camilo, si los microservicios los implemenntas con contendores, entonces si, cada contenedor contará con el Tomcat. Cada contenedor tiene, por definición, absolutamente todo lo que la aplicación que corre adentro necesita para correr. Soft de base, web server, variables de entorno, etc. Suerte!
@@sebagoomez Con spring el tomcat ya viene embebido. Mi pregunta es ¿todos los microservicios van en un solo contenedor con tomcat configurado? O por el contrario cada microservicio debe ir en un contenedor aparte. En mi trabajo tienen esa duda debido a que si cada ms tiene su propio contenedor, gastaría en demasía los recursos de la máquina.
@@camiloolivo6719 Esa es una decisión de ustedes. Hay que ver cada escenario, cuántos ms van a tener, la comunicación entre ellos, etc. Tampoco tiene mucho sentido tener una arquitectura de ms con todos los ms en una misma máquina. Yo no tendría varios ms en un mismo container. La caída de un ms te puede tirar otros, y eso es una de las cosas lo que la arquitectura de ms intenta resolver. Si un ms tiene un error fatal que haga que caiga, nada del resto de tu aplicación se debería ver afectada. Incluso quienes se comunican con el servicio fallido tienen que estar preparados ante estas fallas y actuar acorde, por ejemplo guardar el estado de esa transacción en algún storage y volver a intentar más tarde, o devolver un mensaje al cliente/usuario y que este vuelva a probar más tarde. No puede caer todo tu sistema por la caida de un ms, a diferencia de lo que pasaría con una app monolítica. Espero haber ac;arado un poco. Saludos
@@sebagoomez Muchas gracias, si aclaró muchas de mis dudas. Un saludo
Excelente video, súper claro, como se llama la herramienta de netflix para el monitoreo de los requests?
Hola Sebas,como va? gran exposición! te hago una consulta.Como o donde podría encontrar info sobre el flujo de datos de mi aplicación? osea,según entiendo,guardo mi front en un container, mi backend en otro container,mi database en otro container etc etc(container === servicios) pero como hago que al apretar un boton,el front me muestre datos que le pido a la base de datos? entiendo que los container tienen puertos que puedo dejar abiertos para interactuar con otros containers,pero específicamente el flujo de los datos en la app como funcionaria,osea,explícitamente,como los conecto en código?
Como hago. Para ver en web los datos de mi clúster?
Muy didactico, gracias
Buena presentacio
Entre más réplicas le coloque, es más rápido?
Entre más réplicas levantes , más agilidad tendrás en tus servicios, siendo esté más escalable y distribuyendo las peticiones para que no se sobresature un solo servicio
@@darqkomotovlogs pero como se maneja el concepto de una base de datos centralizada, entiendo que en ese punto no sirve tener varias instancias de base de datos
@@bidcar para base de datos existen varias estrategias, una de ellas son las réplicas maestro esclavo, dónde la maestra es la que escribes y las esclavas son de solo lectura, la maestra réplica la información entre las esclavas, como ejemplo, para microservicios , es oportuno tener cada seccion del dominio dividida en una pequeña instancia de bd, así tienes más atomicidad sobre la información y desacoplamiento
@@darqkomotovlogs muy amable por tu respuesta, investigaré más al respecto para tener más control del tema, cómo desarrollador me preocupa el tema de mantener una base de datos transaccional en este tipo de infraestructura, saludos
@@bidcar el tema de una base de datos transaccional no es complicado , a diferencia de tener una transaccionabilidad en microservicios, si tú servicio a depende del servicio b y el servicio b truena, debería ser capas tu microservicios de , deshacer las operaciones transaccionales del servicio a
stop cuando escuche genexus
🤟👉
Una charla muy interesante, me.ayudo a complementar lo que sabía ua-cam.com/video/N95W6I_DoRs/v-deo.html
Saludos y seguiré viendo el bueno contenido.
es bastante útil la explicación pero mete mucho ruido semántico y aveces no entendía a que se referia
quizá no estás muy familiarizado con el argot de esta parte del software o el problema está con algunas de sus frases propias de argentino. Yo tuve duda en la palabra Sandbox o algo así. Si quieres comenta en qué tuviste duda y vemos si te puedo resolver algo. Saludos.
horrible
Un desarrollador usando Windows... No lo sé
@Federico Noriega Martin mas bien creo que es un pendejo y no lo sabe.