¿De verdad son necesarios los microservicios?
Вставка
- Опубліковано 25 гру 2023
- Veamos que está pasando con los microservicios. ¿Es necesario extender la arquitectura de microservicios hasta donde está llegando? ¿Deberíamos volver a arquitecturas monolíticas? Sobre estas y algunas preguntas más vamos a hablar en este video.
Si quieres tener un gran hosting para tu web con servicio en España 24/7 y con centro de datos en España aquí te dejo una gran recomendación, la empresa Loading, además, no olvides usar el código 10%ANTONIOPEREZ para conseguir un 10% de descuento al contratar con ellos!
www.loading.es/clientes/aff.p...
Si queréis ampliar la información de este video he publicado otro en el que comento algunas alternativas de arquitectura de proyectos, así como algunos consejos para elegir la arquitectura:
• Alternativas a los mic...
Vídeo en el que hablo de crear apps con IA que menciono en el video:
¿Quieres programar apps con IA?
• ¿Sabes como añadir Int... - Наука та технологія
no creo que el problema sea si es monolítico u orientado a servicios, creo que el tema es de como organizar una arquitectura de soluciones
Excelente video! coincido plenamente! Trabajo como programador desde 2004 y en los ultimos años solo programo mis propias apps. Vi tanto caos, en los equipos que integre, que decidi vivir unicamente de mis propias fuentes de ingresos. No solo el problema esta en el exceso de microservicios sino en el exceso de herramientas a usar y mil formas intrincadas de producir que lo unico que hacen es disminuir el tiempo productivo y la capacidad de dar respuestas eficientes.
Hice de todo para optimizar mi forma de desarrollo.. desde crear mi ORM hasta mi propio framework con un lenguaje basado en XML. Siempre escuche el tipico consejo de reinventar la rueda es malo, pero hoy en dia mi productividad es mucho mas alta gracias a eso.
¡Al fin alguien serio por Dios que dice las cosas como son! Pensé que era el único, jaja... Puro marketing de software. Hoy en día, las empresas usan lo que está de moda, ni se preguntan si realmente en su contexto aplica. Y sí, tal cual, me ha tocado ver aplicaciones que son un simple CRUD y un login con 4 y 5 microservicios xD...
Hay varias cosillas que hay que señalar. Una arquitectura de microservicios tiene un propósito. La escalabilidad. Si en vuestros desarrollos no os encontráis con problemas de escalado o de aumento exponencial de los recursos que necesita un monolito para dar servicio a más y más usuarios entonces es que no se hicieron los deberes. La escalabilidad de un servicio de "tres o cuatro" pantallas, por ejemplo, porq es el servicio más demandado, es muucho más barato que escalar N funcionalidades que no demandan tantos recursos, pero al estar en monolito tienes que escalar el conjunto. Tarea que en cloud se vuelve imposible de asumir por ejemplo.
Los equipos y la forma de gestión no es culpa de los microservicios. Un equipo "agile" es un equipo capaz de enfrentar de manera casi autónoma mucha incertidumbre en la definición de vuestro desarrollo. Si en vuestro caso no se tiene este componente de "incertidumbre" se puede usar waterfall. De hecho antes del Hipe* este del agile y de que salieran scrum masters de cursillo express era un sistema residual.
Digo todo esto porq el problema no es la metodología o el coste del equipo (están contratando ingenieros y gente muy especializada, si no se tiene dinero hay que dedicarse a otra cosa). El problema es la injerencia. En todos los proyectos, y digo todos. La capa de gestión se extralimita en sus funciones y no deja funcionar bien al equipo técnico tomando decisiones que no son las correctas o moviéndose por modas con el único propósito de hacer más atractivo el producto o el servicio. Hablar de costes de equipos en Agile y decir que son caros cuando a todas luces se están tomando decisiones no fundamentadas y ni hablar del ROI esperado del desarrollo es hacernos trampas al solitario y al que tenemos delante. Preguntémosle a Space X cuanto le sale el equipo de ingenieros que están con el Falcon Heavy, o con cualquier otro... Nos comentarán cifras acoj**, ahora bien, ¿ porq lo hacen ?. El ROI que esperan es muchísimo mayor. Podría seguir pero sinceramente ... creo que queda más o menos claro lo que quiero decir.
Muy interesante tu enfoque, gracias por el video.
El surgimiento de Docker y la tecnología de containers fue decisiva para el nacimiento de los microservicios; marcó un punto de inflexión, simplificando la división de aplicaciones en contenedores y facilitando los despliegues. Recuerdas cuando había que configurar una VM o aprovisionarla para desplegar nuevo la app, la DB, etc...
Los microservicios surgen como una forma de bajar el acoplamiento: cuando los desarrolladores toman cualquier decisión en un monolito logrando que el código sea una gigante bola inmantenible, los costos de cualquier cambio, o de un nuevo feature, empiezan a subir.
La clave de usar microservicios es que sean independientemente desplegables y reducir el acoplamiento todo lo posible. Microservicios bien usados permiten bajar el time-to-market ya que una nueva funcionalidad en un nuevo microservicio no se mete (en gral) en el resto del código de la app.
Muchas veces esto no se logra, se termina creando un monolito distribuido y las ineficiencias y costos se van a las nubes, como bien señalas.
Creo que es clave lograr un equilibrio en un punto medio. Considerar trabajar en múltiples repos Git y muy estricto versionado y gestión de depencias, que luego se pueden ensamblar en pocos servicios.
No es necesario implementar microservicios para hacer aplicaciones modulares.
Coincido en que los skills fullstack serán más valorados al igual que los devs que se esfuercen por encontrar soluciones eficientes.
Ej: hoy Vercel permite montar apps con SSR programando sólo Typescript en front+back, con backend services, integración y despliegue continuos directo desde Github, una maravilla.
También RoR como mencionas, es enormemente productivo.
HTMX también es muy interesante. En mi caso estoy experimentando este stack: Go, HTMX, TailwindCSS+DaisyUI, AlpineJS. Resultado: una imagen docker de 10 MB con una aplicación completa y tremendamente performante gracias a Go.
Muchas gracias! Se nota que llevas algún que otro año peleando con arquitecturas, un saludo!
Yo no tengo experiencia en microservicios, pero en el proyecto de mi empresa (que por ahora llevo yo solo), tengo muy claro que cuando se haga alguna separación de algún módulo o bounded context, los beneficios tienen que superar a los inconvenientes. Además de que intentaré de que ese servicio que se cree sea lo suficientemente independiente como para que la interacción con el resto del proyecto sea mínima.
Yo creo que el problema es que cuando piensas en microservicios, tienes la sensación de que es una buenísima idea para cualquier situación. Lo ves perfecto porque dices "mira, proyectos pequeños independientes, todo más controlado". Pero luego, te paras a pensar en los problemas de verdad, como la comunicación entre ellos o la infraestructura que tienes que montar... y te das cuenta que es un problemón incluso para las cosas más simples.
Tiene su mercado, por supuesto, pero es lo que tú dices, nos hemos pasado tres pueblos y ahora estamos sufriendo las consecuencias de no pararnos a ponerlo en una balanza a ver si compensa o no.
soy devops y me he encontrado con mucha sobreingenieria en muchos proyectos, muchas veces se toma libro de microservicios y se intenta aplicar todo y se terminan complicando demasiado.. saludos antonio que vuelvan los podscast de full stack
Qué es devops? Llevo 12 años en el sector y cada mes sale un término nuevo del que cada uno tiene su propia definición. Me interesa tu opinión, porque tuvimos un debate en mi trabajo sobre esto y llegamos a la conclusión de que también es humo.
amigo yo quiero estudiar eso, que ruta puedo seguir?
@@jymmy8312 A vuelo de pájaro, se encargan de la integración continua y el despliegue continuo.
@@oarangov mi pregunta era irónica. Quería decir que son términos volátiles, puro marketing para vender más cursos y títulos inútiles. La integración continua es algo intrínseco al desarrollo de software, tan común y vital como compilar.
@@jymmy8312 El DevOps más allá de una ejecución de unos pipelines, y así es cómo lo venden, pero no, ellos son una especia de evolución de los infra, se encargan de montar y mantener la estructura, disponibilizar recursos y etc.
Llevo 17 años programando, y lo que ocurre es que al plantear un proyecto la gente crea infraestructura como una empresa de éxito, es decir, crear infraestructura como si fuera a recibir millones de solicitudes por minuto, y a menudo ves que ni se acercan a sacar partido de lo planificado. En la vida real, los microservicios no dejan de ser dividir una app, pero una cosa es dividir algunas funcionalidades importantes y otra es que una app sean ciento y pico servicios que a veces son mini funcionalidades. Así le va a las empresas.
No puedo estar mas de acuerdo con tu comentario
Exacto, separar en exceso la aplicación no tiene sentido, si vas aumentar la complejidad del proyecto es por que en realidad es necesario y traera más beneficios que problemas
Monolito con modulos es casi igual que microservicios. Lo mismo que usted comenta tambien Robert C. Martin lo ha comentado en su libro Clean architecture, osea una pantalla o un pequeño cambio e una tabla de base de datos, empieza a involicrar muchos micros servicios y mucha gente y se vuelve mas dependiente
Me ha tocado dirigir equipos de alrededor de 100 desarrolladores y ser quien dicte las reglas de como DEBERÍAN SER los microservicios en algunas ocasiones… creo que tienes mucha razón pero la realidad es que me parece qué hay que sepáralo en sus bemoles:
1) El desarrollo móvil lleva años en decadencia
2) hoy tenemos alternativas que antes no teníamos (k8s, WASM, Docker, etc.)
3) Hay un frenesí por pasarse al lenguaje nuevo vs seguir trabajando en el lenguaje de turno
4) Realmente muy pocas personas trabajamos antes de usar microservicios y entendemos que le DUELEN a los monolitos
5) Poco a poco está arquitectura empieza a tocar al front end (micro-front, SSR, etc)
6) Muchos desarrollos son microservicios para adaptarse al proceso establecido (pipelines, plantillas, etc)
7) el tema de practicidad vs costos
Sin fin, me gustaría poder debatir algunos puntos contigo 😅
Gracias por el comentario, veo que llevas algún tiempo peleándote con proyectos, oye, podría estar bien ese debate!
Me da curiosidad saber cómo se necesitan tantos desarrolladores en una sola área, en mi empresa manejamos una súper app, una web muy robusta, y somos muy pocos dev en verdad, hace poco colaboramos con otra área para agregar una feature en flutter de una súper app nativa y la empresa service trajo 6 squads de 6 devs cada uno, para un trabajo sencillo, que en realidad lo podíamos hacer 2 devs.
@@aulavirtualjyl9578 Pues diría que si realmente hacen las cosas bien y no pasan más de máximo 60 horas a la semana y hacen todo escalable ... Yo diría que sois unos pros y tienen todo mi respeto
A que te refieres con desarrollo movil en decadencia?
@@rubensanchez6954 Me gustaría saber también a que se refiere XD
Buen video amigo, yo no tengo mucha experiencia, hace casi 3 años que comencé a trabajar.. pero estoy a cargo de un equipo y me tocó diseñar un servicio y la mejor decisión fue hacer un monolito modular, aislando lo mejor posible cada módulo.. y si en el futuro se necesita, se puede transformar fácilmente esos módulos en microservicios
No soy muy experto, quisiera entender mejor, es decir que no desagrego tanto las funcionalidades y se desearon unos servicios más completos que más adelante igualmente se pueden deshacer en varios servicios más pequeños e independientes?
Eso es MUY peligroso. No es tan fácil pasar un módulo que usa el resto de la plataforma como librería (si está bien hecho) sin tener nociones de patrones de diseño como proxies, fachadas, etc. Lo cierto es que es muy importante que una persona que tome estas decisiones sea una persona con mucha experiencia. Lo digo porque si te hubieras enfrentado a una refactorización de ese nivel, verías que una cosa es separación lógica y otra separación funcional, y y que en el desarrollo de años eso se puede perder y lo vuelve un infierno carísimo de resolver
@@lordexess ¿Como que no? Si está bien desarrollado y separado, el modelo irá por un lado, y la lógica por otra (Vamos, en modulos independientes). Si creas un micro solo tendrá sentido si es de la lógica, no del modelo, por lo que es tan sencillo como crear un micro que como dependencia tenga dicho modulo que contiene la lógica. Ya lo tienes, el modulo de la lógica tiene un paralelo que es un micro, pero a la vez sigues manteniendo la versión que es una librería, de modo que el resto de proyectos pueden ir migrando de a poco de usar la librería a usar el micro. Cuando todos hayan migrado para usar el micro, podrás mover definitivamente el código de la librería en el propio micro (Si quieres, por mí lo mantenía separado).
Yo ya tengo varios proyectos "core" que funcionan así, con multiples interfaces de entrada posibles (versión microservicio, versión cli, versión librería autoconfigurable con spring... cada versión en su propio proyecto separado, pero todos con la misma librería core que contiene la lógica de negocio). O lo mismo es que no estoy entendiendo la dificultad que quieres señalar 😅
@@javiergavilanmerida2133 son cosas diferentes. El modelo y la lógica es independiente del patrón, sea mvc o un rest normal. Los micros son de la lógica de negocio. Recomiendo mucho leer sobre este patrón en el libro de arquitecturas limpias
@@lordexess Siento discrepar, pero los micros son de la capa de infrastructura (en hexagonal) o interface adapters (clean architecture), y son los que hacen uso de las clases de la capa de dominio/aplicación (hexagonal) o negocio (clean). Así es como mantienes la lógica de negocio separada de frameworks y librerías externos, lo cual te permite hacer cosas como las que explico que yo mismo tengo hechas. En mi caso los controller (con los endpoints) de los micros funcionan con springboot, y los del cli con picocli. La librería autoconfigurable son simples components en lugar de controllers con endpoints, pero al final es terriblemente similar a los micros. Además tengo la gracia de que la implementación de los repository (que también son de la capa de de infrastructura/interface adapters) también los tengo separados, pudiendo usar nosql, jpa, jdbc, o ficheros csv si te apetece. De hecho, en algún proyecto lo tengo hasta separado por agregado (Yo y mis experimentos con DDD).
Si, es importante leer sobre arquitecturas límpias, pero más importante aún es juguetear con ellas para realmente entender el como, el por qué, y el cuando de su uso 😜
PD: Se de varias fuentes que dicen lo que tú, pero nada más piensas un poco sobre el objetivo de las arquitecturas limpias te puedes dar cuenta de que no tiene sentido. Las arquitecturas limpias se basan mucho en principios como los de SOLID, siendo su objetivo primordial el mantener bajo el acoplamiento para que el código sea mantenible. Y si integras detalles de infraestructura (como que la aplicación realice su trabajo a través de micros) en el negocio, tu código va a estar fuertemente acoplado a ese detalle de implementación que no tiene nada que ver con el problema real que se busca resolver.
PD2: OJO, que si tu aplicación es una utilidad para trabajar con un framework concreto, el uso de dicho framework pasa a formar parte de las reglas de negocio. Son el resto de librerías y frameworks que utilices los que se quedarán en capas exteriores. Digamos que es uno de los casos excepcionales donde se puede usar recursos externos en las capas interiores.
CURIOSIDAD: En algún lado he leído la historia de que clean architecture es una "implementación"/"evolución" de hexagonal. No se si esto es realmente cierto, pero si que es verdad que entendiendo la arquitectura hexagonal, vas a entender la clean architecture más fácilmente.
La gente que no entiende microservicios los implementa mal, en lugar de solucionar problemas crea nuevos, por eso muchos terminan odiandolo. No es para todos, si no los entiendes no los utilices.
pero danos un ejemplo de a qué te refieres. sino es un comentario que dice nada
@@visitor404también espero su "aporte" y ver qué entiende el que no entendió el creador del vídeo.... porque en el vídeo se retrata que para ciertos proyectos el presupuesto se puede terminar mal utilizando, es decir lo mismo de toda la vida, que no se trata usar una tecnología solo porque está de moda o parece que es lo mejor si no analizar , pensar fuera de la caja y quizás elegir otras conveniencias de acuerdo a cada realidad y buscando una eficiencia del presupuesto y durante el el ciclo de vida de la aplicacion.
Es lo mismo que con un monolito si no lo entiendes no los uses 😂
lo q dice esta muy claro, los mocroservicios aumentan el coste de produccion x10 . en equipos pequeños sin tanto presupuesto hay q andar con pies d plomo al implementatlos
@@jesuseduardonivialatorre4722 pero a diferencia es que la idea de microservicios es subdividir los servicios en varios proyectos para que se concentre a crear proyectos en focados en servicios. El monolito es bueno cuando el proyecto no es tan extenso.
Excelente reflexión. En mi día a día me consigo con este tema cuando estoy haciendo diseño de aplicaciones. Es importante no hacer sobre ingeniería y tratar de mantenerlo simple; no siempre es simple conseguir el equilibrio pero es parte del desafío. Gracias por el video.
Muchas empresas comenzaron a utilizar microservicios por subirse al hype, sin entender que la idea de los microservicios es que distintas secciones del negocio puedan crecer y caerse sin afectar a otras, en su lugar solo separaron la lógica en distintos servicios, pero todos dependen entre todos, haciendo inútil la separación, gastando más en infra y complicando el mantenimiento
Rappi tenia más de 1800 Servicios hace 2 años, según la entrevista del Pelado Nerd al equipo de Rappi, ahora deberá tener más de 2000 🥲
Buen canal, esperemos crezca y puedas subir contenido mas seguido! un abrazo, sigo viendo el video, excelente tema
Lindo video, realmente es importante conocer que soluciona la arquitectura de microservicios. Hay un principio que creo que todo proyecto nuevo debe aplicar que es el "Monolith First" y luego con las metricas que se obtengan ver que parte del sistema se pueden separar para tener una escalabilidad eficiente. Si aplicamos los principios SOLID facilita mucho extraer ese fragmento del sistema que requiera ser separado en microservicios.
El mantenimiento del codigo ya pasa a ser parte de la practica del Clean Code y implementacion de test automatizados por sobre todo.
Me ha encantado lo de monolith first, te lo compro!
En donde trabajaba antes teníamos eso de hacer un monolito solo para backend y conforme salieran necesidades lo dividiamos en distintas apis o jobs, eso sí el frontend iba aparte, atendiamos muchos clientes de los más grandes del pais y vaya como avanzábamos rápido ya que hay tenia autoridad y siempre proponía que todo se hiciera lo más simple posible, después deje esa empresa porque me doblaron sueldo en una startup fintech donde se usan microservicios para todo y solo son simples cruds y vaya lío para cosas muy simples se lleva mucho tiempo 😅
Después de oír tu disertación (en la ducha esta mañana), me ha recordado los tiempos en que hice código (2003). Lo más difícil de un proyecto (en general, no necesariamente de software) es gestionarlo. Cuanto más "piezas" lo compongan más difícil es dimensionarlas, gestionarlas, certificarlas y mantenerlas. Si quieres mantener tus costes controlados en un proyecto con muchas piezas, estén redactadas como microservicios o formando parte de código HTML es necesario modularizar y estandarizar; es lógico por tanto que tengas tanta gente gestionando el proyecto como gente redactando código mas los problemas de ralentización cuando alguien se vá (de cualquier lado, gestión o redacción). Al escucharte ensalzar las comunicaciones directas en HTML vs microservicios, pienso que no es por ahí por donde venga la solución, porque el problema persistirá, si no tienes estandarizadas y modularizadas las rutinas operativas de construcción, gestión, certificación y mantenimiento del software.
Hablando de estandarizar y modularizar, recuerdo un evento en la Secretaría de Estado de Telecomunicaciones, en la que un conferenciante de IBM se refería a las etiquetas RFID en la que decía que si habían tardado cerca de 10 años para llegar a un estandar industrial, no quería ni pensar lo que llevaría llegar a un estándar industrial sobre IoT.
Quizá lo que ayudaría en el caso del software sería el desarrollo de IA en el apartado de asistencia a la gestión del software, es decir, la asistencia a aquellos que han de gestionar los proyectos, ya sabemos que puede ayudar mucho al testeo. Por otro lado crear procedimientos y marcos de trabajo estándar llevan mucho tiempo, mucho más que el plazo de un proyecto, ¿quien financia esto? y lo que es más difícil aún, ¿quien cuida y lo proteje de otros que consideran este trabajo inútil y devorador de recursos dentro de la empresa?, solo una dirección profesionalizada puede hacerlo y defenderlo, y eso ocurre en muy raras ocasiones.
Totalmente de acuerdo contigo. No todas las soluciones necesitan ser abordadas con microservicios. Su implementación puede añadir complejidad, aumentar costos y abrir brechas de seguridad. Pero lo que veo aquí es más un caso de mala implementación que de problemas inherentes a los microservicios.
En lugar de lanzarse directamente a crear microservicios, creo que un enfoque más gradual con servicios SOA podría ser la clave. Estos no son tan pequeños como los microservicios, pero ofrecen un buen punto intermedio para desacoplar servicios de manera más controlada. Mantenerse fiel a los estándares y patrones establecidos es esencial para minimizar los riesgos.
Y sobre el tema de Ruby on Rails y los SSR, hay bastante controversia, pero creo que es importante reconocer que hay muchas soluciones alternativas disponibles en la actualidad. Desde frameworks de frontend avanzados hasta plataformas de bajo código y servicios en la nube, hay muchas opciones para elegir. Es cuestión de encontrar la que mejor se adapte a las necesidades específicas de cada proyecto.
En resumen, estoy de acuerdo contigo en que la implementación de microservicios puede ser compleja, pero creo que con el enfoque adecuado y la selección de herramientas correcta, se pueden minimizar los riesgos y maximizar los beneficios.
Tiene razon, mientras mas fragmentacion mas complejidad, mas probabilidad de fallos, mas tiempo de depuracion, equipos mas voluminosos, mas esfuerzo de intercomunicacion, finalmente menos productividad. Tengo 73 años y he visto DE TODO, personalmente yo prefiero el paradigma FUNCIONAL sobre el mainstream OOP, es mucho mas flexible y escalable pero desgraciadamente tiene un publico muy reducido, sin embargo hemos desarrollado productos especializados. Podemos adaptarlos rapidamente a los cambios de las "reglas de negocio" y cambios tecnologicos del cliente dandole soporte LTS, requiere cultivar una relacion de confianza, brindando un servicio efectivo, productivo y a valores muy competitivos.
Tenemos un producto que aun se mantiene "joven y agil", ha sobrevivido por mas de 20 años.
Desgraciadamente nuestra experiencia no creo que le sea de utilidad, porque la arquitectura de diseño es MUY diferente al mainstream.
Sin embargo creo que va bien encaminado en su reflexion ... suerte Antonio.
Totalmente de acuerdo contigo. Si yo, propietario de una pequeña empresa, estoy sufriendo todo esto que dices, al aumentar el tamaño de la misma los problemas se multiplican exponencialmente y esto llevará en pocos años a grandes quiebras y a miles de programadores sin trabajo. Además, programadores ultra preparados en una tecnología pero no válidos cuando se necesiten "hombres orquesta". Todo lo que sube como la espuma, se disuelve como ella. Ya te digo, desgraciadamente totalmente de acuerdo contigo.
Muy interesante el vídeo. Desde que empecé he visto el cambio de monolitos a micros y la complejidad de las soluciones ha aumentado brutalmente. La creación de micros para cada parte funcional es una aberración, pero un monolito mal montado es peor todavía.
Por otro lado la hiperespecialización al final es un mal necesario requerido por los tiempos de entrega. Igualmente si es interesante al menos saber qué es lo que sucede alrededor. Por muy backend que sea, no está demás saber a que se dedica el front y el devops, aunque no me caiga dicha parte.
Un saludo!
En mi caso he estado liderando a nivel técnico un grupo pequeño de no más de 3 desarrolladores, un tester y tenemos además una gerente de proyecto. El proyecto es grande en mi opinión y si es complejo ya tener 3 repositorios de front, 7 de backend y 2 de sql. Los hotfix urgentes, los bugs, los desarrollos nuevos comienza a ser complejo cómo hacer para que no se repitan funcionalidades pues luego de 3 años muchas cosas ya están hechas pero difícilmente alguien puede conocerlas todas para no repetir funciones auxiliares por ejemplo. Sumarle a esto que el proyecto comienza a ser transversal y otros proyectos ya dependen de los servicios y cada cambio requiere más horas de reuniones que de desarrollo . No me quiero imaginar cómo sería si realmente el sistema estuviera con microservicios por cada módulo pues ya son más de 150 servicios y ni hablar de lo que ahora llaman micro frontend . Definitivamente el tema da para escribir por horas 😅 pero muy buena la invitación a reflexionar
Te puedo comprar los repositorios de backend y db, pero me da curiosidad por qué 3 de front… ¿hicieron varias páginas distintas o fue por usar otro stack de pronto? 🤔
@@dev_time un front era para uso interno y otro para el público. El tercero es como un front transversal que unifica la autenticación en diferentes sistemas no solo el que tengo a cargo.
Tengo 11 años como programador y estoy bastante de acuerdo contigo, debemos regresar a un nivel más sencillo, la división es excesiva y absurda.
Completamente de acuerdo con lo que comentas, trabajo para una empresa muy grande y en mi equipo son mas los puestos de coordinacion que especialistas de hardware y desarrolladores.
Al final toda esta jerarquia es una perdida de tiempo, TPO, PO, Scrum master, el PM etc son un atraso en los proyectos sin contar con la cantidad de reuniones para discutir bugs que por el uso de estas metodologias son una basura de coordinacion.
La verdad estas metodologias son una perdida de tiempo, dinero y atrasos en proyectos y release!
Gracias, bueno saber que no soy el único que cree que algo anda mal. Lo de microservicios cuando no hacen falta o exagerar con ellos es una parte importante del problema. Coincido además con lo de "demasiada gente para poco resultado". Cuando yo desarrollaba sistemas solo o casi, terminaba produciendo mucho más. Ahora pierdo un montón de tiempo en reuniones, coordinaciones, convenciendo al QA, entendiendo especificaciones de algo que le explicaron al PO en lugar de a los desarrolladores, esperado por que alguien califique, planifique, documente. No exagero si digo que entre un 10 y un 15% de mi tiempo de trabajo es producir algo. La idea de lo "ágil" era deshacernos de tanto proceso inútil pero yo siento que sólo hemos cambiado aquellos procesos inútiles por otros nuevos con palabritas nuevas, más gente y más caos.
yo tengo muy pocos años de ser desarrollador, actualmente yo solito me hago una aplicación enorme, claro el costo de mi tiempo y vida ha sido enorme, pero si yo formara una empresa con otro como yo, creo que podriamos hacer aplicaciones, increíbles jaja... vieras que a estas alturas nunca pude conseguir trabajo, asi que me decidí a crear aplicaciones que solucionen ciertos problemas a negocios locales, y para este año, estimo poder vivir de esto totalmente
Que bueno que haya gente que entiende las soluciones de software de esta manera, por lo general es bueno cuestionarse si en realidad es necesario tomando mejor ser prácticos
Yo empecé mi camino de aprendizaje en aplicaciones web hace dos años, al escuchar este tipo de ideas y situaciones del día a día en empresas de programación veo un panorama gigantesco y me vuela la cabeza con lo poco que he aprendido en este tiempo.
Muy interesante todo lo que compartiste, para alguien que sabe tan poco como yo fue muy valioso escucharte.
Es verdad que los microservicios conllevan muchos retos, y el diseño de la solución completa se vuelve más compleja, pero desde que me he adentrado al mundo de los microservicios me he dado cuenta que en realidad pocos saben realmente como implementar microservicios de manera adecuada porque muy pocos los entienden, entonces solo incrementan la complejidad del proyecto y no reciben los beneficios que los microservicios conllevan, microservicios no es solo partir la aplicación y ya, primero se debe de analizar si ese módulo que quieres convertir en microservicios realmente puede (y vale la pena) ser independiente del resto de la aplicación si no solo complicarás el proyecto y seguirás teniendo los mismos problemas e incluso más que en una aplicación monolítica, por otro lado estoy en desacuerdo contigo en el uso de JSON, los JSON son una maravillosa forma de comunicar BE y FE, son muy ligeros, versátiles y permiten mantener su independencia. Regresando a microservicios, si los microservicios ya dividían la aplicación en partes pequeñas ahora también tenemos FaaS así que esa parece ser la tendencia.
Estoy totalmente de acuerdo. En mi opinión, los microservicios son una solución muy puntal que incluso es mejor si logras no necesitar de ellos.
Realmente es siempre lo mismo. Hay que vender una nueva tecnología que hace lo mismo que la anterior para mantener vivo el mercado. Primero fue CORBA, luego SOAP, RMI, EJBs, REST, ahora los microservicios, ... Todas tecnologías que básicamente acaban haciendo lo mismo (arquitecturas distribuídas) pero cada diez años se convierten en obsoletas. Antes hacíamos un proyecto entre cuatro y ahora tenemos que ser cuarenta porque está que tener Devops, sistemas, desarrollo, arquitectura, ... Con los microservicios yo siempre digo lo mismo: el nombre es engañoso. Micro en este entorno no significa "diminuto". Es como los "Microcomputadores" de hace años, que ocupaban una habitación. Los microservicios tienen que ser amplio espectro, pero la gente insiste en crear microservicios para el mantenimiento de una tabla de la base de datos.
Entiendo perfectamente el punto compañero, después de superar el código espagueti, llegamos a la infraestructura espagueti.
Es el primer video que veo de tu canal. Estoy muy de acuerdo con tu visión y cómo la has expuesto. Creo que hay que buscar un punto de equilibrio para no caer en la tentación de "monolitizar" o "microserviciar" cualquier aplicación. Cada aplicación es diferente y prentende resolver necesidades que no se satisfacen con una receta mágica o universal. La industria seguirá descubriendo patrones que van más allá de la ingeniería del software y que vienen impulsados precisamente por los costos y beneficios propios de las necesidades de cada negocio.
Totalmente deacuerdo con lo que explicas. Llevo haciendo aplicaciones desde 1992 y ya he pasado por todas las modas que hido surgiendo, ahora mismo soy fullstack de Angular y c#. La realidad es que la mayoria de empresas quieren microservicios sin pensar si realmente lo necesitan.
Y realmente lo que antes haciamos equipos de 1 a 5 programadores ahora lo hacen con equipos de 30 personas y lo peor es que la calidad no es mucho mejor que la que teniamos antes.
Yo el futuro lo veo como aplicaciones de servicos modulares, osea que cada servicio sea sobre un contexto empresarial, eso permite una alta escalabilidad sin comprometer el mantenimiento.
15+ años de experiencia. Trabaje con monolitos, microservicios y la posta es la que siempre fue. Hace un monolito y saca en un servicio aparte lo que no escala. Usar colas para comunicar procesos lentos.
Antonio, google me ofreció tu video y comparto todo lo que has dicho, la verdad que no he trabajado con microservicios, tal vez por el tamaño de los proyectos, pero siempre me pareció una sobre ingeniería, complejidad de comunicación entre los servicios, complejidad en mantenimiento y mejoras y obviamente en costo de desarrollo y costo de hosting.
Lo mismo me pasa con las cloud functions y todo lo serverless... realmente no es necesarios en la mayoría de los casos.
Solo vengo a comentar, por experiencia, que tienes TODA LA RAZÓN. El desarrollo de software se ha fragmentado tanto que lo que antes hacían tres profesionales, ahora lo tienen que hacer seis especialistas
Antonio, me dio mucho gusto oír tus ideas.... tengo 50 años programando done es obvio que vengo de los super monolitos. Al gustarme mucho este mundo no he querido quedar desactualizado como la mayoría de mis compañeros y le he entrado al mal necesario. Lo de los microservisios lo veo igual que tu sin embargo hoy tengo soluciones completas en la web multi páginas generando miles de transacciones hechas por un solo desarrollador que soy yo. Hoy genero una solución completa en web como en Android que llega a mejores resultados que las soluciones de las que hablas con un costo muy bajo. Me gustaría mucho mostrarte los mín - monolitos que construyó antes de morirme. Felicidades por tu reflexion.
Un microservicio tiene muchas ventajas, muchas de las cuales ya has mencionado. En el entorno que estoy desarrollando, la mayor ventaja respecto del monolito de cara al desarrollador es que puedes subir a producción una parte del sistema y no como antes que era necesario subir a producción el monolito entero. Esto en otro tipo de entornos puede no ser la gran cosa, pero en el nuestro es algo primordial, ya que provocaba que solamente pudieras modificar algo una vez al mes y el proceso desde que lo modificas hasta que sube a producción era insufrible y interminable. Como desventaja más importante para el propietario del producto, efectivamente son los costes de desarrollo, pero también hay que decir que, al menos en nuestro caso, el coste por unidad de procesamiento ha bajado mucho. De todas formas, los microservicios están pensados para aplicaciones altamente escalables, para sistemas de pequeño tamaño no tiene sentido usarlos.
Me agradó la información que expresas, coincido en tu enfoque, soy programador de front end y back end, opté desde mis inicios no trabajar con microservicios y los resultados son buenos. Gracias por compartir.
Hola, hoy ví tu vídeo y en todo lo que dices estoy de acuerdo contigo. Soy especialista de infraestructura (sysAdmin). Conozco algunas herramientas de DevOps, como Docker, Podman, Kubernetes, Openshift, etc. Nunca le he dado tanto la razón a nadie como ahora a tí con este vídeo. Esas herramientas son muy buenas, pero además de que incrementan exponencialmente la necesidad de equipos de trabajos más grandes, más todo lo que eso conlleva: coordinación, sincronicidad, sinergia y los costos asociados; pues también el problema de ciberseguridad es grande y demandante, dado que estas herramientas se piensa más en la velocidad que en la seguridad, entonces siempre se termina sacrificando la seguridad y priorizando la velocidad, porque "los ataques son esporádicos, pero la lentitud es constante". En fin, mejor explicado imposible.
Prefiero monolitos pero el problema es que tiende a acoplarse entre módulos y luego se torna dificil de mantener. Tienes que tener un buen equipo de trabajo y tener las reglas muy claras para que no acoplen. En mi caso trabajo con un equipo de la India que no son los mejores del mundo y he estado pensando en cambiar a microservicios. Pero con una cantidad limitada de servicios. Asi cada equipo se ocupa de su servicio. Es como dices, a la final cada servicio es un mini proyecto
Yo tengo opiniones encontradas (por no decir q la solución “DEPENDE”)
Por un lado me ha servido desacoplar las funcionalidades en microservicios porque me ha sido mas fácil mantener el código y añadir nueva funcionalidad, pero por otro lado al entrar en equipos donde ya tienen todo su sistema montado con 6 o 7 micros se me hizo casi imposible entender como funcionaba todo el flujo, seguir la traza de errores o identificar el estado y en que punto se había quedado. Entonces creo q lo mejor es no casarte con una solución sino d intentar dejar todo lo las simple posible y si vez q el sistema crece sacarlo en otro micro servicio pero evaluando la complejidad q se le añade.
Cuando recién me gradué, a un ingeniero se le asignaba un proyecto. Y Éste lo iniciaba y lo terminaba solo.
Hoy se requiere toda una cuadrilla para resolver un problema simple.
Igual que cuando en las calles destapan una alcantarilla, se ve uno o dos camiones, varias camionetas y 8 a 10 personas mirando y solo una trabajando.
Tienes toda la razón con el tema de la sostenibilidad y mantenibilidad del software. Es muy complicado gestionar evolutivos que van encima de cosas y acabas necesitando de manera directa o indirecta a 20 tios para levantar una SPA al entorno si quiera de desarrollo. Sin embargo, hay mucha de esta problemática que se puede resolver (gestión de dependencias, coordinación de despliegues o versiones), que no tienen porqué hacerse desde un monolíto, sino quizá desde un monorepo. Es decir, gestionar todos esos múltiples servicios y aplicaciones que forman parte de un mismo producto de manera centralizada. Por lo menos al arranque de los proyectos, esto escala súper bien y te ahorra muchísimas horas de coordinación, puesto que la misma base de código está compartida y se puede gestionar el ciclo de vida del producto de manera centraliza. Sigues necesitando mucho experice, pero si ya tienes a 3/4 tios que te sepan montar todo, es un metodología de trabajo mucho más ágil para la gestión del production (la infra va a parte)
Muy interesante! Apoyo la idea, También tomar en cuenta el tema de los datos que son el alimento de la IA
En mi caso, trabajando en una empresa que factura muchos millones al año, estamos usando un monolito. Pero ha llegado un punto en el cual ya nos hemos planteado el paso a microservicios, porque tenemos muchos lanzamientos con miles de peticiones por segundo, en previsión de los cuales se hace necesario realizar escalados horizontales de infra (AWS) muy muy costosos (para que nos entendamos, replicar el monolito, y replicar la mega base de datos conectada, en múltiples instancias cada uno).
Con microservicios en soluciones serverless en la nube, p.ej funciones lambda, nos olvidaríamos de los escalados y son servicios mucho más baratos. Aparte, creo que usar EDD ayuda a desacoplar cada pequeña parte de la aplicación, evitando que si se rompe un microservicio, dejen de funcionar los otros.
En definitiva creo, al menos en nuestro caso, y en cualquiera con picos de alta demanda, que un monolito es la peor solución.
RoR, Laravel, sí, son perfectos, pero para aplicaciones web con poca fluctuación de tráfico.
Si alguien se ha visto o está en esta misma situación y tiene una solución monolitica y de bajo coste que me explique cómo lo hace 😅
Un saludo!
Personalmente pienso que no tenéis tampoco que tomar una decisión de cambiar totalmente la arquitectura, yo, sin conocer para nada lo que hacéis, primero analizaría cuáles si. Las partes que tienen esas miles de peticiones por segundo y separar solo esa parte manteniendo el grueso de la plataforma, no creo que se trate de algo exclusivo, hay muchos escenarios intermedios que no suponen cambiar radicalmente una plataforma que lleva años funcionando a una arquitectura totalmente distinta reescribiendo todo desde cero
En todo caso, gracias por comentar y exponer el caso
Me parece super interesante y muy bien explicado. Quizás solo sería útil desarrollar el discurso a partir de un ejemplo más tangible, por ejemplo una aplicación concreta que haga X.
El relato en sí es terrorífico y con reminiscencias kafkianas.
Complementando, creo que no debemos usar una tecnología por moda y para todos los casos o escenarios; todo parte de aquellos atributos de calidad o requerimientos no funcionales del proyecto en particular; son estos quienes en primera instancia nos que permiten definir que estilos y patrones arquitectónicos se podrían implementar para tener un producto o software de calidad, luego de esto entrar a verificar con el equipo de proyectos o stakeholders su viabilidad técnica y económica que me permita identificar si puedo o no implementar microservicios o debo empezar con un monolito bien diseñado y codificado que permita evolucionar con el tiempo.
Yo he trabajado tanto con monolitos como con microservicios . Los microservicios son una buena opcion para poder escalar mejor , hay veces que quieres tener un micrsoservicio solo destinado a automatismos... Otro para relazar carga masivas y otro un microservicio que sea un motor de alertas en tiempo real y notificaciones . Hay que usar las cosas con cabeza . Y por supuesto hay cabida para todo , pero si ... Estoy de acuerdo en que si separas y separas servicios que pueden convivir juntos ... Se vuelve una odisea programar
Muy de acuerdo en todo. Justamente este último tiempo veo que se valora más los perfiles generalistas que los especialistas.
Trabajo con Remix.js que va muy en esta linea
Estoy muy de acuerdo con el problema, es muy real y de gran impacto. He dirigido proyectos de desarrollo de escala mundial, y también he externado esa preocupación de alto incremento en el costo y la complejidad de las aplicaciones. Soy también dueño de productos, incluso con AI y Data Science, y la solución que he encontrado es aplicar domain driven design y web semántica, con sus herramientas de código automático en un porcentaje muy significativo, y como sugieres, hacer mini app (no micro) creadas por funcionalidad de negocio, pero agrupando en cada una todas las capas arquitectónicas, servicios y front y persistencia, con lo que he reducido el tamaño del equipo y costo hasta en más de un 80% . Muchas gracias por un tema tan relevante.
Gracias a ti por tu comentario, me parece interesantísimo lo que comentas, además basado en proyectos reales, un abrazo!
Tiene mucho sentido, trabajo en una empresa donde parece haber una espidemia de microservicesitis
Creo que esto da para un open space online interesante, obviamente con gentes que tenga muy pero que muy vista ambas caras de la moneda 😉Respecto a lo que comentaste de que para hacer 3 pantallas hay que hacer 3 micros, francamente alli hay alguien que carece de sentido común y que no sabe evolucionar software de manera iterativa, me gusta la arquitectura de microservicios pero rara vez la recomiendo, siempre recomiendo monolitos bien modularizados y solo sacar fuera aquellas piezas que tenga sentido que escalen por separado porque computacionalmente hablando lo requieren, es decir, son demandantes en cuanto a trafico y obvio necesidades de infra.
Me parecio interesante lo que aqui se plantea por el expositor como por los que presentan sus puntos de vista los felicito
Interesante tu tema. Acá en Argentina y sobre todo en el sur, donde la gente especializada es muy muy poca, hemos tenido que ir capacitándonos en "de todo un poco", y cuando se necesita un especialista para algún tema en particular, se lo contrata en BsAs. Ahí, además de hacer su trabajo, por lo general luego de la/s jornada/s, brinda otra parte de su conocimiento a ansiosos oyentes, a cambio de un asadito entretenido y ameno. Es todo un tema la relación los especialización vs recurso humano. no creo que se limite a los microservicios ni tampoco a la informática. En el caso de los petroleros creo q esto lo resolvieron muy bien con los Company Man.
menuda Joyita de canal. Saludos de españa
Gracias por compartir este pensamiento de arrebato. Saco de tus palabras la necesidad de la figura del maestro liendre (De todo sabe y de nada entiende). Es cierto que se requieren perfiles mas multidisciplinares donde una única figura tenga la capacidad de abordar otras áreas. Lo cierto y verdad es que estos perfiles también tienen experiencia y especialización con lo que los costes entiendo que son difíciles de reducir y lo interesante es reducir el numero de integrantes del equipo, formando un equipo multidisciplinar que de respuesta como el equipo anterior pero en menor número de personas, optimizando los costes, por otro lado hay una tecnología emergente donde muchos de los problemas que planteas quedarán resuelto WebAssembly. En mi humilde opinión creo que todas las tecnologías se están llevando al punto de la extenuación obligando de algún modo a ser un gurú en cualquiera de ellas para hacer cualquier cosita medio decente. En tus tiempos manejando 4 herramientas y programando en algún lenguaje eras rey del mambo ahora con 5 lenguajes hablando 3 idiomas y manejando windows y linux tienes menos peso para el mercado que una pluma de paloma.
Yo prefiero la mezcla de los 2, microservicios y monolítico
Yo soy Tech lead pero perdemos mucho tiempo con la metodología Scrum, se pierde mucho tiempo gestionando tareas y registrando horas, el proyecto solo tiene 3 programadores que son todo, incluso yo me meto a veces a ayudarlos cuando no estoy gestionando el proyecto, después de eso hay como 7 personas más que se ocupan de la gestión del proyecto.
Yo viví toda la migración de una estructura monolítica a microservicios y detesto estar construyendo modelos para leer un JSON de un solo microservicio, si son N servicios tengo que construir N modelos porque cada quien arma su JSON como se le da la gana.
Me gusto mucho la propuesta que dio microsoft con Blazor capaz de mezclar los 2 mundos, se puede usar microservicios pero a la vez usar un backend sin estar refrescando el navegador, como lo hacía ASP.NET en 2008, tenías tu archivo.aspx y tu archivo.aspx.vb, algo parecido lo hace Blazor, no directamente, entonces lo que es de backend es de backend y lo que es de front es de front pero todo conviviendo en 2 proyectos que al final hacen un solo proyecto sin darle tantas vueltas al asunto.
Interesante el tema que estás tratando, estoy completamente de acuerdo con tu punto de vista, creo que una solución que he visto es Laravel con Livewire el cual combina lo mejor de ambos mundo de frontend y el backend, utilizando un solo lenguaje de programación. Hay que volver a lo de ante donde un programador pueda crear un sistema sin necesidad de utilizar tantas tecnología o microservicios es más optimizado, ahorra mucho tiempo y menos complicaciones como resultado de todo eso Mayor rentabilidad
En mi experiencia, los microservicios (ms) son un problema si no hay una infrarstructura y una arquitectura bien definida. En las dos últimas empresas en las que trabajé, esto era así, y crear un nuevo ms era muy simple. Ya esta definido como los ms se comunican entre sí, como mantienen consistencia entre ellos, como se despliegan en la nube. Incluso tenemos unos templates que generan un esqueleto de ms, en el que luego hay que escribir la lógica de negocios para ese ms en particular.
Entiendo que puede ser más complicado si todo eso no existe, si cada nuevo ms es distinto al anterior.
Y creo que tener microservicios, uan vez que está solucionado el tema anterior, dan muchas ventajas sobre un monolito.
Exacto, un buen sistema de microservicios debe siempre inciar con templates, comunicaciónes definidas. Logs etc, lo mas. Minimo pero mas completo para q dos microsbse comuniquen.. De ahi en adelante escalar eso con nuevos micros es solo baje repo, siga este estandar e implemente lo propio del microservicio y listo.. El despliegue, monitoria, etc etc, viene sencillito
Lo q pasa es q los arquitectos no diseñan bien y dejan mucho al desarrollador y estos muchos hacen lo minilo y a como les plasca..
Estoy de acuerdo, solamente con decir que vas a usar una arquitectura de MS ya tienes que empezar a pensar en el MSs de configuración, APIGateway, Seguridad, Trazabilidad y Discovery, más los MSs propios del negocio, eso en infraestructura de contenedores ya es una pasta adicional. El problema es que a veces se encuentra uno con aplicaciones de 3 o 4 MSs para empresas de 20 usuarios.
Asi es, y con un uso muy uniforme de las distintas secciones funcionales de un proyecto
Hola,
Varios puntos buenos, los factores de éxito, profesionales experimentados.
Por otro lado, he reflexionado y veo que el término ágil se usa convenientemente según a quien le preguntes y comparo el desarrollo de microservicios con metodología antiguas como los famosos prototipos, espiral e incluso aplicaciones por componentes.
Finalmente la cultura del como vamos sin mayor conocimiento del proyecto, seguimiento no acompañamiento.
Totalmente de acuerdo. De hecho, estoy saliendo de un proyecto en el que inicialmente se planeó un monolito dada la necesidad y características del negocio del cliente. Cuando conocimos a detalle los flujos de trabajo, prácticamente tuvimos que optar por microservicios lo menos específicos posibles para evitar una modularidad excesiva. Al final, todo fue bien pero el despliegue de la aplicación ha sido lento y por partes complicado. Un saludo.
La separación entre backend y frontend ya es un esfuerzo enorme, pero te da una visión mas global de integración del proyecto, pero esos cambios solo es cuando quieren lograr los atributos de calidad que te dan los microservicios, ahora que tu backend lo puedas separar en muchos microservicios ya es cuestión que tan maduro sea tu equipo, saludos
Yo trabajo con varios clientes. Realmente solo son 5 y de verdad que no puedo atender mas. Pero la verdad que me mantienen bastante ocupado y con mucha evolución. Porque comencé con sistemas básicos y ya llevamos varias app y de hecho tengo un cliente que en particular ya utiliza tres sistemas de bases de datos distintos para sus necesidades. Tengo 3 colaboradores que trabajan conmigo y nos seria imposible gestionar las diferentes partes de nuestros sistemas y los distintos lenguajes de programación tanto en el backend, como en el frontend, apps móviles e IA sin usar microservicios. Creo que cualquier recurso mal gestionado al final le ira mal. Un sistema basado en microservicios bien definido y sobre todo DOCUMENTADO a tiempo (y no cuando la aplicación lleva como 5 anos y 4 cambios de plataformas o versiones), funciona perfectamente. Claro esta es siempre mi opción y experiencia particular, después de 4 años implementado microservicios en producción y es la que me ha funcionado hasta al momento. Que las soluciones implementadas puedan trabajar solas y permitan generar beneficios de forma pasiva y sin estar colocando venditas aquí y allá
Entiendo, pero me hablas de microservicios o de distintos módulos independientes trabajando en conjunto? A eso me refiero en el vídeo. De todos modos, muchas gracias por comentar, muy interesante lo que dices
Muy buena reflexión!
saludos, super interesante y esta situacion lo veia venir, pero hasta que no se hace notorio los jefes no lo ven y no lo entienden.
Excelente video!! Me parece muy interesante tu reflexión sobre como se esta trabajando con los microservicios hoy en dia. A decir verdad, no tengo experiencia trabajando con Microservicios (hasta ahora solo he trabajado con Monolitos) pero recientemente he comenzado a aprender sobre ellos porque me encantaria trabajar en proyectos de ese tipo en un futuro proximo, y esta problematica que planteas sobre los microservicios me ayuda a tener un panorama más claro sobre ellos. 👏
Gracias por comentar! Al final esto es una carrera de fondo, tú mismo con el tiempo vas sacando conclusiones
Creo que lo que falla es que se trata de aplicar la misma solución (microservicios, monolitos, etc) a todo tipo de aplicación. Creo que los arquitectos e ingenieros de software tienen que dejar de usar las modas y pensar seriamente cual es el poducto que que quieren desarrollar.
Veo que en muchos casos le dicen a los programadores "Hay que hacer esto", sin casi ninguna planificación o delineamiento. Hay empieza a jugar el nivel de señority de cada uno, sumado al problema de la rotación, los proyectos terminan como "Frankesteins" con poca resiliencia, difíciles de continuar y mantener.
Desde mi experiencia Jr. trabaje para algun proyecto de microservicios con spring boot, me asignaron el servicio de batch en su momento. Me parecio bueno en el sentido que todo estaba bien organizado y cada aplicacion back, se dedica a una logica muy general del negocio, se buscaba tener como 6 microservicios entre esos el gateway. Entonces iba a ser algo manejable porque eran pocos y solo un front con angular que mostraba la vista de todos...
A nivel medio es una maravilla, pero cuando la aplicacion es masiva, y ademas la empresa no tiene un buen sistema de revision de codigo se vuelve una pesadilla. De igual manera es la mejor solucion a dia de hoy para la gran mayoria de proyectos
Creo que mas el problema como en todos los proyectos es tener una buena arquitectura. La modulizacion resulto ser muy buena para hacer mas robustos los proyectos en escalabilidad de cargas y multi servidores. Pero como indica en el video el mantenimiento se volvera siempre complicado y creo al final AI se encargara de eso al final eventualmente reemplazar a los programadores. Al final no sera raro ver un DevOps AI. Un ejemplo es la modulacion de logs en Splunk AI que Cisco planea como solucion para QA
Hola Antonio, tal cual, si bien como dices es una solucion para problemas complejos, pero tal cual he estado en proyectitos de par de pantallaa o interfaz y se inventan una infraestructura de micros y para proyectos que ni tienen planes de crecer tienen, y luego de mar de api pierden hasta el control y ves tantas repeticiones de los mismos metodos. Muy interesante tu analisis.
Para 2005 todas las aplicaciones que hacía eran WEB. Robustas y con gran empleo de bases de datos. Solo estaba cerca a las aplicaciones de escritorio para migrarlas a WEB.
La arquitectura en ese momento era SOA, algo mucho más lejos del monolito que venden los evangelistas de los microservicios... y antes de eso, desde 1997 el modelo era desacoplado sobre n-Tier. (tenía equipos de desarrolladores especializados en cada capa!)
El problema de la gran cantidad de gente está dada por el modelo de desarrollo: agile. Donde lo que he visto en estos años es que aplican a la fuerza esto cuando otras metodologías son mejores.
Lo otro es que la aplicación de principios SOLID y Patrones de diseño a rajatabla sin evaluar cuando procede aplicarlos y cuando dejarlos de lado. Sin embargo este sobreesfuerzo vale la pena pues se reducen dramáticamente los tiempos y costos de agregar nuevas funcionalidades.
La conclusión es siempre hacer desarrollos híbridos que emplean microservicios dependiendo del diseño de una arquitectura pensada y no armada a la carrera como sucede habitualmente con Agile. (Prefiero modelos híbridos RAD + Agile)
Totalmente de acuerdo,los microservicios son útiles más que todo para sistemas que sean de consumo masivo(estilo Netflix).
Claro es como la gente que usa nextjs solo para un landing que tiene un formulario simple. Hay que saber usar la herramientas y saber en qué proyecto usar una u otra.
Tu corta respuesta resuelve el punto central del tema; los microservicios son para aplicaciones que demandan mucho tráfico, eso sin mencionar el costo de los equipos que los mantienen, que sólo pueden ser asumidos por empresas grandes. Saludos
Vaya que odias Java 🤣🤣🤣 Buen canal, lo descubrí hoy. Yo hago el front end el back, etc como Alfonso Cuarón, el es director, editor, guionista, sonidista, etc. Saludos desde Paraguay
Estoy muy deacuerdo contigo.
Creo que ocurre un problema muy común entre nuestro gremio (quizá en otros). Es saltar de un extremo al otro y volver a saltar hasta el otro pero un poco más corto... en un mecanismo similar a un muelle como buscando el punto de equilibrio pero utilizando un algoritmo no optimizado.
Estoy sufriendo todos los problemas que describes en mis propias carnes.
Y como ejemplo de nuevo de la "técnica del muelle", añado el "Spring Dependency Injection".
"Spring Dependency Injection" es realmente interesante y útil. Pero usado con moderación. El abuso del use hace que el mantenimiento sea casi imposible sin llegar a tener claro en algunos casos donde se define que componente, quienes lo están usando e incluso... cuando puedo eliminarlo porque nadie lo está usando nunca más :-D
Cordial saludo, me encanta el tema, me parece acertado el punto de vista. Lo que se vive en la programación es consecuencia de modelos creados para salir del paso y de personas que no se preguntan porqué se hace de esa manera, peor aún, por no usar nuestra propia inteligencia, estamos delegando tareas importantes a la inteligencia Artificial. Los futuros ingenieros se ven certificados gracias a chapGPT.
Muy buen video!
Creo que es una reflexión necesaria que debemos hacer con frecuencia, muchas veces adoptamos una metodología/herramienta/tecnología solo por que es lo que más suena y no evaluamos si realmente la necesitamos.
Durante más de 10 años trabajé construyendo un monolito al que hoy doy mantenimiento en varios clientes.
Un punto a favor es que resulta relativamente fácil agregar nuevas funcionalidades, pero una contra es que resulta complicado incorporar nuevos desarrolladores.
Como dicen, la clave está en el equilibio y pensar siempre en que sea un producto sostenible.
Totalmente, ese equilibrio es el más difícil de mantener, con respecto a lo de incorporar nuevos desarrolladores, creo que es más complicado incorporarlos a una plataforma con muchos microservicios en diferentes tecnologías, cuesta bastante más encontrar perfiles con mayor especialización y cuyo expertise sea alto en cada una de ellas, y claro, cada uno de ellos sale más caro. Lo que intento defender un poco en el vídeo es que modularizar suele funcionar bien, pero tenemos que pensarnos muy bien fracturar una app en muchas partes, aunque a priori parezca más sencillo trabajar en cada una de ellas por separado, muchas gracias por comentar!
@@fullstackoficial Yo pienso que es como la mecánica cuantica, las reglas cambian cuando las cosas son muy pequeñas o muy grandes.
Hola amigo, muy interesante tu analisis. Habiendo sufrido los cambios que bien describes en tu video, recuerdo que para desarrollar y mantener un monolito se necesitaba gente muy bien capacitada en todas las capas del desarrollo (de ahi venimos la mayoria de arquitectos). Pienso que si volvemos al paradigma del monolito, aunque sea pequeño, deberiamos volver a contar con ese estilo de perfil en nuestros equipos. Lo que aumentaria el costo (sueldos mas altos) con el agravante que si uno de ellos se va, el abandono es mucho mas grande. Tal vez la solucion al problema de los microservicios sea una mejor documentacion y una superposicion de responsabilidades. O sea que todos puedan saber un poco de lo que hacen los demas. Promover el conocimiento de otras tareas puede hacer que la gente se encuentre mas motivada a quedarse (aca estoy creciendo). De esta forma, si tenemos una baja, no todo esta perdido. Por otro lado la renderizacion en servidor nos volveria a traer el problema de los diferentes dispositivos, a lo cual deberiamos encontrar una nueva solucion. Vuelvo a repetir, muy interesante tu planteo, es muy bueno para ponernos a pensar
ALELUYA! Por fin alguien lo dice. Eso que hace Ruby on Rails me parece lo más genial del mundo. No entiendo cómo no es usado más por los desarrolladores. Yo uso Ruby On Rails en mis proyectos y el desarrollo es súper rápido.
El tema me encanta porque soy empresario y en nuestro mercado el desarrollo de software es necesario pero no hay tanto dinero para llevarlo a cabo.
En nuestro caso hemos tomado la decisión de tener un monolito modular (5 módulos). Hasta no ver que es completamente necesario, no vamos a romper el monolito.
Muy buena decisión desde mi punto de vista, a veces perdemos la perspectiva de que un proyecto debe ser rentable y poder competir, en muchas ocasiones lo que hace que se pueda continuar es justo que sea viable económicamente, aunque sea el proyecto más bonito del mundo y el mejor hecho
Tal cual como mencionas..
El problema no es la tecnología, sino el mal uso que se le da..
No creo que sea responsabilidad de los devs, para eso existe el rol de "arquitecto" que en la mayoría de las empresa no existe y la responsabilidad termina recayendo en perfiles Ssr. o con suerte en algún Sr, aunque eso garantiza nada.
Los que hacen management, si fueron devs deberían saber abstraerse el problema y ver costo/beneficio en la toma de decisiones. Pero solo les interesa el TTM, o acordar tiempos ajustados para "motivar" a los devs.
La rotación tampoco es el problema, sino la consecuencia de la falta de cultura en las empresas.
Disculpa pero programación orientada en el WEB empezó enseñarse por ahí en 1998-1999 en la universidades, y se usaba asp, js, jsp. y app web habían muchas ya en producción
Escuche todo el video, excelente opinión
Muy buen punto Antonio. Como curiosidad añadiré que yo mismo allá por 2017 ya comentaba a mis compañeros esto mismo, que veía bien este tipo de enfoque para corporaciones y empresas tochas pero no para todo el mundo. Simplemente para la agregación de logs era una locura, instalar ELK o similar blah blah blah ... Claro veías lo que hacía Netflix y alucinabas los bien que lo tenían montado pero eso no era viable bajo mi punto de vista para una pyme incluso para una gran compañía que no tuviese un muy buen equipo técnico. Se desplazó la complejidad de la parte de desarrollo a la parte de arquitectura. Claro yo veo los costes y ves que ahora todo se lo llevan las grandes (Amazon y Microsoft) mientras los beneficios de la empresa que tiene la propia aplicación languidecen porque te gastas una pasta en infra. Incluso abogo por montar tú los microservicios en tus instalaciones para no pagar esas cantidades astronómicas a los grandes (proyecto medio del orden de 20000€ al mes (DEV/UAT/PRO), ¿sabes cuanto hierro y recursos puedes poner en tu empresa por ese precio?) Una vez más, ha sido una jugada maestra de las corps.
Veo opiniones, acertadas y desarsertadas. Por lo que mencionas en tu video, veo que no saben usar microservicios y no tienen un claro manejo de los Dominios, si los microservicios crecen manera exagerada como decis, es porque justamente no saben dividir los dominios, les recomiendo que leean un poco la teoria de microservicio y la aplicquen porque no lo estan usando bien.
Nunca logré implementar ms solo. Tengo una aplicación de contabilidad (mini erp) separado por modulos (ear) con servidor de aplicaciones wildfly y un ear que contiene el front end angular. Con una base de datos postgresql. Funciona bien y muy rápido. Creo que los ms nacieron con la idea de alivianar frameworks pesados antiguos, pero hoy en día tenemos opciones mucho más rápidas donde se puede separar el front y el back, sin necesidad de que sea ms. Pienso que las arquitecturas no son ni nuevas ni viejas, sino que deben ser pensadas para resover un problema real, si ocacionan un problema no cumple su objetivo.
Ufff, implementar ms uno solo, no se si me metería yo ahí, si lo que tienes te va bien y lo puedes mantener tu solo, no cambies la arquitectura a no ser que responda a unas necesidades muy concretas que no puedas solucionar con lo que tienes, gracias por comentar!
Totalmente de acuerdo con cada palabra.. la pregunta que me hago es.. ¿No será el momento de quitarles el mote de 'Escalables y Mantenibles'?
Todo lo que has comentado es cierto, pero realmente quien ha pecado es quien dirige los proyectos porque es quien debe de medir en qué se invierte el tiempo y como lo inviertes. Si para todo quiere hacer micro servicios sin medida, pues los desarroladores lo van a hacer, y cuidado que se le cuestione porque luego luego se enfada y el ambiente laborar se pone raro. Creo que hemos perdido el poder de discutir todo y aceptar experiencia, ideas nuevas y sentido común.
Te conocí por este video, y es que estoy en la misma posición, veía los Microservicios como el presente y el futuro, pero me he encontrado a varios compañeros mostrándose en contra
Varios problemas que noto en la actualidad: 1.los analistas desconocen el comportamiento de los procesos, al crear historias de usuario no tienen en cuenta el ámbito en que trabajan, ni los interesados implicados, 2. no se aprovechan los cambios tecnológicos, así que no se proponen mejoras desde el inicio, esto tiene como consecuencia historias de usuario mal concebidas que no se ajustan a la realidad de los procesos... 3. mucho tiempo para el análisis y poco tiempo para el desarrollo. 4. el usuario no siempre tiene razón (su visión de los procesos, descarta el como la tecnología puede disminuir sus costos de operación)
Trabajo en una de las grandes de informática de España y ocurre lo que explicas, hay mas jefes que indios. Es un proyecto grande basado en microservicios java. Llevo en informática desde los inicios de la informática, he visto nacer todas las tecnologías existentes y javascript se me daba genial y la verdad que llegaba a adorarlo, ahora ya no lo uso casi, pero se hacer desarrollos muy buenos con él. Soy nuevo en tu canal y por como hablas y explicas, me he subscrito.
Gracias por comentar! Por lo que dices creo que hasta se de que empresa hablas, jeje, yo también trabajo con ellos, son clientes nuestros… (si es quien yo creo)
Los microservicios en su momento ayudaron a que no sean tan "gordos" y difíciles de entender y mantener los monolitos, pero lo que yo veo es que con nuevos patrones como arquitecturas hexagonales/tdd/domain objects/etc.. el código se puede organizar y mantener mejor en un monolito por lo que son más viables/factibles que hace unos años (osea estoy de acuerdo en bastante de lo que dices). Los microservicios los aplicaría en sistemas grandes que usan corporaciones, soluciones como SaaS, Netflix, Etc.. soluciones en las que van a participar varios equipos de trabajo y por supuesto no pueden haber mas de 50 devs pusheando sobre un mismo repo un mismo código porque sería algo caótico. El patron mas controversial que he visto con 20 años que ya llevo trabajando es tener 1 base de datos por microservicio, por la complejidad y altos costos que lleva aplicar esto en la practica como aplicar el patron de domain events para que los microservicios tengan copias de datos externos en sus bases de datos, precisar un broker que funcione bien y coordine todo esto, luego patrones como CQRS, etc... sin duda todo esta complejidad puede evitarse teniendo varios microservicios compartiendo una única base de datos, y creo es algo que no debe descartarse; pero curiosamente sin embargo hoy parece que se "demoniza" como una mala práctica cuando en realidad simplifica las cosas y baja muchisimo los costos.
Estoy de acuerdo. Yo tengo unos años desarrollando mi producto, tengo dos personas apoyándome y este producto es monolítico y muy organizado y hasta el momento no he tenido la necesidad de hablar de microservicios, teniendo en cuenta que el proyecto es grande, sirve de pasarelas de pagos para conectar aplicaciones a bancos de Colombia y Venezuela, controla inventario, ventas, entre otras funciones y con tres recursos el proyecto ha estado avanzando. Pienso que se está burrocratizando cada vez más los proyectos.
Me parece una gran estrategia, probablemente por eso tu proyecto mantenga una buena rentabilidad, algo básico que como desarrolladores muchas veces se deja de lado, un proyecto tiene que ser rentable, si no, tarde o temprano, cae
Te has puesto a pensar de que todo esto son los pesares de empresas? De que esto no es nuevo sino ya es sangre que corrió en gigantes anteriores? Esto ya lo sufrió Ford, lo sufrió GM, lo sufrieron cadenas de supermercados, todos más de 50 años atrás. El programador es muy demandado porque es el nuevo peón de la industria. La industria del software sufre tal cual lo describes porque a pesar de todo el palabrerio, en general ejecutan todo accionar orientados a la tarea, a pesar de que venden la idea de procesos contemplados.
Esto termina en un tendal de procesos rotos, no reconocidos y una nueva tendencia de contracción sobre la implementación y la huella de personal. Esto es solo una idea, mi forma de verlo. Saludos
Yo siempre lo he considerado un disparate: es muyy complicado de implementar, desarrollar y actualizar. Al final estás manteniendo miles de "maquinitas pequeñas".
Ya hay monolitos modernos como next o nuxt. La cuestión es que los monolitos que usaban jQuery se volvían infernales en cuanto la cosa crecía un poco. Al final cada proyecto es único y hoy en día, por suerte, hay opciones para todo, si quieres monolito, si quieres monorepo, si quieres microservicios, si quieres microfrontends... lo malo es la cantidad de cosas que hay que saber xD
En mi caso utilicé mucho ssr, pero vi que los frameworks se fueron quedando atrás en la gestión de recursos