Microservices (ENG)

Esto se debe a la forma en que funciona nuestro backend.

[#7 Jatetu]

Siendo una cosa chula, es la t'ipia gilipollez que se pone de moda y se trata de aplicar a todo, cuando fue concebida para muy pocos proyectos, muy espec'ificos. Como sus propios creadores han dejado claro en art'iculos.

[#13 honbu]

#7 Tienes a mano alguno de esos artículos? Estoy hasta los huevos de ver apis simples con k8s

[#28 Jatetu]

#13 Lo buscar'e hoy antes de que acabe (mi) el d'ia. He visto esto pero no es de los creadores:
https://techbeacon.com/app-dev-testing/why-your-project-may-not-be-ready-microservices
https://medium.com/swlh/stop-you-dont-need-microservices-dc732d70b3e0

PS: no los he le'ido.

[#45 honbu]

#28 Yo he leído este y me gustó bastante:
https://pythonspeed.com/articles/dont-need-kubernetes/

[#30 Jatetu]

#13 Estoy buscando pero no lo encuentro, creo que no era de Fowler sino del otro.

Mientras tanto, este art'iculo cita a Fowler unas observaciones que seguro que le joden bastante a los t'ipicos capullos que quieren hacerlo todo innecesariamente complicado:

Microservices are only viable for mature products

On the topic of starting from a microservice design, Martin Fowler observed that:

1. Almost all the successful microservice stories started with a monolith that got too big and was broken up.

2. Almost all the cases where a system that was built as a microservice system from scratch, ended up in serious trouble.

This pattern has led many to argue that you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile.

The first design is rarely fully optimized. The first few iterations of any new product are spent finding what users really need. Therefore, success hinges on staying agile and being able to quickly improve, redesign, and refactor. In this regard, microservices are manifestly worse than a monolith. If you don’t nail the initial design, you’re in for a rough start, as it’s much harder to refactor a microservice than a monolith.

[#31 Jatetu]

#13 Getting closer!!!

Este art'iculo habla del creador avisando que los microservices NO deber'ian de ser la arquitectura por defecto (que es lo que de'ia en el art'iculo que menciono, que s'olo es buena idea en unos pocos casos).

[#34 PacoJones]

#31 Sabes que en teclados con distribución UK puedes poner tildes, no? Te lo digo yo que ahora mismo estoy utilizando uno. Hay varios métodos pero el más rápido es AltGr+vocal, yo cambio de distribución al español al vuelo, me sé de memoria las teclas.

[#35 Jatetu]

#34 Lo s'e... pero esribo m'as en ingl'es y estoy mirando varias cosas a la vez... me vuelvo loco, lo siento.

[#37 PacoJones]

#35 Pues escribe sin tildes que es un coñazo leerte, se ve muy raro

[#39 Jatetu]

#37 Perdon.

[#61 Westgard]

#39 Perdón

[#63 ayana]

#35 Debes adecuar la definición del idioma del teclado a tu teclado físico. No importa el idioma en el que escribas, que eso es otro tema.

Es decir, no mires los settings de idioma. Mira en teclado.

[#66 trivi]

#35 EEUU internacional con teclas muertas

[#32 Pablosky]

#13 #7 Yo también quiero ver esos artículos si los tienes a mano.

Yo he visto un sito, uno al menos, en el que tiene sentido usarlo: Cuando se monta un servicio que tiene cientos de instancias paralelas que hacen "casi lo mismo" todas al mismo tiempo y se tienen que ver entre sí. En ese caso montarlo en K8s es una delicia.

Lo que no es una delicia es gestionar esos putos 500 microservicios de mierda, claro

Para todo lo que no sea algo así no le veo mucho sentido a montar K8s. Yo he llegado a ver un Nifi (el trasto de la fundación apache para Big Data, que necesita máquinas físicas exclusivas o lo más parecido que se le pueda poner) corriendo en un K8s usando como excusa que "es que si se cae, Kubernetes lo reinicia" <

Debe ser que si lo montas de cualquier otra manera como servicio, si se cae no se reinicia...

[#33 Jatetu]

#32 No s'e, la verdad... conceptualmente es chulo, pero 1) los problemas de escalabilidad se pueden resolver de otras maneras 2) esto es caro 3) surjen otros problemas, como el c'omo se comunican entre ellos, race conditions, problemas de datos duplicados desactualizados o inconsistentes, etc...

Pero a ver, que molar mola.

Por cierto, verguenza me da decir que no s'e que son los K8s.

[#36 Pablosky]

#33 Kubernetes abreviado. Me leí un día el porqué, pero lo he olvidado...

[#40 Jatetu]

#36 ok, gracias.

[#44 migrad]

#33 y #36 el número corresponde al número de letras que hay entre la primera letra y la última k-ubernete-s. Lo mismo ocurre con i18n (i-nternationalizatio-n) y l10n (l-ocalizatio-n),

[#64 ayana]

#44 Demasiado poco mnemotécnico.

[#42 hablador_pasivo]

#33 Los microservicios, de hecho, no resuelven problemas de escalabilidad.

k8s = kubernetes

[#47 honbu]

#32 En mi opinión tiene sentido cuando tienes que escalar como loco en base a un montón de motivos y además tienes una cantidad grande y compleja de dependencias

[#60 lasi_zoillo]

#32 Yo trabajé en un sitio en el que tenían un nifi dentro de un k8s que no estaba en alta disponibilidad. La gente que quería el nifi lo montó en k8s para que tocaran menos los paquetones de operaciones

[#22 Zade]

#7 Bueno, cuidao que están los que usan ciertas arquitecturas por moda sin entender lo más básico de la arquitectura (que acaban haciendo monstruos que violan todos los principios de esa arquitectura), y luego están también los que no usan ciertas arquitecturas que no entienden porque la moda ahora está en odiarlas.

En muchos casos son la misma persona.

[#27 Jatetu]

#22 Estoy un poco desconectado del tema, si te digo la verdad. Qu'e arquitecturas se odian?

[#57 Pablosky]

#27 Kubernetes. Hay colgaos que han usado eso para montar un Wordpress. Para el que no lo sepa, necesitas un mínimo de 3 nodos master y 1 worker, pero montarlo así es una idiotez y lo normal es tener un mínimo de 5 máquinas. Entonces claro, 5 instancias en un proveedor cloud para un puto Wordpress...

[#65 Zade]

#27 Últimamente se ve mucho despistado echando pestes de Clean o Solid sin tener ni idea solo porque la nueva moda es odiar a la antigua moda

[#41 hablador_pasivo]

#7 Y no solo eso: fue concebida como una manera de facilitar la organizacion en equipos pequenos dentro de empresas grandes: cada equipo, un servicio.

En la realidad, unos te dicen que mejora la escalabilidad, el rendimiento, etc. Todo mentira.

[#58 Pablosky]

#41 Hombre, tanto como "todo mentira" no, si se monta bien bien de verdad. Pero claro, nadie lo quiere montar bien ya que cuesta pasta.

Entonces a veces ves maravillas como el "Cluster de Alta INDisponibilidad", un cluster que va tan sumamente justo de CPU y Ram que cuando se cae una máquina arrastra a todas las demás con ella

[#59 hablador_pasivo]

#58 Incluso montandolo bien, no mejora necesariamente la escalabilidad ni el rendimiento. Vamos, depende de lo que tuvieras antes, pero en general, las aplicaciones hechas con microservicios no son ni mas escalables ni mas rapidas.

Tiene otras ventajas, pero no esas.

[#6 gelatti]

Too old for this microshit

[#1 kampanita]

kubernetes sucks

[#4 ed25519]

#1 kubelnete el tu amiglo

[#53 O.OOЄ]

#1 Found the openstack guy.

[#48 hablador_pasivo]

#46 Esto no es asi. Un monolito puede escalar horizontalmente, el mundo esta lleno de ejemplos de ello. No tiene nada que ver una cosa con la otra.
De hecho, lo mas normal es que una aplicacion en forma de microservicios consuma muchos mas recursos (RAM y CPU) que una monolitica.

Lo que antes se hacia con 20 maquinas con 2 CPU sy 4 GB de RAM cada una, ahora necesitas 40 maquinas con 20CPU y 20GB de RAM, con kubernetes, para meter esos cientos o miles de instancias.

Por este tipo de malentendidos es por los que muchos "arquitectos" optan por microservicios, jodiendo a la empresa.

[#49 Adrian_203]

#48 Los recursos necesarios para escalar horizontalmente un aplicación monolito son mucho mayores. Por supuesto depende de las necesidades de cada caso.
Imaginemos que tenemos una parte de aplicación que se dedica a transformar ficheros pdf a png/gif/... porque tienes una pagina de estas de conversión. Si esta parte de la transformación está acoplada a la aplicación, necesitas duplicar la aplicación web muchas veces. Es mucho más y operativo extraer esa funcionalidad en un microservicio y orquestar los microservicios de transformación en función de las necesidades. ¿Para que voy a orquestar toda una web cuando lo que necesito es solo escalar la transformación que es el cuello de botella?.
En este caso la web como punto de entrada no necesita mucha escalabilidad y puede permanecer como monolito, mientras desacoplas la otra parte. Y por supuesto esto tiene su coste, porque una vez necesitas orquestar la fiesta de los microservicios ya te metes en mil historias.

[#51 hablador_pasivo]

#49 Imaginemos que tenemos una parte de aplicación que se dedica a transformar ficheros pdf a png/gif/... porque tienes una pagina de estas de conversión. Si esta parte de la transformación está acoplada a la aplicación, necesitas duplicar la aplicación web muchas veces. Es mucho más y operativo extraer esa funcionalidad en un microservicio y orquestar los microservicios de transformación en función de las necesidades. ¿Para que voy a orquestar toda una web cuando lo que necesito es solo escalar la transformación?.

Esto no tiene ningun sentido. Si tienes un monolito y escalas horizontalmente (supongo que ahora estas de acuerdo en que si que se puede), las partes que usen mas CPU y memoria la usaran de donde este disponible, es decir, de toda la maquina, y las partes que no necesiten tanto, pues no la usaran.
Con microservicios, tienes que estar pendiente de que funcionalidad necesita mas recursos y darselos. O usar un autoscaler, pero que anade mas complejidad para solucionar un problema introducido por la propia arquitectura.
Yo tengo experiencia en ambas arquitecturas, y los microservicios consumen muchos mas recursos, y requieren mas intervencion. Pero de calle. Esto lo puedo probar con numeros, pero obviamente no los voy a dar por aqui.

[#68 ostiayajoder]

#48 No.

Puedes escalar lo que quieras una aplicacion y meter 3000 servidores de aplicacion balanceados.

Pero BBDD tienes una, y los 3000 servidores se van a bloquear entre si al escribir en ella.

Los microservicios dividen la carga de las BBDDs y hacen que eso, tambien, pueda escalar.

Aparte, si, dividen mejor el trabajo en equipos y son mas faciles las subidas a produccion sin perdida de servicio.

[#69 hablador_pasivo]

#68 Los servicios monoliticos o, bueno, con otras arquitecturas que no sean microservicios, que no todo es blanco o negro, utilizan otras estrategias para escalar, desde soluciones noSQL, a caches, CQRS, etc. Tambien se puede coger una aplicacion no-monolitica y escribir datos en 2 o mas bases de datos, nada lo impide.

[#3 amlluch]

Joder ... ese es mi puto día a día trabajando en el fucking back end

[#20 MEV]

La cantidad de aplicaciones que deberían ser un monolito pero que el pesado de turno se ha empeñado en diseñar como un conjunto de microservicios con nombres chupiguays porque "xxx ventajas" y cuestan la vida de mantener/extender/cambiar es para echarse a llorar.

Y todo es porque "y si..". Y si... los cojones. Empieza con un monolito, encapsula bien las responsabilidades, descubre dónde te has equivocado y refactoriza lo que toque... y entonces, si te llegan X Millones de peticiones a una parte del servicio que necesita escalar de forma independiente, si cierta petición tiene un coste computacional muy alto y quieres re-escribirlo en Rust o lo que te de la gana, sólo entonces, empieza a extraer cosas.

Cuando he trabajado como arquitecto de software mi trabajo (y el de muchos compis mucho más experimentados que yo) la mitad de las veces era discutir con alguien y echar atrás intentos de usar microservicios por defecto en situaciones que estaba claro que iban a causar más daño que bien.

[#25 llorencs]

#20 En mi empresa, un compañero de trabajo me contó que para un producto empezaron a hacerlo en microservicios, porque el Gestor de Producto era un fan de los microservicios. Y tuvieron que volver atrás y restructurarla como una aplicación monolítica.

Luego hay productos que tienen sentido hacerse como microservicios.

#23 Pero es que hay aplicación que no esté montada al final sobre parches tras parches?

Incluso aplicaciones pequeñas, pueden acabar siendo así a menor escala. La haces para algo especifico, luego crece y le añades parches a ese código. Vuelve a crecer y le añades más parches... Ya que el diseño estaba pensado para una escala o funciones, y al final acaba creciendo en funciones y tamaño y eso son parches sobre parches, porque el diseño no estaba pensado que escalara de esa forma.

[#2 ed25519]

jajajajjaja como la vida misma

[#5 ayana]

#2 Hasta que pretendes usar Terraform.

[#70 ed25519]

#5 dios te salve the usar terraform.

[#23 PacoJones]

Lo he vivido sufrido, al final todo un castillo de naipes que daba miedo tocar. Y no pienses que el front-end está mucho mejor con tanto frameworks, dependencias, gestores de paquetes, herramientas,... pfffff
Al final te das cuentas que Internet está hecho sobre parches tras parches y patada palante.

[#50 dvdkrku]

Mi experiencia me dice que en la mayoría de proyectos lo que mejor funciona es modulith, a grosso modo, un monolito modular que sea fácil de partir en cachitos cuando algún servicio se hace muy demandante y es necesario escalarlo horizontalmente de forma aislada. No obstante, cada uno tiene su opinión

[#21 asterissco]

A no ser que que vayas a hacer un backend monstruoso y te compense meterte ahí, vamos, que ya es jodido que te quedes corto con un HAPROXY balanceando N apis monolíticas y la db replicada.

[#29 delsegura]

Estoy esperando la siguiente del versión del video cuando incluya los microfrontends

[#55 Desactivado]

#29 Pensaba que te lo habias inventado pero no

[#56 delsegura]

#55 https://micro-frontends.org/
que lo disfrutes

[#9 JovenCarcamal]

Tal cual. Incluidos nombres frikis

[#17 LaPoliticaNoVaDePartidos]

Ese product manager no tiene ni idea, hace tiempo que Dijkstra demostró que obtener la fecha de nacimiento de un usuario es computacionalmente imposible.

[#52 redscare]

Jajajaja, mola el video, me he sentido identificado

Alguna vez me ha pasado que me llega un tío de negocio y me dice 'de verdad es tan complicado hacer XYZ?'. Y yo... me alegra que me hagas esa pregunta! Tienes una hora para que te explique en detalle?

Y eso que en mi curro hay muy pocos micro-servicios... aunque si hay son tropecientos sistemas interconectados, cada uno de su padre y de su madre

[#54 samsaga2]

Microservicios y DDD están muy sobrevalorados. Como Netflix lo usa todo el mundo a usarlo también sin pensar en si realmente hace falta o no.

[#24 del_dan]

cual de los dos es Elon?

[#14 ElPerroDeLosCinco]

Me parto con los nombres de los servicios. A ver si alguien en mi empresa ve este vídeo y dejan de poner nombres cool a las cosas, en lugar de llamarlas de forma que se entienda para qué c*ñ* sirven.

[#62 lasi_zoillo]

#14 No se si odio más a los que ponen nombres estúpidos que nada tiene que ver o a los abstractos que llaman a todo Handler, Manager o Scheduler y tampoco sabes para que c2o sirven. Es como los que para arreglar un código espaguetti se dedican a meter capas de abstracción aleatorias obteniendo como resultado un código lasaña.

Para mi los microservicios son como un ventilador: Una ráfaga de aire fresco para quién se le ha quedado pequeño el monolito. También son una herramienta donde arrojar el código de los programadores que se dedican a hacer mierda.

[#67 ostiayajoder]

Monolito + hexagonal (con sus commands y sus queries) y a volar.

Si quieres microservicios pq necesites escalar sacarlos de ahi va a ser super sencillo...

[#38 Adrian_203]

La complejidad tecnica que se alcanza con los microservicios solo sale rentable cuando hay una cantidad muy grande de peticiones simultaneas y necesitas balancear recursos a lo bestia. Si no, meterte en esa mierda es un tiro en el pie.

[#43 hablador_pasivo]

#38 No, los microservicios no tienen mejor rendimiento, el balanceado de carga se puede hacer con o sin microservicios.

Los microservicios son una estrategia organizativa: asi, un equipo a cargo de un microservicio, puede hacer despliegues sin tener que coordinarse con toda la empresa.

[#46 Adrian_203]

#43 La arquitectura de microservicios tiene mejor rendimiento porque permiten un mayor escalamiento horizontal, mientras que las monoliticas para mejorar rendimiento necesitas escalar verticalmente.
Por supuesto que como este estructurada la arquitectura de los microservicios puede tener mayor o menor escalabilidad horizontal, pero está enfocado a ello.

[#26 Midiam]

Al final ninguna arquitectura es la ideal.

Todas tienen sus pros y sus contras. Ya al final dependerá a futuro cómo quieres que crezca y evolucione tu mapa de aplicaciones.

Porque vaya, he trabajado con empresas con n proyectos monolíticos, cada una usando su propia implementación de arquitectura, con sus propios lenguajes y eso a la larga se vuelve inmantenible si encima esas aplicaciones se tienen que acabar integrando entre si.

Al final es como todo, los puntos intermedios es lo ideal y siempre adaptándolo a cada necesidad.

[#8 Desactivado]

Entre progremitas e informáticos padefos, tenemos Meneame hecho una mierda

[#10 RGr8888]

#8 tu deves ser nuevo aquí

[#19 Jesulisto]

#10 Nuevo pero con gran potencia venenosa.

[#11 Battleship55]

#8 Habló el cancerbot...

[#12 emdi]

#8 Vete a barrapunto.com

[#15 Relator]

#8 Entonces, ¿quiere bolsa?

[#16 LaPoliticaNoVaDePartidos]

#8 Los informáticos padefos somos la espina dorsal de menéame, un respeto

[#18 kolme]

#8 ¿Nos tienes envidia, no da mucho dinero lo de ser troll profesional?