Muerte por mil microservicios
(renegadeotter.com)- La cultura de adoptar microservicios como si fueran la opción por defecto ha aumentado costos y complejidad para resolver problemas que no existen, no problemas reales de escala
- El aislamiento del ecosistema de JavaScript/Node.js, las prácticas estilo FAANG y la abundancia de capital de riesgo se combinaron para crear un ambiente en el que incluso las startups imitaban arquitecturas de escala web
- Aunque existan Docker y Kubernetes, las dificultades de los sistemas distribuidos —como desarrollar, depurar, desplegar, probar y asegurar resiliencia— no desaparecen
- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow y WhatsApp comenzaron con codebases monolíticas o todavía mantienen un monolito en el núcleo
- La mayoría de las empresas no llega a la escala que realmente requiere sistemas distribuidos, así que en la práctica conviene separar servicios solo cuando haya una carga claramente aislable y escalable
Una cultura que idolatra la complejidad
- La sátira que intenta explicar sin éxito un laberinto de microservicios para obtener un solo dato, como la fecha de cumpleaños de un usuario, apunta a la sobrediseñación de la cultura tecnológica actual
- El problema es que el objetivo cambió: en vez de resolver los retos inmediatos, se quema dinero intentando resolver problemas que no existen
- La crítica a JavaScript y Node.js no trata solo de una tecnología concreta, sino del riesgo de los ecosistemas de software cerrados que obligan a reaprender lecciones ya conocidas
- La industria ya había vivido antes choques contra muros de complejidad como CORBA y SOAP, y luego tuvo que corregir el rumbo
Qué condiciones hicieron popular a los microservicios
- Desarrolladores que usaban JavaScript para el navegador empezaron a llamarse “full-stack” y se metieron al desarrollo de servidores y al código asíncrono; Node al principio se parecía más a un proyecto personal de aprendizaje, y JavaScript temprano era una opción con muchos problemas para desarrollo backend
- Como si el mundo fuera de Node prácticamente no existiera, surgió una mentalidad dogmática donde la forma de hacer las cosas en Node parecía la única válida
- Después, gente proveniente de FAANG entró a startups y difundió como respuesta correcta “la forma en que lo hacíamos en Google”, sin importar contexto ni escala
- Un ejemplo típico era la presión de decir que sin un
User Preferences Serviceaparte no se podía escalar
- Un ejemplo típico era la presión de decir que sin un
- En la época de abundante capital de riesgo, mostrar crecimiento explosivo a inversionistas pasó a ser más importante que los ingresos, y las empresas contrataron rápido a costosos ingenieros de software para ponerlos a hacer “algo”
Los sistemas distribuidos siguen siendo difíciles
- Los microservicios se presentaron como “una nueva forma de escribir software escalable”, pero en esencia están ligados a problemas de sistemas distribuidos que existen desde hace mucho
- Antes, los sistemas distribuidos se veían como herramientas difíciles y riesgosas, casi un último recurso para problemas especialmente complicados
- En un sistema distribuido, todas estas tareas se vuelven más difíciles y tardadas
- desarrollo
- depuración
- despliegue
- pruebas
- asegurar resiliencia
- El desarrollo basado en microservicios no cuenta con herramientas estándar ni frameworks comunes, y aun en la década de 2020 trabajar con sistemas distribuidos solo se ha vuelto un poco más fácil
- Docker y Kubernetes no eliminan mágicamente la complejidad esencial de una configuración distribuida
Casos donde la simplicidad dio mejores resultados
- Resumen de 5 años auditando código de startups concluye que las startups exitosas adoptaban un enfoque Keep It Simple casi descaradamente
- Cambiar demasiado pronto a microservicios, depender de arquitecturas apoyadas en cómputo distribuido y diseñar alrededor de mensajería fueron trampas importantes que metieron a varias empresas en problemas
- Muchas startups construyen sistemas simples y de buen rendimiento, pero aun así sienten una falsa inferioridad por “no hacer microservicios desde el día uno”
- A la pregunta “si solo tenemos un monolito en Django y una instancia de MySQL mantenidos por unos cuantos ingenieros, ¿qué está mal?”, la respuesta casi siempre es “nada”
- Incluso ingenieros con experiencia pueden sentirse inadecuados en la cultura tecnológica actual, pero el problema real puede ser un entorno mezclado con exceso de confianza injustificado, desperdicio y efecto Dunning-Kruger
Empresas que crecieron con monolitos
- La idea de que no se puede crecer sin abandonar el monolito está cerca de ser un mito
- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify y StackOverflow comenzaron con codebases monolíticas, y algunas aún mantienen un monolito en el núcleo
- StackOverflow presume en su página de rendimiento que opera un sitio grande con poco hardware
- Shopify sigue usando un monolito en Rails y procesa miles de millones de trabajos con Resque, una herramienta ya probada
- WhatsApp creció muchísimo con un monolito en Erlang y unos 50 ingenieros
- Mantiene una organización de ingeniería pequeña, de alrededor de 50 personas
- Los equipos individuales tienen entre 1 y 3 personas y gozan de gran autonomía
- Prefieren pocos servidores y escalan verticalmente cada servidor tanto como sea posible
- Instagram fue adquirida por miles de millones de dólares con un equipo de 12 personas, y Threads sigue el modelo de Instagram
No hay que resolver problemas inexistentes
- La pregunta central es “¿qué problema estamos resolviendo?”
- Si el problema es la escala, se necesitan datos que muestren qué debe separarse en un servicio distinto y por qué
- Los sistemas distribuidos se crean por escala y resiliencia, pero también hay que contemplar situaciones donde el tráfico se vuelca sobre otros servicios cuando uno se pone lento o cae
- Los factores a considerar cambian según los patrones de uso y las características de carga del sistema
- backpressure
- circuit breakers
- colas
- jitter
- timeouts razonables en todos los endpoints
- mecanismos de protección para que cambios pequeños no provoquen una caída total
- La mayoría de las empresas no llega a la enorme escala que exige un sistema distribuido real
- Imitar a Amazon o Google sin tener su escala, experiencia ni recursos hace muy fácil desperdiciar tiempo y dinero
- Queda la advertencia de que un mal sistema distribuido puede ser peor que el propio problema de tener un sistema distribuido
El ideal y la realidad de servicios por equipo y APIs
- Intentar alinear una topología distribuida con la estructura de la empresa parte de la idea de que, si se divide el problema en piezas pequeñas, se vuelve más fácil
- El microservicio ideal es mantenido rigurosamente por un equipo dedicado, oculto detrás de una API versionada, elegante y retrocompatible, de modo que casi no haga falta comunicarse con otros equipos
- En la realidad, los canales de Slack se llenan de lanzamientos, bugs, cambios de configuración, breaking changes y anuncios
- Todos tienen que estar al tanto de todo el tiempo, y es común que equipos ya saturados terminen haciéndose cargo a medias de varios microservicios
- Conforme la gente cambia de puesto, también cambia la propiedad de los servicios, y el resultado termina siendo varios carritos de golf mediocres en lugar de un solo auto de carreras bien hecho
Lo que se pierde con los microservicios
-
Debilitamiento de DRY
- Los microservicios, por naturaleza, no son muy DRY, y cada servicio termina cargando boilerplate duplicado
- En microservicios pequeños, el peso del código de infraestructura puede crecer tanto que una instancia promedio se parezca más a código de “servicio” que a código de producto
- Incluso si se intenta extraer código compartido, todas las opciones traen dolor
- Si se crea una librería común, hay que definir una estrategia de versiones y actualizaciones
- Se pueden generar pull requests periódicos en todos los repositorios para forzar actualizaciones
- Si se junta todo en un monorepo, aparecen problemas propios de ese enfoque
- O se acepta cierta duplicación de código, o cada equipo vuelve a reinventar la rueda
-
Peor experiencia para desarrolladores
- La experiencia de desarrollador es la cantidad de fricción y esfuerzo que exige crear una nueva función o corregir un bug
- En un entorno de microservicios hace falta un mapa mental de todo el sistema para saber qué servicios levantar para una tarea específica, con qué equipo hablar y a quién preguntarle qué cosa
- Spotify creó Backstage para listar sus innumerables sistemas y servicios, lo cual da una pista de lo costoso que es este juego
- Las empresas que no son Spotify terminan improvisando soluciones internas, de las que no se puede esperar gran solidez ni portabilidad
- Iniciar un servicio nuevo también implica muchas cosas que deben automatizarse
- permisos de desarrollador en GitHub/GitLab
- variables de entorno y configuración básicas
- CI/CD
- revisiones de calidad de código
- configuración de code review
- reglas y protección de ramas
- monitoreo y observabilidad
- test harnesses
- infraestructura como código
- Si se usan varios lenguajes de programación, esta lista se multiplica por la cantidad de lenguajes
- Afinar toda esa automatización puede tomar meses, y eso obliga a elegir entre construir producto o construir herramientas
-
Dificultad de las pruebas de integración
- Que pasen las pruebas unitarias y las pruebas de un servicio aislado no responde por sí solo si el camino crítico completo sigue funcionando después de cada commit
- Las pruebas de integración en una configuración distribuida se tratan casi como un problema imposible, y se considera que ese lugar lo terminó ocupando la observabilidad
- La observabilidad se volvió toda una nueva industria, y exige no solo dinero sino también tiempo de los desarrolladores
- La observabilidad no funciona como un plugin que se activa y ya; hay que entender e implementar canary releases, feature flags y más
- Dividir el problema no hace que resolverlo sea más fácil, sino que entrega un paquete de problemas aún más difíciles
Un monolito no es automáticamente buen código
- Defender el monolito no significa decir que “el monolito es buen código y los microservicios son mal código”
- En la práctica abundan los monolitos mediocres hechos por equipos apresurados o simplemente promedio
- Pero los sistemas distribuidos castigan mucho más cualquier atajo, mala decisión o modo de falla no contemplado
- Si no se operan siempre con un nivel alto, en un sistema distribuido se paga el precio
No tiene que ser micro; a veces basta con que sea un servicio
- Un servicio no necesariamente tiene que ser “micro”; en algunos casos basta con ser simplemente un servicio
- Algunas startups llegaron al nivel de crear un servicio por función, mostrando hasta dónde puede llegar un cargo cult sin validar
- Empezar con un monolito es una opción completamente clara
- El patrón “trunk & branches” también puede encajar en muchos casos
- El monolito principal se encarga de las funciones centrales, la “carne con papas” del producto
- Las cargas claramente identificables y que necesitan escalar por separado se asignan a servicios branch
- Un
Image-Resizing Serviceintensivo en CPU tiene más sentido como servicio aparte que unUser Registration Service - La pregunta clave para decidir una separación es si el volumen de registros por segundo realmente exige escalado horizontal independiente
El retroceso de la moda y la elección pragmática
- Parece que el sobrecalentamiento de los microservicios se está enfriando, y conforme se endurece el flujo de capital de riesgo el mercado está empujando a las empresas a tomar decisiones más sensatas
- Gastar dinero en una arquitectura de escala web sin tener problemas de escala web no es sostenible
- Si necesitas ir de Nueva York a Filadelfia, una solución adecuada al problema es comprar un boleto de Amtrak de 90 minutos, no construir una nave espacial compleja
1 comentarios
Opiniones de Hacker News
Soy una de las personas que ha defendido con fuerza los microservicios, ayudé a construir la plataforma de Netflix y he viajado por el mundo predicando sus ventajas, pero cuando asesoro a startups casi siempre les digo que empiecen con un monolito
Es mucho más fácil mantener una sola base de código y una sola base de datos, y eso puede escalar durante bastante tiempo. Si usas un almacén clave/valor como DynamoDB, pierdes algunas funciones relacionales, pero puedes aguantar más
También puedes desplegar un monolito en Lambda y obtener las ventajas de Lambda sin dividirlo en servicios
Solo después de crecer conviene separar en microservicios, con sus propios almacenes de datos, las partes que necesiten escalar de forma independiente o desplegarse por separado
Los microservicios consumen como mínimo 25% del tiempo de ingeniería solo en mantener la plataforma, así que no valen la pena si no puedes recuperar esa eficiencia
Mientras estás creciendo —y en la mayoría de los casos— es mejor no usar microservicios en absoluto
Y, por favor, no dividan los datos. Los datos son mucho más complejos de gestionar que el código
Siempre puedes hacerlo más complejo después. Puedes separar partes de un monolito y convertirlas en servicios; claro que es difícil, pero no se compara con sacar del sistema una complejidad que ya metiste
Quien haya intentado volver a convertir varios microservicios en un monolito sabe que normalmente es una cantidad de trabajo parecida a hacerlo de nuevo desde cero
Si quisieran, estos productos realmente podrían correr el entorno de producción en una laptop
En mi trabajo anterior hicimos una fiesta de microservicios para 300 clientes. Era un negocio donde llegar a unos miles ya era un éxito, y decenas de miles habría sido un gran éxito
Como normalmente no se dedica 25% del tiempo de ingeniería a mantener la plataforma, termina siendo imposible ejecutarla localmente y el entorno de producción queda apenas sostenido con cinta adhesiva
En una entrevista reciente me pidieron diseñar un sistema para “500 millones de usuarios concurrentes”, pero esa empresa era más bien del tipo con pocos clientes y altos ingresos por cliente
Todavía no sé si era una prueba para ver si señalaba que 500 millones es una cifra absurda, cerca del 10% de la población mundial conectada a internet, o si realmente creían que una startup podía llegar a eso
Respondí que me enfocaría en lo más simple: construir un monolito y validar las funcionalidades y si era un producto que la gente quería. No me contrataron
Trabajo en un monolito enorme con unos 800 contribuidores, y agregar un campo simple como la fecha de cumpleaños del usuario es igual de complejo. Pero no toda la complejidad es técnica: como toca el código de todos, requiere “alineación organizacional”
El diseño y las revisiones se repiten sin fin, se necesita la aprobación de al menos 2 arquitectos y se agrega a varios ciclos de planificación. El código real no toma ni medio día
En la revisión de código hay que alcanzar 90% de cobertura de pruebas, pero hay tantas pruebas que un solo PR queda demasiado grande, así que se divide en varios PR y entra a lo largo de varios lanzamientos semanales
Por eso se oculta detrás de feature flags, y actualmente hay 13,000 feature flags
Cuando llega a producción y se le agregan dashboards y monitoreo, se prende y se apaga varias veces. No estamos seguros de por qué la funcionalidad de cumpleaños rompió el servicio de facturación, pero parece ser la causa, así que habrá que analizarlo durante semanas
Al final, un año después, el ingeniero a cargo quizá reciba una buena evaluación y sea candidato a un ascenso. Y de inmediato lo asignan a otro proyecto roto que entra en su tercer año de desarrollo: permitir que los usuarios configuren su zona horaria
Ni los microservicios ni los monolitos son martillos universales ni balas de plata; tampoco son el mal en sí mismos. Ambos son herramientas con trade-offs, y se combinan con trade-offs de contexto distintos en cada organización
El problema es que los ingenieros se sienten fascinados por la complejidad y confunden “simplicidad” con “parche”, y que las organizaciones imitan ciegamente herramientas y patrones de arquitectura
Si creen que basta con usar una arquitectura o un patrón de diseño para obtener beneficios y los aplican ingenuamente, eso no va a ocurrir
Intenté tener siempre presente que la ingeniería de software es una lucha interminable contra la complejidad; a veces tuve éxito y a veces fracasé
Esta lucha hay que darla siempre y debe ser el valor prioritario. Si no, pasan cosas como esta
No hay arquitectura ni ideología que ponga fin a esta guerra; es simplemente la esencia de esta profesión
En producción no se permitía activar esos flags de release, y los desarrolladores tenían que eliminar el código del flag antes de las pruebas finales y el lanzamiento
Agrega un poco de trabajo por cada funcionalidad que necesita un flag, pero después de unos meses se nota mucho la reducción de complejidad en la base de código
Los microservicios no son una solución a un problema técnico, sino a un problema social
Un equipo con N ingenieros necesita N² de coordinación. Los equipos grandes caen en reuniones interminables, correos y revisiones de diseño; los equipos pequeños son más efectivos, pero tienen dificultades para mantener sistemas grandes
Dividir el sistema en subsistemas permite que cada equipo se concentre en su pieza del rompecabezas y reduzca la coordinación entre personas
Es cierto que los microservicios agregan complejidad y overhead, pero este enfoque permite que las organizaciones grandes construyan sistemas grandes rápidamente y los mejoren de forma iterativa
Ahora, en vez de conectarse directamente, se necesitan reuniones “cross-functional” entre equipos y una capa de comunicación compleja
Si encontraste una descomposición que casi no requiere conexiones entre subsistemas, entonces esas conexiones tampoco habrían existido en el sistema original y no habría habido problema de N²
Lo que he visto una y otra vez es un único equipo enorme donde “todos son responsables de todos los microservicios”, y al final nadie es responsable de nada
Para resolver un “problema de personas”, convierten un problema técnico trivial en un problema complejo de sistemas distribuidos
Ahora sí tienen un problema real
Soportaba dos tipos de bases de datos y también tenía un ejecutor de tareas escalable horizontalmente
En un momento éramos 35 personas, pero por despidos quedamos 7, y entonces empezamos a lograr mucho más. Porque se redujo muchísimo el tiempo dedicado a alinear a todos
Hubo muchas menos reuniones, aprobaciones, revisiones, planificación, retrospectivas y juntas de gestión; los desarrolladores tuvieron más criterio propio y simplemente sacaron el trabajo adelante
Las funcionalidades se resolvían fácilmente en la mitad del tiempo, y el 50% restante lo usábamos para pagar deuda técnica. Como reducíamos la complejidad sin piedad, también aumentó la velocidad para agregar nuevas funciones
Algunos proyectos necesitarán más gente, pero creo que hay un límite superior a la complejidad que se puede agregar a un sistema en un periodo dado
Si pasas el umbral y agregas más desarrolladores, la cantidad de funciones por semana se mantiene igual, pero todos trabajan un poco menos y dedican más tiempo a comunicarse
Si repites este proceso hasta llegar a miles de personas, agregar un solo campo toma meses
Me pregunto si han considerado moverlo a carpetas distintas
No hace falta modularizarlo con repositorio nuevo y configuración nueva de Docker. Simplemente usen carpetas
Un patrón que he visto a menudo es este: los CTO o VP actuales originalmente crearon el monolito o participaron en su creación
Nadie quiere decirle al CTO que ese código es pésimo. O quizá simplemente es código que necesita una renovación completa porque los tiempos cambiaron, y eso no tiene nada que ver con que sea un monolito
El CTO está ocupado con marketing o levantando inversión, así que no decide si microservicios o monolito; el arquitecto recién contratado toma la decisión
Todos celebran los microservicios. Encajan bien con la narrativa de una empresa tecnológica seria y de rápido crecimiento, y nadie quiere oponerse solo ni criticar al CTO
Casi nunca se recomiendan porque, de verdad, los microservicios sean el mejor trade-off. Es porque a la gente le gusta su trabajo, le gusta contratar a más personas y encajan bien con la narrativa de la empresa
Durante una gran reestructuración se puede reescribir y mejorar mucho código, y basta con llamarlo migración a microservicios
Al final se convierte en una forma de reescribir masivamente código viejo y malo sin herir los sentimientos del CTO, siguiendo a la multitud y bajo una causa que casi todos apoyan
Ya sea un ingeniero líder individual o un CTO/fundador, al mirar atrás uno termina concluyendo que pudo haberlo hecho mejor, y ve con alegría y horror las ventajas y desventajas de los patrones y procesos que el equipo siguió de buena fe
Me gusta aún más porque confirma mis sesgos
Llevo años diciéndolo, pero creo que la fiebre por los microservicios es más bien una excusa para que ingenieros promedio mantengan la demanda. La mediocridad la alimenta y, al mismo tiempo, mantiene en marcha a muchas empresas de tecnología
No hay suficientes ingenieros competentes que sepan manejar UNIX de verdad y construir sistemas minimalistas hermosos como StackOverflow
Por eso los microservicios como cortina de humo para tapar la mediocridad van a seguir existiendo. Más aún porque proveedores de nube como AWS se promocionan por todos los canales posibles y hacen que los responsables de tomar decisiones elijan ese camino
Si no hablas de nube, microservicios y frameworks nuevos no probados, te tratan como un viejo quedado en el tiempo
Aunque rara vez esos sistemas sean los más eficientes, robustos o seguros
Mi empresa actual crea software para uso interno de otras compañías; como mucho hay 200 usuarios concurrentes y no hay picos de uso
Sería un entorno perfecto para un servidor web común y no habría problemas inesperados de escalabilidad, pero todos quieren irse a la nube
Creo que la razón es que la dirección, los programadores e incluso los clientes fueron convencidos por el marketing de la nube y creen que la nube es genial
Las empresas no solo reflejan su organigrama: también cargan en el producto todas sus disfunciones y su lastre histórico
Aunque hace 5 años fuera una plataforma hermosa, con un modelo de datos y una API eficientes y bien diseñados, y código bien escrito y probado, después de 5 años puede convertirse en un desastre total por los constantes cambios de rumbo del CEO, pedidos de clientes de último minuto impulsados por ventas, gerentes de producto que agregan funciones que nadie necesitaba ni pidió, y falta de personal y de tiempo
Un día te encontrás frente a una enorme pila de deuda técnica, donde corregir bugs y agregar funciones tarda mucho más de lo necesario, y los microservicios suenan como el canto de sirena que te susurra que no hace falta quemarlo todo y empezar de cero
Puede parecer una sutileza, pero hay un punto más grande: las elecciones tecnológicas rara vez son el cuello de botella
En cambio, los microservicios tienen muchas más piezas móviles y modos de falla, así que son mucho más complejos; por eso es mucho más probable que causen problemas tanto los ingenieros promedio como muchos que no lo son
Parece que fracasamos en enseñar bien a la generación actual qué es lo importante al hacer este trabajo
Estoy en un equipo pequeño que está migrando a microservicios, así que lo entiendo. El mayor problema es la observabilidad
Cuando algo falla en producción, averiguar exactamente qué salió mal se vuelve una tarea enorme y tediosa
No alcanza con seguir los logs de una aplicación distribuida; hay que mirar al mismo tiempo los logs de varias aplicaciones distribuidas, con mensajes mezclados entre sí
Si tuviéramos herramientas para visualizar el tracing estaría bien, pero somos un equipo pequeño, el ancho de banda humano es limitado y todavía no tenemos esas herramientas
En cambio, el monolito tenía NewRelic integrado desde hace años. Había problemas de rendimiento, pero la mayoría se resolvieron con índices y algunas vistas materializadas
Es fácil identificar qué salió mal y, aunque el código sea viejo y esté lleno de condiciones de carrera, resolver los problemas en sí no es difícil
Me da miedo el momento en que haya que actualizar las instancias de base de datos separadas de cada microservicio. Ojalá hubiéramos tenido varias bases de datos en una sola instancia, pero esa arquitectura no está entre las opciones
El logging centralizado y el rastreo de llamadas entre servicios/ejecución de código no son algo nuevo. Pero a menudo se dejan para después y entonces uno termina en este tipo de situación desagradable
Como no pusieron las herramientas correctas desde el principio, el equipo queda más chico y más limitado, porque sabe poco o nada de lo que hacen los servicios
Las instancias de base de datos se pueden actualizar una por una. Si no hay bugs graves, como de seguridad, no hace falta apurarse solo porque sea posible actualizar
Leer textos así me resulta extrañamente terapéutico. Hace 10 años yo gritaba lo mismo, pero me trataban como un incrédulo y me decían que me callara
Disculpen que el paradigma de los “microservicios” me haya dejado un sabor amargo. Viví en carne propia lo que pasa cuando se adopta por completo una tecnología de moda sin entender del todo sus trade-offs
Hace mucho, cuando me contrataron en StumbleUpon, era la época en que alguien presentado como un doctor en ciencias de la computación de vanguardia intentaba reemplazar un monolito PHP que funcionaba bien y generaba ingresos por una arquitectura de microservicios en Scala/Java
El proceso de onboarding incluía una extraña reunión 1:1 con ese científico de la computación chiflado, que explicaba con fervor las ventajas de los microservicios y esquivaba hábilmente preguntas como “¿por qué crear un servicio distribuido solo para sumar una lista de números?” con gestos del tipo “no vas a entender por qué es mucho mejor”
Después de más de 30 contrataciones nuevas y más de 4 años de desarrollo intenso, a la empresa, que ya no generaba ingresos, solo le quedó un infierno distribuido más lento, con más bugs e imposible de depurar
El diseñador y arquitecto de todo decidió que ese era un buen momento para tomarse un “año sabático”, y poco después se agotó otra ronda más de inversión, vaya uno a saber cuál, y todos terminaron buscando trabajo
Este artículo, tomando prestada la analogía de Amtrak, se descarriló por completo
El autor parte de la premisa de que, si creaste microservicios pésimos, mágicamente todo habría estado bien con solo haber hecho un monolito
Es como decir que, aunque con el mismo nivel de diseño e ingeniería hubieras creado microservicios basura, si el objetivo hubiera sido un monolito el resultado habría sido dorado
A lo largo del texto también hay bastante autocomplacencia; el comentario sobre los desarrolladores full-stack de JS es un ejemplo
Pero casi no hay contenido desde una perspectiva real de ingeniería. Si esperas métricas o datos, lo que recibes es solo una perorata
Gestionar la complejidad para mantener bajo el costo de cambiar un sistema es un buen objetivo, pero eso no es lo que propone este artículo
Si hubiera reconocido este punto, o presentado datos o al menos una anécdota, el texto habría sido mejor
En mi equipo elegiríamos a un desarrollador frontend brillante y entusiasta que quiera ampliar su perspectiva y crecer como desarrollador full-stack, antes que a alguien que cree que ya lo sabe todo y que no tiene nada más que aprender
En mi trabajo actual estoy luchando contra esta tendencia, y en algunos equipos hemos tenido cierto éxito, pero en otros mucho menos. Esos equipos ahora están peleando contra el monolito distribuido que ellos mismos crearon
Irónicamente, todos los ex-FAANMG están del lado de apoyar el monolito
Parece que mucha gente pasa por alto que los microservicios son el resultado de un proceso iterativo. Al final, se trata de separar del monolito las partes que necesitan escalar
Los microservicios requieren mucha infraestructura básica que no quieres mantener a menos que realmente la necesites
La mayoría de las empresas ni siquiera tiene una plataforma adecuada para soportar ese patrón
Estoy de acuerdo. En nuestra empresa, las herramientas no funcionan bien, así que básicamente ya abandonamos el debugging
Para ejecutar un solo servicio en la máquina local, hay que ajustar los otros 9 para que se conecten con este servicio
Si siquiera haces una “funcionalidad” para un cliente, obviamente tienes que tocar al menos 2 servicios al mismo tiempo y mover más datos
Si pones un breakpoint en un lado, el otro lado hace timeout
Por eso todos los desarrolladores despliegan builds de release en una VM local y, sin hot reload, meten console.log, System.PrintLines(), _logger, y luego leen archivos de logs dispersos
Obviamente, yo pienso saltar de este barco
Sería mejor moverlo todo a tracing distribuido, pero para rastrear correctamente las solicitudes hay que unificar los metadatos de tracing en toda la plataforma, así que la inversión es mayor
Probablemente ayude más a operaciones que a desarrollo, pero aun así serviría. Con solo tener información decente de los tramos ya se obtiene mucha perspectiva para entender el caos
Si un breakpoint en un lado provoca timeout en el otro, me pregunto si no hay una forma de aumentar o desactivar los timeouts en modo desarrollo