¡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...
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.
Qué buena tu decisión, hermano. ¿Podrías mostrarme tus apps? ¿Las tienes en la Play Store? Y si es así, ¿de qué son? O, ¿cómo trabajas como freelancer actualmente?
yo comence a trabajar en una pequeña empresa familiar hace un tiempo atras, experimenté de primera mano los desafíos de una arquitectura monolítica mal organizada. No contar con una estructura bien planificada genera múltiples problemas y limita la escalabilidad. Además, como se menciona en el video, depender exclusivamente de una única estructura puede volverse un obstáculo, especialmente al intentar adaptarse a nuevas necesidades o tecnologías.
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.
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.
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.
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.
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 😅
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
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.
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
Muchas gracias por el video. Soy desarrollador y he ido notando esa moda por microservicios que muchas veces no analiza bien el impacto. Dividir, seguro, pero no solo por moda, sino por necesidad. Un equilibrio creo yo.
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
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.
@@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.
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.
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
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.
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 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.
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.
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.
@@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.
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.
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 😅
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
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.
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)
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.
Excelente análisis, creo que el principal problema que se maneja en la industria es que se quiere hacer de todo una bala de plata, nos movemos en un bucle donde nos vamos del punto A al punto B para luego volver al punto A y asi sucesivamente. Ya sea microservicios vs monolito, serverless vs serverful, ssr vs csr y asi con todas las arquitecturas, patrones de diseño, etc. Como veniamos de webs full server side, pasamos al client side donde era lo nuevo y "mejor" y ahora todos quieren volver al ssr porque le estamos dejando mucha carga al usuario. Y creo que como todo es "depende".
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.
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
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.
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.
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!
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.
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.
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.
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)
Completamente de acuerdo, hay que ser más multidisciplinar. De hecho, no soy un especialista en programación y hace un tiempo puedo perfectamente automatizar procesos con IA y poder hacer servicios puntuales empresas. Y una app con IA ya es otro tema.
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.
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!
CUALQUIERA. En 20:08 empezás a comentar el quid del asunto. El problema es que no entendés la INGENIERÍA de software. Decís que surgen los problemas surgen cuando incrementás una versión y tenés (micro) servicios dependientes... ERROR. Los microservicios son INDEPENDIENTES!!! Por eso les fallan y los odian, porque no entienden cómo deben funcionar. ERROR 2) Decís que al incrementar versiones separadas hay que generar diferentes tipos de pruebas, independientes y eso es complicado. Eso es no saber los conceptos de TESTING, integración continua, por lo menos. Ambientes de prueba. POR SUPUESTO que el testing es independiente y separado en el contexto de cada (micro) servicio. Si algo falla después, es por la carencia de tests de INTEGRACIÓN. Estimado, como arquitecto de software, le diré que el problema de su título tan POLÉMICO se debe a la falta de conocimiento. Saludos cordiales, Angel
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.
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
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. 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.
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
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
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
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.
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.
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.
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.
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.
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
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.
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.
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!
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.
Volvera los inicios de PHP cuando se construia un trozo de interfaz como un componente en el servidor y se recibia con ajax para pintarlo? simpre lo hice asi pero pense que lo hacia mal😅, bueno lo hacia asi porque no tenia compañeros programadores
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
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.
Hola Antonio. Me ha saltado este vídeo mientras estaba programando. Como no te conocía y el título a priori me parecía interesante, me he quedado a escucharlo, pensando en que igual estaba a punto de descubrir un nuevo paradigma de la programación. Ahora que ha terminado, igual me he perdido alguna parte o algo, porque no he acabado de enlazar el tema de los microservicios con todo lo que has explicado. Seguro que será error mio por estar a tres cosas a la vez y tal vez me lo vuelva a ver más adelante. Yo con lo que me he quedado ha sido con la definición que has hecho de los grupos de trabajo actuales, con la que obviamente estoy de acuerdo, también con el tema de especialización con lo que no coincido contigo (ahora te comentaré) y sobre las aplicaciones monolíticas, modulares, mantenibles, etc... Sobre los equipos de trabajo, en mi experiencia están compuestos por las personas necesarias. El PM, aunque solemos burlarnos de él diciendo que su trabajo consiste en hacer reuniones todo el día, es un perfil que puede ser muy útil o muy prescindible, según lo bueno que sea ese PM. El tech lead encaja siempre y cuando sea un rol que tenga más experiencia que los propios programadores y sepa coordinar un equipo, si no, obviamente es un gasto prescindible. Y así con todos los roles. Yo como programador freelance fullstack que prefiero trabajar como backend, te puedo maquetar, te puedo montar un angular y hacer todo lo que puede hacer un frontend, pero no estaré en mi salsa. Conmigo puedes ahorrarte un frontend y mandarme tareas que no me gustan, que las haré sin ningún problema, pero las horas de programación están ahí... Un sprint pueden ser 20 horas de front y 20 de back, o 40 de un full stack pero en realidad no ahorras nada, simplemente reduces el número de personas manteniendo la carga de trabajo. ¿Es necesaria tanta gente en un equipo? Si y no... Depende de que se necesite en el proyecto y de que esos miembros hagan su trabajo. Lo que no suele salir muy bien es... Esto es demasiado caro, vamos a ir recortando y ya saldrán las cosas. Ese es el principio de un proyecto desastroso. Sobre la especialización ya depende de cada programador. Yo siempre he querido saber hacer de todo pero estar especializado en unas tecnologías concretas. Yo llevo 14 años con PHP y Javascript, enfocado en Drupals y Symfony pero he tocado Unity, Python, NodeJS... Incluso he llegado a programar un Arduino para una prueba técnica porque nadie quería hacerlo. Pero a la hora de la verdad, una empresa busca un senior especializado en Symfony o Drupal y viene a mi en lugar de pillar a un programador con experiencia en Wordpress. Además de que se paga algo mejor. Y bueno, comento algo sobre los microservicios que esto está quedando demasiado largo. Yo siempre he preferido trabajar en proyectos monolíticos. Me parecen mucho más simples de mantener a la larga. Para eso está la documentación y las pruebas unitarias, para cuando tocas algo no se desplome todo. Tampoco te hace API-dependiente ni te obliga a duplicar funcionalidades. Pero como todo, si necesito crear microservicios, los creo y ya está. Al final, para hacer rentable y escalable un proyecto, contra más opciones tengas, mejor. Por eso te digo que no acabo de entender la idea de "terminemos con los microservicios". En fin... ya me volveré a ver el vídeo para ver si veo mejor el proposito sugerido en el título. Un saludo.
Hola, gracias por comentar! Tranquilo, no intento iniciar una revolución, la estructura que muestras de un equipo está muy bien, lo que comento en el vídeo es que precisamente me estoy encontrando con muchos proyectos que están aplicando micro servicios en proyectos que realmente lo único que se consigue así es aumentar la complejidad del proyecto y la gestión de forma brutal, la intención es solamente que, antes de aplicar esa arquitectura, párate muy bien a plantearte si es necesaria, por lo que estoy viendo yo desde hace unos pocos años, muchas veces no lo es
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.
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
Totalmente de acuerdo, estoy liderando un equipo con el Backend de microservicios y me tarde 3 dias completos en entenderlo y terminar 1 ticket, que al final tuvo 5 Pull requests de cada uno de los servicios, API gateway y frontend, todo esto sin siquiera tener 1 solo usuario activo en dicha app (aun no se lanza al publico). Honestamente creo que Next.js v14 viene a perfilarse en el Monolito perfecto, pues maneja SSR, Edge functions (para streaming, muy necesario con IAs). Escribir directamente en el component de react, ahora server component, codigo que solo se ejecutara en el servidor, este framework me parece excelente para startups en conjunto con Vercel, para que se escale automaticamente.
Gracias por el comentario! ufff, microservicios para la primerísima versión lo veo cuando menos arriesgado… por lo demás, he oído cosas muy buenas del framework aunque yo no soy un gran amante de JavaScript para backend, pero bueno, cada uno tiene sus manías… 😂😂😂
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.
Tremendo tema has tocado amigo, tengo experiencia en micro servicios, y desde mi punto de vista son muchas las cosas que deben cambiar, lo primero serian las actualizaciones, por ejemplo: yo comencé con .Net Core 3.1 , me toco actualizar esas API , a la 3.X , 4.0, 4.1 .... etc , (ojo si estoy de acuerdo que las tecnologías y lenguajes deben mejorar) pero eso afecta muchísimo el desarrollo y mantenimiento, prácticamente debes ser "muy rápido" en llevar a producción tu proyecto antes que salgan nuevas actualizaciones porque te quedas sin soporte muy rápido. Lo otro seria las metodologías agiles, si es verdad son buenas, pero yo trataría de crear una serie de reglas estándar que se apliquen "a los entornos de desarrollo IDE etc" a ver si se reduce la cantidad de personas necesarias para sincronizar un proyecto, porque a empresas grandes no impacta mucho pero en StartUps es muy difícil. esto es solo una pequeña opinión no quiero aburrir , pero podría discutir este tema por horas, te invito a que continúes hablando sobre ello, es muy interesante , saludos.
Los MS tienen ventajas y contras que dificultan mcuho su implementacion. Imagina un patron saga en microservicios, donde tienes que orquestas varios en una transaccion.. eso es un lio. Ahi un monolito vendria de maravilla pero hay que analizar cada caso. LOs Ms son utiles para dividir proyectos muy grandes con grandes equipos de desarrollo y poco tiempo.
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
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
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
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.
Excelentes puntos de vista. Solo me quedó una duda ¿Por qué tendría que ser una nueva opción de integración o acoplamiento el hecho de hacer rendering desde el servidor para enviar HTML? Me parece que al final ahí estarían los 2 monolitos, aunque el front sin la tarea de renderizar y procesar Json. No veo la ayuda... Saludos!!
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..
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
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!
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. 👏
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
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.
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.
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.
Muchos problemas que comenta también aplican para monolitos, subir de versión así sea de un monolito puede ser un servicio, en realidad depende también del nivel de usuarios del tamaño de la empresa, un monolito para una empresa grande no funcionaría
Hay varias soluciones arquitecturales en ingeniería de software que prevee estas formas de implementación del software. Por ejemplo, la más vieja y muy conocida, la programación modular. Si se aplica bien este concepto, cualquier sistema software es "facilmente" escalable. Si desde un inicio se diseña orientando el software a una arquitectura modular, cada módulo tendrá su interfáz y sus dependencias definidas. Primeramente se despliega como un monolito, todos los módulos en un mismo proceso compartiendo la misma memoria. Luego cuando se empieza a demandar más una funcionalidad, se puede separar ése módulo a un proceso separado, siempre respetando su interfaz y dependencias. Los mismo con los demás módulos. A medida que la demanda aumenta en una característica del software, se va desacoplando del monolito. Esta es una forma burda de pensarlo. Cómo todo cambio, implica cierto grado de complejidad, la transición...
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 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
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
No hace falta dejar de usar microservicios, hace falta usarlos cuando sea necesario. No tiene sentido pasar directamente a una arquitectura distribuída si no tienes diferentes equipos que puedan dedicarse a cada servicio, si no tienes los suficientes dominios (dominio en términos DDD), si no tienes una cultura CI/CD en la empresa... En cuanto al tema de la especialización... hace ya tiempo que viene desterrándose en las grandes empresas. Yo he estado hasta hace poco trabajando en un gran banco y hace ya un par de años se cargaron a los QA y fuimos los desarrolladores los que fuimos incorporando test automation para los E2E. Otro paso que se dio fue el que los desarrolladores backend empezásemos a asumir tareas de devops En la empresa en la que estoy actualmente (también multinacional) somos los desarrolladores backend los que provisionamos nuestra propia infraestructura con Terraform y adptamos nuestros pipelines de CI/CD en base a templates que nos proporciona el equipo de CI/CD. Creo que como bien dices, la época del dinero barato no va a volver y con ello tampoco va a volver la época de la mega especialización
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)
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.
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
¡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...
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.
Qué buena tu decisión, hermano. ¿Podrías mostrarme tus apps? ¿Las tienes en la Play Store? Y si es así, ¿de qué son? O, ¿cómo trabajas como freelancer actualmente?
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
yo comence a trabajar en una pequeña empresa familiar hace un tiempo atras, experimenté de primera mano los desafíos de una arquitectura monolítica mal organizada. No contar con una estructura bien planificada genera múltiples problemas y limita la escalabilidad. Además, como se menciona en el video, depender exclusivamente de una única estructura puede volverse un obstáculo, especialmente al intentar adaptarse a nuevas necesidades o tecnologías.
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!
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.
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.
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 😅
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
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
Muchas gracias por el video. Soy desarrollador y he ido notando esa moda por microservicios que muchas veces no analiza bien el impacto. Dividir, seguro, pero no solo por moda, sino por necesidad. Un equilibrio creo yo.
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
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.
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.
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
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.
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 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.
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.
Entiendo perfectamente el punto compañero, después de superar el código espagueti, llegamos a la infraestructura espagueti.
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.
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
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.
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)
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.
Excelente análisis, creo que el principal problema que se maneja en la industria es que se quiere hacer de todo una bala de plata,
nos movemos en un bucle donde nos vamos del punto A al punto B para luego volver al punto A y asi sucesivamente.
Ya sea microservicios vs monolito, serverless vs serverful, ssr vs csr y asi con todas las arquitecturas, patrones de diseño, etc.
Como veniamos de webs full server side, pasamos al client side donde era lo nuevo y "mejor" y ahora todos quieren volver al ssr porque le estamos dejando mucha carga al usuario.
Y creo que como todo es "depende".
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.
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
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.
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.
Este era el mejor sonido de fondo de tus videos!
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!
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.
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.
Buen canal, esperemos crezca y puedas subir contenido mas seguido! un abrazo, sigo viendo el video, excelente tema
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.
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.
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)
Completamente de acuerdo, hay que ser más multidisciplinar. De hecho, no soy un especialista en programación y hace un tiempo puedo perfectamente automatizar procesos con IA y poder hacer servicios puntuales empresas. Y una app con IA ya es otro tema.
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.
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!
CUALQUIERA.
En 20:08 empezás a comentar el quid del asunto.
El problema es que no entendés la INGENIERÍA de software. Decís que surgen los problemas surgen cuando incrementás una versión y tenés (micro) servicios dependientes... ERROR. Los microservicios son INDEPENDIENTES!!! Por eso les fallan y los odian, porque no entienden cómo deben funcionar.
ERROR 2) Decís que al incrementar versiones separadas hay que generar diferentes tipos de pruebas, independientes y eso es complicado. Eso es no saber los conceptos de TESTING, integración continua, por lo menos. Ambientes de prueba. POR SUPUESTO que el testing es independiente y separado en el contexto de cada (micro) servicio. Si algo falla después, es por la carencia de tests de INTEGRACIÓN.
Estimado, como arquitecto de software, le diré que el problema de su título tan POLÉMICO se debe a la falta de conocimiento.
Saludos cordiales,
Angel
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.
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
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. 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.
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
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
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
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.
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.
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 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.
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.
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 🥲
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
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.
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.
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!
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.
Volvera los inicios de PHP cuando se construia un trozo de interfaz como un componente en el servidor y se recibia con ajax para pintarlo?
simpre lo hice asi pero pense que lo hacia mal😅, bueno lo hacia asi porque no tenia compañeros programadores
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
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.
Hola Antonio. Me ha saltado este vídeo mientras estaba programando. Como no te conocía y el título a priori me parecía interesante, me he quedado a escucharlo, pensando en que igual estaba a punto de descubrir un nuevo paradigma de la programación. Ahora que ha terminado, igual me he perdido alguna parte o algo, porque no he acabado de enlazar el tema de los microservicios con todo lo que has explicado. Seguro que será error mio por estar a tres cosas a la vez y tal vez me lo vuelva a ver más adelante.
Yo con lo que me he quedado ha sido con la definición que has hecho de los grupos de trabajo actuales, con la que obviamente estoy de acuerdo, también con el tema de especialización con lo que no coincido contigo (ahora te comentaré) y sobre las aplicaciones monolíticas, modulares, mantenibles, etc...
Sobre los equipos de trabajo, en mi experiencia están compuestos por las personas necesarias. El PM, aunque solemos burlarnos de él diciendo que su trabajo consiste en hacer reuniones todo el día, es un perfil que puede ser muy útil o muy prescindible, según lo bueno que sea ese PM. El tech lead encaja siempre y cuando sea un rol que tenga más experiencia que los propios programadores y sepa coordinar un equipo, si no, obviamente es un gasto prescindible. Y así con todos los roles.
Yo como programador freelance fullstack que prefiero trabajar como backend, te puedo maquetar, te puedo montar un angular y hacer todo lo que puede hacer un frontend, pero no estaré en mi salsa. Conmigo puedes ahorrarte un frontend y mandarme tareas que no me gustan, que las haré sin ningún problema, pero las horas de programación están ahí... Un sprint pueden ser 20 horas de front y 20 de back, o 40 de un full stack pero en realidad no ahorras nada, simplemente reduces el número de personas manteniendo la carga de trabajo.
¿Es necesaria tanta gente en un equipo? Si y no... Depende de que se necesite en el proyecto y de que esos miembros hagan su trabajo. Lo que no suele salir muy bien es... Esto es demasiado caro, vamos a ir recortando y ya saldrán las cosas. Ese es el principio de un proyecto desastroso.
Sobre la especialización ya depende de cada programador. Yo siempre he querido saber hacer de todo pero estar especializado en unas tecnologías concretas. Yo llevo 14 años con PHP y Javascript, enfocado en Drupals y Symfony pero he tocado Unity, Python, NodeJS... Incluso he llegado a programar un Arduino para una prueba técnica porque nadie quería hacerlo. Pero a la hora de la verdad, una empresa busca un senior especializado en Symfony o Drupal y viene a mi en lugar de pillar a un programador con experiencia en Wordpress. Además de que se paga algo mejor.
Y bueno, comento algo sobre los microservicios que esto está quedando demasiado largo. Yo siempre he preferido trabajar en proyectos monolíticos. Me parecen mucho más simples de mantener a la larga. Para eso está la documentación y las pruebas unitarias, para cuando tocas algo no se desplome todo. Tampoco te hace API-dependiente ni te obliga a duplicar funcionalidades. Pero como todo, si necesito crear microservicios, los creo y ya está.
Al final, para hacer rentable y escalable un proyecto, contra más opciones tengas, mejor. Por eso te digo que no acabo de entender la idea de "terminemos con los microservicios". En fin... ya me volveré a ver el vídeo para ver si veo mejor el proposito sugerido en el título. Un saludo.
Hola, gracias por comentar! Tranquilo, no intento iniciar una revolución, la estructura que muestras de un equipo está muy bien, lo que comento en el vídeo es que precisamente me estoy encontrando con muchos proyectos que están aplicando micro servicios en proyectos que realmente lo único que se consigue así es aumentar la complejidad del proyecto y la gestión de forma brutal, la intención es solamente que, antes de aplicar esa arquitectura, párate muy bien a plantearte si es necesaria, por lo que estoy viendo yo desde hace unos pocos años, muchas veces no lo es
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.
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
Totalmente de acuerdo, estoy liderando un equipo con el Backend de microservicios y me tarde 3 dias completos en entenderlo y terminar 1 ticket, que al final tuvo 5 Pull requests de cada uno de los servicios, API gateway y frontend, todo esto sin siquiera tener 1 solo usuario activo en dicha app (aun no se lanza al publico).
Honestamente creo que Next.js v14 viene a perfilarse en el Monolito perfecto, pues maneja SSR, Edge functions (para streaming, muy necesario con IAs). Escribir directamente en el component de react, ahora server component, codigo que solo se ejecutara en el servidor, este framework me parece excelente para startups en conjunto con Vercel, para que se escale automaticamente.
Gracias por el comentario! ufff, microservicios para la primerísima versión lo veo cuando menos arriesgado… por lo demás, he oído cosas muy buenas del framework aunque yo no soy un gran amante de JavaScript para backend, pero bueno, cada uno tiene sus manías… 😂😂😂
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!
Tremendo tema has tocado amigo, tengo experiencia en micro servicios, y desde mi punto de vista son muchas las cosas que deben cambiar, lo primero serian las actualizaciones, por ejemplo: yo comencé con .Net Core 3.1 , me toco actualizar esas API , a la 3.X , 4.0, 4.1 .... etc , (ojo si estoy de acuerdo que las tecnologías y lenguajes deben mejorar) pero eso afecta muchísimo el desarrollo y mantenimiento, prácticamente debes ser "muy rápido" en llevar a producción tu proyecto antes que salgan nuevas actualizaciones porque te quedas sin soporte muy rápido. Lo otro seria las metodologías agiles, si es verdad son buenas, pero yo trataría de crear una serie de reglas estándar que se apliquen "a los entornos de desarrollo IDE etc" a ver si se reduce la cantidad de personas necesarias para sincronizar un proyecto, porque a empresas grandes no impacta mucho pero en StartUps es muy difícil. esto es solo una pequeña opinión no quiero aburrir , pero podría discutir este tema por horas, te invito a que continúes hablando sobre ello, es muy interesante , saludos.
Los MS tienen ventajas y contras que dificultan mcuho su implementacion. Imagina un patron saga en microservicios, donde tienes que orquestas varios en una transaccion.. eso es un lio. Ahi un monolito vendria de maravilla pero hay que analizar cada caso. LOs Ms son utiles para dividir proyectos muy grandes con grandes equipos de desarrollo y poco tiempo.
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
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
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
Me parecio interesante lo que aqui se plantea por el expositor como por los que presentan sus puntos de vista los felicito
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.
Excelentes puntos de vista. Solo me quedó una duda ¿Por qué tendría que ser una nueva opción de integración o acoplamiento el hecho de hacer rendering desde el servidor para enviar HTML? Me parece que al final ahí estarían los 2 monolitos, aunque el front sin la tarea de renderizar y procesar Json. No veo la ayuda... Saludos!!
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..
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
Totalmente de acuerdo con cada palabra.. la pregunta que me hago es.. ¿No será el momento de quitarles el mote de 'Escalables y Mantenibles'?
Muy interesante! Apoyo la idea, También tomar en cuenta el tema de los datos que son el alimento de la IA
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!
@@inteligencia_artificial_tech Yo pienso que es como la mecánica cuantica, las reglas cambian cuando las cosas son muy pequeñas o muy grandes.
Escuche todo el video, excelente opinión
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
Tiene mucho sentido, trabajo en una empresa donde parece haber una espidemia de microservicesitis
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
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.
Estoy de acuerdo contigo,
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.
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.
Muchos problemas que comenta también aplican para monolitos, subir de versión así sea de un monolito puede ser un servicio, en realidad depende también del nivel de usuarios del tamaño de la empresa, un monolito para una empresa grande no funcionaría
Hay varias soluciones arquitecturales en ingeniería de software que prevee estas formas de implementación del software. Por ejemplo, la más vieja y muy conocida, la programación modular. Si se aplica bien este concepto, cualquier sistema software es "facilmente" escalable. Si desde un inicio se diseña orientando el software a una arquitectura modular, cada módulo tendrá su interfáz y sus dependencias definidas. Primeramente se despliega como un monolito, todos los módulos en un mismo proceso compartiendo la misma memoria. Luego cuando se empieza a demandar más una funcionalidad, se puede separar ése módulo a un proceso separado, siempre respetando su interfaz y dependencias. Los mismo con los demás módulos. A medida que la demanda aumenta en una característica del software, se va desacoplando del monolito. Esta es una forma burda de pensarlo. Cómo todo cambio, implica cierto grado de complejidad, la transición...
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.
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 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
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
No hace falta dejar de usar microservicios, hace falta usarlos cuando sea necesario. No tiene sentido pasar directamente a una arquitectura distribuída si no tienes diferentes equipos que puedan dedicarse a cada servicio, si no tienes los suficientes dominios (dominio en términos DDD), si no tienes una cultura CI/CD en la empresa...
En cuanto al tema de la especialización... hace ya tiempo que viene desterrándose en las grandes empresas. Yo he estado hasta hace poco trabajando en un gran banco y hace ya un par de años se cargaron a los QA y fuimos los desarrolladores los que fuimos incorporando test automation para los E2E. Otro paso que se dio fue el que los desarrolladores backend empezásemos a asumir tareas de devops
En la empresa en la que estoy actualmente (también multinacional) somos los desarrolladores backend los que provisionamos nuestra propia infraestructura con Terraform y adptamos nuestros pipelines de CI/CD en base a templates que nos proporciona el equipo de CI/CD.
Creo que como bien dices, la época del dinero barato no va a volver y con ello tampoco va a volver la época de la mega especialización
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)
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.
En mi caso utilicé mucho ssr, pero vi que los frameworks se fueron quedando atrás en la gestión de recursos
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
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.