- "Monolith > apps > services > microservices"
- Primero, esto no es una regla; solo es mi opinión. Quienes han construido sistemas distribuidos a gran escala saben que en la práctica no funciona exactamente así y que hay que adaptarse
- Segundo, las etapas importan
- Si tu empresa tiene entre 5 y 50 personas, simplemente vayan con un monolito
- Si es una empresa de 10 mil personas, probablemente tendrá todo lo anterior. Pero hablemos de cómo cambió mi forma de pensar...
Empecemos por la definición
- monolith - xyz.com
- apps - abc.xyz.com
- services - dan soporte a las apps o al monolito; son infraestructura central o funciones clave de compliance; puede que no los escriba el equipo de apps (los mantiene infraestructura)
- microservices - unos pocos cientos de líneas de código, en su mayoría de un solo uso; podrían/deberían ser una librería o un SDK
Why? : básicamente por "Speed & Risk"
- #1 Es más fácil que todo el equipo de desarrollo trabaje dentro de una sola app grande (imaginen que todo el sitio es una app en Rails)
- #2 Al crecer, el sistema distribuido que inevitablemente van a tener ya es difícil de razonar por sí mismo, incluso sin cientos de microservicios intrínsecamente riesgosos
- #3 Si se van por completo a lo micro, tendrán que introducir nuevos conceptos para manejar la expansión descontrolada
- #4 La infraestructura a medida (
Bespoke) o los microservicios a medida son una forma extrema de deuda. El código ya es deuda, pero un servicio es su versión extrema. Piensen bien lo que eso significa. Hagan que sea un punto de apalancamiento
- A los ingenieros de sistemas distribuidos no les gusta la duplicación, así que si algo ocurre en varios lugares piensan: "saquemos esto y hagamos un microservicio"
- En teoría eso tiene sentido, y hasta 10 o 20 está bien. Pero cuando pasan de decenas o se usan en una empresa grande, deja de ser un problema técnico y se vuelve un problema organizacional
- Puede parecer que lo que digo es una dicotomía equivocada, pero en realidad con los microservicios hay desafíos técnicos y aún más problemas organizacionales
Lo que me preocupa es
- #1 (A menos que la empresa esté dirigida, curiosamente, por un CEO con perfil de TI) la infraestructura siempre termina perdiendo prioridad
- #2 Cuando hay demasiados servicios, normalmente aparecen problemas de ownership y de límites
- #3 Se introducen más herramientas para poder manejar una gran cantidad de microservicios
- #4 Lo más importante es que cada microservicio que debió haber sido una librería o un SDK introduce riesgos en producción
Lo que generalmente recomiendo
- #1 Mantener el monolito el mayor tiempo posible, si se puede
- #2 Que los servicios empiecen por lo que necesita infraestructura, no por el lado del desarrollo de apps
- #3 Si tienen que dividir el monolito, háganlo en apps grandes, no en servicios pequeños
- #4 Piensen en cada app nueva como una pared virtual dentro de la empresa
- #5 Si es posible, prefieran librerías en lugar de microservicios
13 comentarios
La parte final, sobre las preocupaciones y las recomendaciones, me pareció muy identificable.
En realidad, tanto el tamaño de la empresa como el del servicio van en una línea parecida, y sentí que hará falta un criterio acertado para prepararse con anticipación para el momento en que ya no quede otra que dividirlo.
¿No debería depender del tamaño del sistema en lugar del tamaño de la empresa? ¿O yo había entendido mal MSA?
En los comentarios de arriba,
primero coincido con la opinión de que, ¿no será que el problema no es de los microservicios, sino de la expansión indiscriminada de servicios?
y, a medida que la empresa crece, las desventajas propias del monolito —como los problemas de despliegue y la gestión de ramas— se vuelven demasiado evidentes, así que parece importante elegir bien el trade-off entre costo y productividad.
Es un artículo muy bueno. Gracias.
Creo que es algo parecido al debate sobre la importancia de los patrones de diseño.
Los llamados patrones de diseño son patrones de código que surgieron en el proceso de resolver diversos problemas...
Al final, hay que adaptarlos y aplicarlos según la situación y la necesidad...
Pero a veces hay personas que se obsesionan con ellos como si los patrones de diseño fueran una respuesta modelo indispensable...
Últimamente, con el tema de MSA, también parece pasar algo parecido: cada vez hay más gente de la idea de que todo debe ser MSA...
Suena como el típico dilema de qué fue primero, el huevo o la gallina.
¿No será que el problema no son los microservicios, sino la expansión indiscriminada de los servicios?
Creo que es importante encontrar un equilibrio adecuado.
Cuando se avanza hacia los microservicios, existe el riesgo de que cada nueva funcionalidad termine convirtiéndose en un nuevo microservicio,
lo que puede hacer que la gestión se vuelva cada vez más difícil.
Esto me recuerda al artículo "Goodbye Microservices" que antes se publicó en el blog técnico de Segment.
Aunque Segment también es una CDP y procesa una enorme cantidad de datos en tiempo real, igualmente hizo la transición de una arquitectura de microservicios a un monolito y organizó en el blog las razones de ese cambio. Creo que en cierta medida también conecta con este artículo :)
https://segment.com/blog/goodbye-microservices/
En general, coincide bastante con lo que pienso.
En nuestra empresa hay 5 desarrolladores, así que creo que por ahora lo correcto es seguir apostando por un monolito (RubyOnRails).
Si, como en el artículo de arriba, llega a ser un proyecto en el que más de 50 personas desarrollan al mismo tiempo, creo que en ese momento terminaremos desarrollando un segundo monolito.
Si son una empresa de 5 a 50 personas, simplemente vayan con un monolito << ¿esto se refiere al total de integrantes y no a la cantidad de desarrolladores, cierto?
Creo que se refiere al tamaño de la empresa~
Si es posible, mantengan el monolito el mayor tiempo que puedan. < Lo entiendo totalmente. Al separarlo, aumenta mucho el costo de mantenimiento.
Creo que es un texto como reacción a que la arquitectura de microservicios se esté volviendo un dogma, y en ese sentido me parece que tiene valor.