Microservicios: 9 razones para Arquitectos, Desarrolladores y Testers

Hemos estado viendo estos días atrás las diferentes características de los microservicios , la importancia del software de arquitectura basada en éstos, pros, contras… Y ya conociendo de lo que estamos hablando, vamos hoy a dar algunas razones por las que deberíais plantearos comenzar a implantar esta metodología de desarrollo en vuestros proyectos.

Dividiré las recomendaciones en función de a quién pueden llegar a afectar más, cosa que no significa el que no se apliquen a los otros apartados. Vamos allá:

Arquitectos

Es puro y simple

Nada de enrevesadas interrelaciones que comuniquen varias bases de datos. Cada módulo tendrá su propia base de datos y proceso, lo que le da esa independencia de la que hemos estado hablando anteriormente.

Es transparente

Cada servicio hace lo que debe hacer, no llevará infinidad de funciones que apuntan a acciones que no vamos a necesitar. En lugar de eso, cada microservicio puede hacer uso de otros microservicios para completar así una acción que se le ha solicitado y para la que no tiene capacidad.

Conlleva menos riesgos

Como sabemos, a la hora de programar el riesgo de fallo no es lineal ascendente, sino exponencial. A menor código a ejecutar, obviamente menos riesgos de errores vamos a tener. Y de aparecer, el hecho de que cada módulo funcione independientemente, nos otorgará un aislamiento que nos facilitará el encontrar dicho fallo.

Desarrolladores

Es ágil

La mayoría de equipos de desarrollo usan o procuran usar una metodología ágil a la hora de programar una aplicación. Ya se trate de SCRUM, XP u alguna otra variante, el sistema de trabajo se repite porque se ha comprobado que ofrece resultados positivos.

Se trata de dividir un gran volumen de trabajo en pequeñas partes manejables en las que se pueda centrar un equipo de desarrolladores o un único programador. Y esto como hemos visto es de lo que se trata la arquitectura de microservicios, en pequeños módulos independientes que en su conjunto dan forma a una aplicación completamente funcional.

Fomento del desarrollo en paralelo.

Al ser cada microservicio independiente de los demás, el desarrollo de la aplicación puede darse en paralelo, sin incurrir en tiempos de espera a que un grupo de desarrollo finalice una parte imprescindible para que otro equipo de programadores continúe con su tarea.

Traducimos esto como ahorro de tiempo, costes e incremento de la productividad de los efectivos, lo que busca cualquier empresa hoy día ;)

Acelera la depuración.

Para los testers, intentar localizar un fallo en una aplicación monolítica puede llevar muchas horas de prueba, por lo que en la mayoría de los casos al encontrar un fallo éstos reportan un fallo pero no pueden detallar donde se encuentra. Será el desarrollador una vez le llegue el informe que indica un fallo el que tenga que escudriñar entre (por lo general) miles de líneas de código, funciones que se llaman entre sí, etc…

En el caso del software basado en microservicios, el 99% de los fallos se reportará indicando que un servicio o microservicio determinado no funciona o no lo hace correctamente, lo que para el programador acota muchísimo su búsqueda del error, pudiendo solventar la incidencia en un breve espacio de tiempo.

Los Testers

Testear servicios gigantescos lleva mucho tiempo.

Ya lo decíamos antes, realizar pruebas sobre servicios de gran magnitud puede llevar muchas horas de prueba, lo que hace que el proceso de testeo acabe incrementando el tiempo final que ha tomado llevar a cabo la aplicación. La cantidad de excepciones, funciones y otros componentes a testear puede ser ingente, pues recordemos que cada servicio puede hacer llamadas a otros tantos… pudiendo incurrir en errores provenientes de otros servicios y llevando a confusión.

Los microservicios son más simples.

Efectivamente, al tratarse de una aplicación basada en microservicios encontraremos muchísimas más API’s que si nos enfrentamos a un “mega-servicio”, pero recordemos lo que hemos dicho antes, localizar los fallos es una tarea mucho más simple si el servicio únicamente hace lo que tiene que hacer, acelerando así el tiempo requerido en cada API y por ende aumentando el rendimiento al no verse atrapados los testers por cientos de errores en cada servicio que prueben.

Los riesgos son mucho más bajos.

Ya lo decíamos para los arquitectos, pero para los testers, aquellas personas quienes orientarán a los desarrolladores y arquitectos de software hacia una experiencia de uso más agradable, los cambios a proponer serán mucho más sencillos si se tratan de pocas líneas de código y directas a cumplir una función determinada. Además, si sumamos la capacidad de introducir cambios que admite este tipo de arquitecturas, comprobamos que efectivamente, el incluir cambios conlleva unos riesgos mínimos que no afectarán más que al módulo en cuestión al que nos refiramos en cada momento.

Y dicho esto tras lo que estaréis ávidos de curiosidad por seguir conociendo más de este tipo de desarrollo de software, teneis nuestro curso de microservicios.