Spring Microservices

By Eugenia Pérez | 29 December, 2017

Seguramente ya hayas oído hablar del concepto de microservicios y, ciertamente, es una de esas nuevas tendencias, que tanto abundan en el ámbito del desarrollo, que aparentemente se pone tan de moda que hace que muchos profesionales se empeñen en cambiar sus sistema actual pese a que no encaje dentro de esa nueva tendencia. Como suele pasar, el desarrollo de aplicaciones mediante microservicios no es mejor o peor, es simplemente otra manera de organizar un sistema que según cada caso resultará en más eficiente o no.

Los microservicios no son una tecnología propietaria, por tanto los cánones que marcan qué es un microservicio y qué no lo es no están establecidos por ninguna entidad en particular. Sin embargo, existen una serie de principios que se cumplen de forma regular en la mayoría de ellos, y que aprovechan el auge de tecnologías como los containers, la computación en la nube y el perfil de DevOp.

¿…Pero qué son…?

Tradicionalmente se procuraba construir aplicaciones desarrollando componentes, con el objetivo de crear un sistema desacoplado y donde esos componentes trabajaban de forma cohesionada y eran fácilmente sustituibles. El objetivo final, siempre era el mismo,  facilitar el mantenimiento y mejora de ese sistema. Sin embargo, en esta era en la que disponibilidad y el tiempo de respuesta se hacen tan cruciales, donde hay infinidad de aplicaciones a las que acceden millones de usuarios en todo el mundo, los sistemas pueden tener un punto débil: ser sistemas monolíticos. Y esto, puede provocar en muchos casos, que para cada modificación haya que cambiar el sistema entero, aunque solo se haya retocado un pequeño componente (si bien es cierto que en la nube hay sistemas que facilitan que ese cambio sea transparente).

Por lo tanto, curiosamente puede darse la circunstancia de que un equipo de ingenieros desarrollen un sistema con una arquitectura más limpia que una patena con una cobertura de código de 100% y un build con integración continua que funcione como un reloj… Pero su sistema sea ¡monolítico!. Al igual que ocurre con los coches, aunque estén hechos a base de componentes reemplazables, si se les añade una mejora el coche tendrá que ir a boxes con la consecuente parada, aunque sea de unos segundos. ¿Imaginas que pudieras cambiar una rueda con el coche en movimiento?

Eso es lo que facilitan los microservicios. En lugar de centrarse simplemente en los componentes, los sistemas se dividen en servicios independientes. Esos servicios, internamente tendrán su organización y componentes, pero a diferencia de los sistemas monolíticos, se pueden “implantar/iniciar/parar/cambiar” de manera, precisamente, independiente y sin afectar al resto de servicios. Esto además, tiene otra ventaja derivada, cuando una aplicación tiene mucha carga de acceso, podemos crear nuevos nodos/instancias/containers de forma automática y segura al superar determinados umbrales programados. Al ser un sistema monolítico, aunque sea un container (Docker), resulta que estamos clonando la aplicación completa, y con una arquitectura de microservicios tenemos la granularidad, si es aplicable, para poder clonar los microservicios que tengan mayor demanda. Por ejemplo un sistema puede tener momentos donde necesite dar respuesta a la parte de altas de usuario, y en otros momentos tener más carga en el servicio de envío de mensajes.

De todo esto se hablará en el libro que será proximamente publicado, dado que es un tema en el que actualmente estoy profundizando…

facebooktwittergoogle_plusredditpinterestlinkedinmailby feather