no creo que el problema sea si es monolítico u orientado a servicios, creo que el tema es de como organizar una arquitectura de soluciones

Excelente video! coincido plenamente! Trabajo como programador desde 2004 y en los ultimos años solo programo mis propias apps. Vi tanto caos, en los equipos que integre, que decidi vivir unicamente de mis propias fuentes de ingresos. No solo el problema esta en el exceso de microservicios sino en el exceso de herramientas a usar y mil formas intrincadas de producir que lo unico que hacen es disminuir el tiempo productivo y la capacidad de dar respuestas eficientes. Hice de todo para optimizar mi forma de desarrollo.. desde crear mi ORM hasta mi propio framework con un lenguaje basado en XML. Siempre escuche el tipico consejo de reinventar la rueda es malo, pero hoy en dia mi productividad es mucho mas alta gracias a eso.

¡Al fin alguien serio por Dios que dice las cosas como son! Pensé que era el único, jaja... Puro marketing de software. Hoy en día, las empresas usan lo que está de moda, ni se preguntan si realmente en su contexto aplica. Y sí, tal cual, me ha tocado ver aplicaciones que son un simple CRUD y un login con 4 y 5 microservicios xD...

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.

@fullstackoficial

5 ай бұрын

Muchas gracias! Se nota que llevas algún que otro año peleando con arquitecturas, un saludo!

Hay varias cosillas que hay que señalar. Una arquitectura de microservicios tiene un propósito. La escalabilidad. Si en vuestros desarrollos no os encontráis con problemas de escalado o de aumento exponencial de los recursos que necesita un monolito para dar servicio a más y más usuarios entonces es que no se hicieron los deberes. La escalabilidad de un servicio de "tres o cuatro" pantallas, por ejemplo, porq es el servicio más demandado, es muucho más barato que escalar N funcionalidades que no demandan tantos recursos, pero al estar en monolito tienes que escalar el conjunto. Tarea que en cloud se vuelve imposible de asumir por ejemplo. Los equipos y la forma de gestión no es culpa de los microservicios. Un equipo "agile" es un equipo capaz de enfrentar de manera casi autónoma mucha incertidumbre en la definición de vuestro desarrollo. Si en vuestro caso no se tiene este componente de "incertidumbre" se puede usar waterfall. De hecho antes del Hipe* este del agile y de que salieran scrum masters de cursillo express era un sistema residual. Digo todo esto porq el problema no es la metodología o el coste del equipo (están contratando ingenieros y gente muy especializada, si no se tiene dinero hay que dedicarse a otra cosa). El problema es la injerencia. En todos los proyectos, y digo todos. La capa de gestión se extralimita en sus funciones y no deja funcionar bien al equipo técnico tomando decisiones que no son las correctas o moviéndose por modas con el único propósito de hacer más atractivo el producto o el servicio. Hablar de costes de equipos en Agile y decir que son caros cuando a todas luces se están tomando decisiones no fundamentadas y ni hablar del ROI esperado del desarrollo es hacernos trampas al solitario y al que tenemos delante. Preguntémosle a Space X cuanto le sale el equipo de ingenieros que están con el Falcon Heavy, o con cualquier otro... Nos comentarán cifras acoj**, ahora bien, ¿ porq lo hacen ?. El ROI que esperan es muchísimo mayor. Podría seguir pero sinceramente ... creo que queda más o menos claro lo que quiero decir.

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.

@visitor404

5 ай бұрын

pero danos un ejemplo de a qué te refieres. sino es un comentario que dice nada

@carloss2202

5 ай бұрын

​@@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.

@jesuseduardonivialatorre4722

5 ай бұрын

Es lo mismo que con un monolito si no lo entiendes no los uses 😂

@miguelgd1985

5 ай бұрын

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

@jorgeluisguizagranobles2165

5 ай бұрын

​@@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.

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

@jymmy8312

5 ай бұрын

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.

@JS.Erick..

5 ай бұрын

amigo yo quiero estudiar eso, que ruta puedo seguir?

@oarangov

4 ай бұрын

@@jymmy8312 A vuelo de pájaro, se encargan de la integración continua y el despliegue continuo.

@jymmy8312

4 ай бұрын

@@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.

@galopezmu

4 ай бұрын

@@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.

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.

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.

@fullstackoficial

4 ай бұрын

No puedo estar mas de acuerdo con tu comentario

@leonx6637

4 ай бұрын

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

Buen canal, esperemos crezca y puedas subir contenido mas seguido! un abrazo, sigo viendo el video, excelente tema

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.

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 😅

@fullstackoficial

5 ай бұрын

Gracias por el comentario, veo que llevas algún tiempo peleándote con proyectos, oye, podría estar bien ese debate!

@aulavirtualjyl9578

5 ай бұрын

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.

@user-fc7eq5uk8z

5 ай бұрын

​@@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

@rubensanchez6954

5 ай бұрын

A que te refieres con desarrollo movil en decadencia?

@memoadian

5 ай бұрын

@@rubensanchez6954 Me gustaría saber también a que se refiere XD

Buen video amigo, yo no tengo mucha experiencia, hace casi 3 años que comencé a trabajar.. pero estoy a cargo de un equipo y me tocó diseñar un servicio y la mejor decisión fue hacer un monolito modular, aislando lo mejor posible cada módulo.. y si en el futuro se necesita, se puede transformar fácilmente esos módulos en microservicios

@victorvasquez9018

5 ай бұрын

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?

@lordexess

5 ай бұрын

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

@javiergavilanmerida2133

5 ай бұрын

@@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 😅

@lordexess

4 ай бұрын

@@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

@javiergavilanmerida2133

4 ай бұрын

@@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.

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.

@fullstackoficial

5 ай бұрын

Me ha encantado lo de monolith first, te lo compro!

@AS-ds7ss

5 ай бұрын

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 😅

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 🥲

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

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.

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!

Muy interesante! Apoyo la idea, También tomar en cuenta el tema de los datos que son el alimento de la IA

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.

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.

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.

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.

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

@dev_time

5 ай бұрын

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? 🤔

@yerkfrider

5 ай бұрын

@@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.

menuda Joyita de canal. Saludos de españa

Me parecio interesante lo que aqui se plantea por el expositor como por los que presentan sus puntos de vista los felicito

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.

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

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

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.

Entiendo perfectamente el punto compañero, después de superar el código espagueti, llegamos a la infraestructura espagueti.

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.

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.

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.

Muy buena reflexión!

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

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.

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 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.

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

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

Tiene mucho sentido, trabajo en una empresa donde parece haber una espidemia de microservicesitis

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. 👏

@fullstackoficial

5 ай бұрын

Gracias por comentar! Al final esto es una carrera de fondo, tú mismo con el tiempo vas sacando conclusiones

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.

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.

Escuche todo el video, excelente opinión

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!

Totalmente de acuerdo con cada palabra.. la pregunta que me hago es.. ¿No será el momento de quitarles el mote de 'Escalables y Mantenibles'?

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!!

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.

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.

Hola, Varios puntos buenos, los factores de éxito, profesionales experimentados. Por otro lado, he reflexionado y veo que el término ágil se usa convenientemente según a quien le preguntes y comparo el desarrollo de microservicios con metodología antiguas como los famosos prototipos, espiral e incluso aplicaciones por componentes. Finalmente la cultura del como vamos sin mayor conocimiento del proyecto, seguimiento no acompañamiento.

Totalmente de acuerdo. De hecho, estoy saliendo de un proyecto en el que inicialmente se planeó un monolito dada la necesidad y características del negocio del cliente. Cuando conocimos a detalle los flujos de trabajo, prácticamente tuvimos que optar por microservicios lo menos específicos posibles para evitar una modularidad excesiva. Al final, todo fue bien pero el despliegue de la aplicación ha sido lento y por partes complicado. Un saludo.

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.

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...

@OscarAndresPabonEstrella

5 ай бұрын

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

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!

@fullstackoficial

4 ай бұрын

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

@fullstackoficial

4 ай бұрын

En todo caso, gracias por comentar y exponer el caso

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.

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.

Estoy de acuerdo contigo,

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.

Es verdad que los microservicios conllevan muchos retos, y el diseño de la solución completa se vuelve más compleja, pero desde que me he adentrado al mundo de los microservicios me he dado cuenta que en realidad pocos saben realmente como implementar microservicios de manera adecuada porque muy pocos los entienden, entonces solo incrementan la complejidad del proyecto y no reciben los beneficios que los microservicios conllevan, microservicios no es solo partir la aplicación y ya, primero se debe de analizar si ese módulo que quieres convertir en microservicios realmente puede (y vale la pena) ser independiente del resto de la aplicación si no solo complicarás el proyecto y seguirás teniendo los mismos problemas e incluso más que en una aplicación monolítica, por otro lado estoy en desacuerdo contigo en el uso de JSON, los JSON son una maravillosa forma de comunicar BE y FE, son muy ligeros, versátiles y permiten mantener su independencia. Regresando a microservicios, si los microservicios ya dividían la aplicación en partes pequeñas ahora también tenemos FaaS así que esa parece ser la tendencia.

Estoy 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

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.

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.

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

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

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.

@fullstackoficial

5 ай бұрын

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!

@juliandavidtrejosrueda5273

5 ай бұрын

@@fullstackoficial Yo pienso que es como la mecánica cuantica, las reglas cambian cuando las cosas son muy pequeñas o muy grandes.

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.

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

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

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.

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.

@fullstackoficial

5 ай бұрын

Asi es, y con un uso muy uniforme de las distintas secciones funcionales de un proyecto

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

Clean Architecture y HATEOAS para lo que dices del json, también habrá que ir cambiando el paradigma de pensamiento hacia el tema de los servicios en la nube para reemplazarlos por sistemas distribuídos como blockchain, pero tranquilos, todavía quedan unos años para eso.

Yo tengo opiniones encontradas (por no decir q la solución “DEPENDE”) Por un lado me ha servido desacoplar las funcionalidades en microservicios porque me ha sido mas fácil mantener el código y añadir nueva funcionalidad, pero por otro lado al entrar en equipos donde ya tienen todo su sistema montado con 6 o 7 micros se me hizo casi imposible entender como funcionaba todo el flujo, seguir la traza de errores o identificar el estado y en que punto se había quedado. Entonces creo q lo mejor es no casarte con una solución sino d intentar dejar todo lo las simple posible y si vez q el sistema crece sacarlo en otro micro servicio pero evaluando la complejidad q se le añade.

En mi caso utilicé mucho ssr, pero vi que los frameworks se fueron quedando atrás en la gestión de recursos

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.

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

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.

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

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.

@fullstackoficial

4 ай бұрын

Gracias a ti por tu comentario, me parece interesantísimo lo que comentas, además basado en proyectos reales, un abrazo!

Si no mal entiendo, el framework de Elixir, Phoenix Liveview, hace eso del renderizado del lado del servidor.

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

Me has quitado las palabras de la boca, quizá veremos el resurgimiento de php para continuar con monolitos como lo propone Laravel. Evidentemente no seria para todos los proyectos pero si que para muchos no vale la pena desplegar una infraestructura tan compleja y costosa. Buen video, saludos .

Me gustaría saber si este análisis se complica o se simplifica al usar lambdas en AWS o se necesitaría más especialización para esto?

@fullstackoficial

5 ай бұрын

Pues en la práctica se suele complicar a no ser que esté muy bien documentado, por otra parte, la ara algunas cosas es muy útil. Yo intento no abusar de las funciones lambda, prefiero integrar con el API de AWS si se puede

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.

@fullstackoficial

4 ай бұрын

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)

Creo que mas el problema como en todos los proyectos es tener una buena arquitectura. La modulizacion resulto ser muy buena para hacer mas robustos los proyectos en escalabilidad de cargas y multi servidores. Pero como indica en el video el mantenimiento se volvera siempre complicado y creo al final AI se encargara de eso al final eventualmente reemplazar a los programadores. Al final no sera raro ver un DevOps AI. Un ejemplo es la modulacion de logs en Splunk AI que Cisco planea como solucion para QA

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.

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.

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á

@fullstackoficial

5 ай бұрын

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

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.

@fullstackoficial

5 ай бұрын

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!

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.

@cmargok

5 ай бұрын

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..

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.

Se podría decir que dependiendo del tamaño de la aplicación y de que tan masivo es su uso, se define si tiene sentido usar un monolito o microservicios.

@fullstackoficial

4 ай бұрын

O alguna otra arquitectura mixta, depende del análisis, esa parte es la importante

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.

@fullstackoficial

5 ай бұрын

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

Hola Antonio la arquitectura monolitica se puede dividir en capas o con arquitectura exagonal no todo es malo en la arquitectura monolitica solo es cuestion de un buen diseño de la solucion

@fullstackoficial

5 ай бұрын

Si si, si justo defiendo la arquitectura monolítica en el video

Totalmente de acuerdo,los microservicios son útiles más que todo para sistemas que sean de consumo masivo(estilo Netflix).

@buhito23

4 ай бұрын

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.

@monitorDevStudio

4 ай бұрын

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

A mi me gusta combinar, me gusta tener monolitos con todo en docker con todo bien montado y aislado para que si por x razón se necesita levantar otroa servidores para balancear o lo que sea sea con un par de comandos y ya... Aunque también depende de lo que se necesite, pero creo que en la inmensa mayoría no se necesita complicar la vida

El tema me encanta porque soy empresario y en nuestro mercado el desarrollo de software es necesario pero no hay tanto dinero para llevarlo a cabo. En nuestro caso hemos tomado la decisión de tener un monolito modular (5 módulos). Hasta no ver que es completamente necesario, no vamos a romper el monolito.

@fullstackoficial

4 ай бұрын

Muy buena decisión desde mi punto de vista, a veces perdemos la perspectiva de que un proyecto debe ser rentable y poder competir, en muchas ocasiones lo que hace que se pueda continuar es justo que sea viable económicamente, aunque sea el proyecto más bonito del mundo y el mejor hecho