¿Son los microservicios balas de plata?

La expresión “balas de plata” en términos informáticos no es muy utilizada por castellano parlantes, no siendo así en el mundo anglosajón. El uso viene dado por Freed Brooks en un artículo científico que público, llamado “No Silver Bullet – Essence and Accidents of Software Engineering” y que se puede traducir como solución a todos los problemas.

Con esto en mente podemos afirmar que los Microservicios no son una bala de plata. Expertos en diseño de arquitectura de software como Simon Brown sugieren que antes de proponer una arquitectura de Microservicios nos hagamos la siguiente pregunta: "Si no puedes construir una aplicación monolito, ¿qué te hace pensar que los microservicios son la respuesta?" 

Con estas afirmaciones no se pretende indicar que los Microservicios sean malos, ni tampoco las aplicaciones monolíticas tiene porque serlo, simplemente se tiene que encontrar el equilibrio y decidir cuidadosamente cuándo es mejor utilizarlos.

¿Por qué implementar una arquitectura de microservicios?

Existen muchos motivos para utilizar microservicios, entre los que caben destacar los siguientes. Hacer que seis personas se pongan de acuerdo en un estándar es difícil. Si elevamos la cifra a 50 o 100 personas es una tarea imposible, así que solo queda la opción de forzar un lenguaje o una sintaxis estándar en todo el proyecto, lo que provoca que la capacidad de aportar nuevas ideas y la innovación se vean afectadas negativamente. Los microservicios, al igual que las arquitecturas orientadas a los servicios, son una excelente manera de disminuir estos riesgos.

Desde el punto de vista de la definición funcional, los microservicios permiten realizar un diseño que tenga en cuenta el escalado independiente, un mayor grado de resiliencia y una depuración más rápida de los errores.

Otra de las ventajas a destacar es que debido a su naturaleza independiente permiten establecer “contratos” claros y sólidos entre los servicios y los equipos responsables de su desarrollo, lo que reduce la necesidad de compresión del código completo del proyecto, permitiendo a cada equipo/desarrollador centrarse en su parte, aumentando la reutilización de las librerías en cualquier lenguaje y un desarrollo más rápido en los grandes proyectos, precisamente porque cada servicio individual es simple, predecible y fácil de entender.

¿Por qué no implementar una arquitectura de microservicios?

La definición de microservicios que suele venir a la mente implica aplicaciones separadas que se comunican a través de una red y, nada más lejos de la realidad, los microservicios son un enfoque para desarrollar una única aplicación como un conjunto de pequeños servicios, cada uno ejecutándose en su propio proceso y comunicándose con mecanismos ligeros.

Las redes han existido durante más de 40 años, y se ha reflexionado mucho sobre nuestras falsas suposiciones acerca de la comunicación a través de ellas, lo que se resume muy bien en las Falacias de la Computación Distribuida:

·        La red es fiable.

·        La latencia es cero.

·        El ancho de banda es infinito.

·        La red es segura.

·        La topología no cambia.

·        Hay un administrador.

·        El coste de transporte es cero.

·        La red es homogénea.

Al plantear una solución basada en microservicios, que conllevará un desarrollo de un sistema distribuido, hay que tener en cuenta que debemos lidiar con un conjunto de problemas diferente. Si la latencia no es cero, ¿cuánto tiempo debemos esperar? Si la red no es fiable, ¿cómo garantizamos que los datos no se pierdan?

Por norma general, las soluciones a estos problemas suelen ser bastante más costosas en términos de desarrollo, mantenimiento y velocidad de respuesta de la aplicación que una llamada a un método.

Quizá el aspecto más importante y donde hay que poner más foco es en la fiabilidad, puesto que puede llevar bastante trabajo hacerlo bien. Una arquitectura de microservicios que no esté bien implementada puede terminar levantando un servidor por cada servicio, añadiendo más componentes, con lo que más partes pueden ir mal, disminuyendo la fiabilidad.

Durante el proceso de desarrollo del proyecto, ese mal diseño y mala implementación, con suerte, se puede convertir en 2-4 servidores, un balanceador de carga y varios contenedores que se ejecuten en un clúster (Kubernetes). Si además se deciden eliminar las llamadas síncronas, podemos terminar descubriendo que en vez de una aplicación hemos creado una caché distribuida gigante y la coherencia de esa enorme caché no es un problema que estaba previsto y tampoco con el que sea fácil de lidiar.

Por supuesto una arquitectura basada en microservicios bien pensada y bien planeada es un sistema muy sólido y fiable.

Conclusiones

¿Es un artículo en defensa de la arquitectura monolítica o es un artículo en defensa de la arquitectura de microservicios? Pues ni una cosa ni la otra. Hay que recordar las balas de plata, lo importante es elegir la adecuada para el proyecto que se plantea y no precipitarse.

Algunas preguntas que pueden ayudar a decidir si implementar la arquitectura en microservicios son las siguientes:

·        ¿Se espera un número elevado de usuarios y no de forma constante?

·        ¿Hay despliegues constantes o muy frecuentes y el sistema debe permanecer levantado?

·        ¿Es la nube el destino del proyecto?

·        ¿Se necesita escalado dinámico?

Y la más importante ¿No se va a complicar la arquitectura de la aplicación innecesariamente?

Autor del artículo

Juan Antonio Morales, specialist lead de Consultoría Tecnológica de Deloitte