Te felicito por tu claridad en la explicación; hice un sistema en PHP hace 7 años para un par de pymes y realmente me resulta hoy dia dificilisimo de agregarle funcionalidad y escalarselos; estoy aprendiendo lentamente el paso a los microservicios y la nube con Docker, tu introducción me vino perfecto para iniciar el estudio del patrón de microservicios y como terminan implementandolo para reemplazar mi vetusto LAMP en un par de intranets.👌
Alguien me corrige porfa. Creo que los microservicios no necesariamente deben de tener una base de datos aislada. Es decir los servicios si van distribuidos en varios servers pero la bd puede ser la misma en común para ambos si no se tendría que meter más ingeniería como replica de bd en cada llamado del servicio.
Algo que yo no entiendo de los microservicios es que una de las ventajas con la que los presentan es la capacidad de intercambiarlos de manera dinámica en caso de fallas... pero lo que yo no entiendo es: si el Servicio de Productos tiene un error, entonces con qué lo vas a intercambiar? si se supone que esa version tiene un bug, no importa que reinicies la pc o el servicio en otro servidor, el bug sigue ahí en tu código... o levantas el servicio en una version que no tenga el bug? pero si esa API es vieja, puede que no ofrezca todas las llamadas que otros servicios necesitan... entonces terminas dañando más cosas de las que quieres solucionar... o implementas para cada Servicio un "Fallback" con funciones limitadas? podría funcionar, pero incrementas el tiempo de desarrollo y mantenimiento y pierdes lógica de negocio por lo limitado que tendría que ser... con la probabilidad de dañar otros clientes que usan procesos que sí sirven en la versión con el bug... Por eso veo los microservicios como algo "over engineered" para desarrollar tu app. Para mí tienen lugar en la integración de diferentes aplicaciones con APIs estrictamente definidas... pero para applicaciones desarrolladas por un único equipo/desarrollador, es como matar a una hormiga con un tanque...
Entiendo por teoria y experiencia laboral, encontré MICRO SERVICIOS con una sola base de datos SQL SERVER..., mi duda es necesario una base de datos por cada microservicios ?
Dependen de los recursos disponibles y el tamaño del proyecto. Además de que puedes tener acceso a servicios externos, donde podrás consumir solo las funcionalidades que tiene definidas, pero la base de datos la administra el dueño de ese servicio.
entonces podría decir que un microservicio es una funcionalidad de un sistema expuesto a través de un end-point, basado en la arquitectura RESTFULL? en el que no importa la tecnología en la que se expone dicho servicio, solo importa que se pueda acceder a este y a los recursos que maneja?
man que diferencia hay con una api? los servicios se manejan diferente o igual? usando diferente tecnologias para desarrollar estos servicios es quien maneja las sesiones?? como se hacen
un microservicio es un "api" fragmentado en pequeñas "apis" que realizan una función especifica. Por ejemplo un api solo para servicios de compras, ventas, logistica, etc... Imagina que un api convencional es un rompecabeza armado y el microservicio es un fragmento del rompecabezas... Asi de sencillo
si esa aplicacion tiene todas las funcionalidades necesarias, y no necesita comunicar con otra instancia o aplicacion para alguna funcionalidad, se podria considerar como aplicacion monolitica.
En ese caso, sobre todo siendo una aplicacion spring boot, seria monolitica, ya que spring creo otra tecnologia (spring cloud) especificamente para facilitar la creacion de una arquitectura de microsrevicios. En dicha arquitectura, varias aplicaciones spring-boot son conectadas y se comunican entre ellas con la ayuda de spring cloud y netflix oss. si te quedan mas preguntas no dudes en decirmelo!
Excelente la respuesta que te dieron! Si querés una regla simple para saber si tenes una arquitectura monolítica o distribuida, pensá en como haces despliegues: si tu aplicación es un solo artefacto que reemplaza el actual, y a lo sumo tenes réplicas del mismo artefacto, es una aplicación monolítica. Una aplicación distribuida tiene componentes que se despliegan independientemente y dependen entre sí en ejecución, no en compilación.
Hola Ramiro, básicamente las ventajas de microservicios sobre desarrollo modular al ser los microservicios unidades independientes son: 1) Se ejecutan y despliegan independientes, por lo que puedes escalar uno si y otros no en dependencia de la demanda, por ej: Una shop que tiene un modulo de pagos y otro de stock, puede ser que mucha gente este accediendo al stock, pero no a hacer pagos, en ese caso el microservicio de stock puede escalar independiente brindando mejor calidad de servicio, otra ventaja es la posibilidad de tener equipos pequeños dedicados, la testeabilidad independiente es otra ventaja y por ultimo la posibilidad de usar tecnologías diferentes, por ej: si vas a desarrollar en esa shop un "modulo de reconocimiento de productos", capaz Python sea lo mejor, pero para el stock Java lo hace mejor, es solo un ejemplo para ilustrarte. Esa es la ventaja que tiene MS sobre módulos. Si quieres aprender más puedes visitar nuestro blog sacavix.com. Saludos !
yo en particular detesto esta arquitectura ya que realizar pruebas me esta siendo muy complicado y tardo muchisimo tiempo, no me siento nada productivo trabajando con ella, pero es la moda y es lo que viene lamentablemente XD
(Yo sentí lo mismo que tu) El problema es que estamos acostumbrados a ver a docentes formales gracias a la universidad, pero vender ese estereotipo de programador greñudo, desalineado, etc. solo pasa en las series y películas. y sin desmerecer de la capacidad que tenga el man del vídeo "que no lo dudo", pero admitamos que no da confianza de seriedad y sabiduría en la primera impresión, pienso que debe haber un punto medio entre la informalidad y la formalidad, mas aun cuando debes llevar una imagen tuya para vender. Yo también soy programador y jamas he vendido esa apariencia por que la imagen dice mucho de una persona independiente de la profesión que tengamos.
@@jvargas1379 En el oficio lo que menos importa es la apariencia. Lo importante son los conocimientos, estoy seguro que Freddy Vega no permitiría que alguien sin las capacidades necesarias pasara a ser parte de platzi.
Te felicito por tu claridad en la explicación; hice un sistema en PHP hace 7 años para un par de pymes y realmente me resulta hoy dia dificilisimo de agregarle funcionalidad y escalarselos; estoy aprendiendo lentamente el paso a los microservicios y la nube con Docker, tu introducción me vino perfecto para iniciar el estudio del patrón de microservicios y como terminan implementandolo para reemplazar mi vetusto LAMP en un par de intranets.👌
Exelente explicación 👌
Muy buena explicacion
Wow!! Me has sacado de una gran duda. Por el momento me voy por el monolítico!! Muchas gracias!
Guido es un gran profesor actualmente.
el mejor profesor de platzi
Magnífica explicación
Amigo, chevere tu video, tomaré este fin de semana el curso.
Alguien me corrige porfa. Creo que los microservicios no necesariamente deben de tener una base de datos aislada. Es decir los servicios si van distribuidos en varios servers pero la bd puede ser la misma en común para ambos si no se tendría que meter más ingeniería como replica de bd en cada llamado del servicio.
esa es justamente la chamba. Coherencia y persistencia de los Datos
Algo que yo no entiendo de los microservicios es que una de las ventajas con la que los presentan es la capacidad de intercambiarlos de manera dinámica en caso de fallas... pero lo que yo no entiendo es:
si el Servicio de Productos tiene un error, entonces con qué lo vas a intercambiar? si se supone que esa version tiene un bug, no importa que reinicies la pc o el servicio en otro servidor, el bug sigue ahí en tu código...
o levantas el servicio en una version que no tenga el bug? pero si esa API es vieja, puede que no ofrezca todas las llamadas que otros servicios necesitan... entonces terminas dañando más cosas de las que quieres solucionar...
o implementas para cada Servicio un "Fallback" con funciones limitadas? podría funcionar, pero incrementas el tiempo de desarrollo y mantenimiento y pierdes lógica de negocio por lo limitado que tendría que ser... con la probabilidad de dañar otros clientes que usan procesos que sí sirven en la versión con el bug...
Por eso veo los microservicios como algo "over engineered" para desarrollar tu app. Para mí tienen lugar en la integración de diferentes aplicaciones con APIs estrictamente definidas... pero para applicaciones desarrolladas por un único equipo/desarrollador, es como matar a una hormiga con un tanque...
Entiendo por teoria y experiencia laboral, encontré MICRO SERVICIOS con una sola base de datos SQL SERVER..., mi duda es necesario una base de datos por cada microservicios ?
Dependen de los recursos disponibles y el tamaño del proyecto. Además de que puedes tener acceso a servicios externos, donde podrás consumir solo las funcionalidades que tiene definidas, pero la base de datos la administra el dueño de ese servicio.
Y react en si no esta echo para eso?
entonces podría decir que un microservicio es una funcionalidad de un sistema expuesto a través de un end-point, basado en la arquitectura RESTFULL? en el que no importa la tecnología en la que se expone dicho servicio, solo importa que se pueda acceder a este y a los recursos que maneja?
Así es.
Tienes algún curso de microservicios en Platzy? y si es asi en que lenguaje de desarrollo esta?
jajajajjajaa su cara al final :v
hide the pain harold
JAJAJAJJAJA
genial explicado, mis diesels
Gracias
voy a consumir este video de un contreras a otro
man que diferencia hay con una api? los servicios se manejan diferente o igual? usando diferente tecnologias para desarrollar estos servicios es quien maneja las sesiones?? como se hacen
un microservicio es un "api" fragmentado en pequeñas "apis" que realizan una función especifica. Por ejemplo un api solo para servicios de compras, ventas, logistica, etc... Imagina que un api convencional es un rompecabeza armado y el microservicio es un fragmento del rompecabezas... Asi de sencillo
Haste uno de saga patterns
Si hay una solo instancia de una aplicación con spring boot con una base de datos, se considera aplicación monolítica?
si esa aplicacion tiene todas las funcionalidades necesarias, y no necesita comunicar con otra instancia o aplicacion para alguna funcionalidad, se podria considerar como aplicacion monolitica.
Solo se comunica con el frontend a través de los REST services.
En ese caso, sobre todo siendo una aplicacion spring boot, seria monolitica, ya que spring creo otra tecnologia (spring cloud) especificamente para facilitar la creacion de una arquitectura de microsrevicios. En dicha arquitectura, varias aplicaciones spring-boot son conectadas y se comunican entre ellas con la ayuda de spring cloud y netflix oss. si te quedan mas preguntas no dudes en decirmelo!
Entiendo gracias por la aclaración.
Excelente la respuesta que te dieron! Si querés una regla simple para saber si tenes una arquitectura monolítica o distribuida, pensá en como haces despliegues: si tu aplicación es un solo artefacto que reemplaza el actual, y a lo sumo tenes réplicas del mismo artefacto, es una aplicación monolítica. Una aplicación distribuida tiene componentes que se despliegan independientemente y dependen entre sí en ejecución, no en compilación.
Pregunta* cuál es la diferencia del desarrollo hecho por módulos?
Hola Ramiro, básicamente las ventajas de microservicios sobre desarrollo modular al ser los microservicios unidades independientes son: 1) Se ejecutan y despliegan independientes, por lo que puedes escalar uno si y otros no en dependencia de la demanda, por ej: Una shop que tiene un modulo de pagos y otro de stock, puede ser que mucha gente este accediendo al stock, pero no a hacer pagos, en ese caso el microservicio de stock puede escalar independiente brindando mejor calidad de servicio, otra ventaja es la posibilidad de tener equipos pequeños dedicados, la testeabilidad independiente es otra ventaja y por ultimo la posibilidad de usar tecnologías diferentes, por ej: si vas a desarrollar en esa shop un "modulo de reconocimiento de productos", capaz Python sea lo mejor, pero para el stock Java lo hace mejor, es solo un ejemplo para ilustrarte. Esa es la ventaja que tiene MS sobre módulos. Si quieres aprender más puedes visitar nuestro blog sacavix.com. Saludos !
Que hay de SOA? Lleva años en la industria y ahora todo el tema de los microservicios pareciera ser un capítulo extraido de la teoría de SOA, es así?
JAJA! que atorrantes con Guido al final!! el pobre no sabe como actuar. Pero lo de profesional eso si se respecta!!! vamo macho!!
AHhaha me dio mucha risa eso también.
yo en particular detesto esta arquitectura ya que realizar pruebas me esta siendo muy complicado y tardo muchisimo tiempo, no me siento nada productivo trabajando con ella, pero es la moda y es lo que viene lamentablemente XD
WTF CON EL FINAL AJJAJAJAJAJAJAJA
Eso no es programación orientada a objetos?
dentro del desarrollo de cada uno de los microservicios se implementan patrones como el de POO
Primer comentario
react xD
me perdonan pero es una lastima que platzi no tenga profesores.. no cualquiera es profesor GRAN ERROR
(Yo sentí lo mismo que tu) El problema es que estamos acostumbrados a ver a docentes formales gracias a la universidad, pero vender ese estereotipo de programador greñudo, desalineado, etc. solo pasa en las series y películas. y sin desmerecer de la capacidad que tenga el man del vídeo "que no lo dudo", pero admitamos que no da confianza de seriedad y sabiduría en la primera impresión, pienso que debe haber un punto medio entre la informalidad y la formalidad, mas aun cuando debes llevar una imagen tuya para vender. Yo también soy programador y jamas he vendido esa apariencia por que la imagen dice mucho de una persona independiente de la profesión que tengamos.
@@jvargas1379 En el oficio lo que menos importa es la apariencia. Lo importante son los conocimientos, estoy seguro que Freddy Vega no permitiría que alguien sin las capacidades necesarias pasara a ser parte de platzi.
tu argumento está incompleto, puedes sustentarlo?
@@jvargas1379 a mi me parece que el "mechudo" explicó bien el tema lo entendí a la perfección era lo que estaba buscando
no me jodas ¿al menos tomaste el curso? Woda es un excelente profesor, el tipo sabe muchisimo.