Publicado el 22 de mayo de 2016 por Nicola Rizhikov
Todo el mundo habla de los microservicios como el enfoque preferido para estructurar sistemas de información complejos.
Estos son algunos de los argumentos más populares:
- Nuestra aplicación monolítica se ha vuelto demasiado grande y compleja, por lo que vamos a dividirla en servicios.
- Hemos alcanzado el límite de rendimiento de nuestro monolito; al dividirlo en servicios esperamos mejorarlo.
- Nuestro sistema será enorme, así que partimos de una arquitectura de microservicios para poder escalar en el futuro.
- Las empresas de éxito utilizan microservicios; simplemente queremos seguir las mejores prácticas del sector.
Desde mi punto de vista, estas motivaciones no tienen una conexión directa con este patrón arquitectónico y pueden acarrearle verdaderos problemas o un desperdicio de recursos. La decisión de adoptar un estilo arquitectónico de microservicios debe ser consciente y contemplar todas las consecuencias y compromisos que implica.
Veamos algunas penalizaciones importantes que pagará al elegir microservicios:
Consistencia y gestión de dependencias
Cuando divide su sistema en servicios que evolucionan de forma independiente, estas partes siguen teniendo dependencias lógicas entre sí y el sistema en su conjunto debe ser consistente. En una aplicación monolítica, estas dependencias están codificadas de forma explícita en el código, pero al dividirlo en piezas, las dependencias se vuelven «implícitas» y se necesita un esfuerzo adicional (versiones, contratos, pruebas, etc.) para garantizar que se satisfacen. El sistema se vuelve más frágil e impredecible. Esto es, en cierta medida, similar a la elección entre las opciones ACID y BASE. En el caso de ACID, en todo momento existe una única versión fiable del mundo; en el mundo BASE, muchas galaxias paralelas pueden coexistir y hay que gestionar la consistencia manualmente. En el peor de los casos, podría acabar con el conocido problema del infierno de dependencias. Por tanto, sin unas sólidas habilidades y herramientas de «gestión de dependencias», está transitando un camino peligroso.
La descomposición «correcta»
La preocupación más difícil en el enfoque de microservicios (en la programación en general :) es cómo descomponer el todo en partes. Como saben muchos arquitectos con experiencia, la descomposición inicial casi siempre es incorrecta. Hacerlo «bien» implica ser capaz de predecir el futuro. En lugar de recurrir a indicaciones teóricas, analicemos las consecuencias de una descomposición «incorrecta».
Funcionalidad transversal: es fácil recibir una solicitud de nueva funcionalidad que requiera realizar cambios en muchos servicios y luego desplegarla de forma coherente. En ocasiones, esta funcionalidad llevaría minutos en un monolito y horas o días en un entorno de microservicios. Lo mismo ocurre con los errores transversales.
Recomposición: si ha encontrado una forma mejor de estructurar su sistema, tendrá que recomponer su arquitectura. En un monolito se trata simplemente del conocido «refactoring», que puede realizarse de forma relativamente segura. Con los microservicios, dicha transformación es en muchos casos una tarea nada trivial.
Gastos operativos
Este es un coste relativamente conocido: cada nuevo componente añade una sobrecarga operativa de forma no lineal. Los sistemas distribuidos requieren una infraestructura, unas herramientas y unos expertos cualitativamente más complejos para funcionar de manera fiable.
Ventajas de los microservicios
Hacer crecer su empresa y su sistema de forma correcta no es sencillo. Hay que gestionar dos entidades interrelacionadas: la organización y el sistema. El argumento más importante a favor de los microservicios, para mí, es alinear ambas de acuerdo con la ley de Conway. Los (micro)servicios permiten asignar cada servicio a los límites de un equipo multidisciplinar, logrando que los equipos sean lo más independientes posible. La restricción fundamental que no debe ignorar es que el equipo debe ser capaz de diseñar, desarrollar y entregar «valor real» al usuario final con una superposición y conflictos mínimos con otros equipos. «Escalar su sistema y su organización» es un objetivo que justifica el coste de los microservicios. La fórmula simplificada sería:
- un equipo → muchos servicios → incorrecto (sobrecargas)
- muchos equipos → un servicio → incorrecto (conflictos)
- un equipo → un servicio → correcto
En estas condiciones, el tamaño del servicio no debe ser «demasiado micro», sino que debe estar definido únicamente por el tamaño y las capacidades de sus equipos. Como sabemos, un equipo puede escalar en un intervalo muy limitado —de 2 a 7 personas—, pero las capacidades pueden variar en varios órdenes de magnitud.
Otro argumento válido para mí es el «cambio tecnológico»: la situación en la que la tecnología actual no puede ofrecer las características técnicas requeridas —por ejemplo, el rendimiento— y es necesario «escribir en C» alguna parte crítica del sistema.
Conclusión
Estos retos y sus derivados consumirán la mayor parte de su tiempo al inicio y le ralentizarán significativamente en la fase crítica. Por eso, el enfoque de «microservicios primero» me resulta muy sospechoso. La mayoría de las aplicaciones de «microservicios» exitosas surgieron como una reelaboración de monolitos en producción divididos en piezas. En esos casos, los ingenieros tenían un profundo conocimiento de los componentes internos del sistema y de sus problemas.
En la mayoría de los casos, defiendo el enfoque «Monolito primero».
