Microservicios

La arquitectura de microservicios es algo de lo que se habla mucho últimamente. Creo que viene derivado de la exitosa adopción de este nuevo modelo por parte de grandes empresas como Netflix, Amazon o PayPal. Es probable que haya personas que piensen que si su organización migra también hacia los microservicios, terminarán teniendo tanto éxito como éstas. ¡¡Ni de broma!! Estas empresas han llegado a los microservicios por necesidad; porque necesitan ciertas características de ese paradigma que no pueden obtener con sus sistemas actuales. ¿Pero realmente es útil para cualquier empresa? ¡¡En absoluto!!

Los microservicios se definen a menudo como lo opuesto a la arquitectura monolítica, que es la que está implementada actualmente en la amplia mayoría de empresas, y que funciona correctamente siempre y cuando las aplicaciones no hayan crecido desmesuradamente y se hayan vuelto inmanejables (caso que trataremos más adelante). Un microservicio es un componente que se puede desplegar y evolucionar de manera independiente. También se dice que su tamaño no debería ser mayor que aquel que puede desarrollarse en no más de dos semanas. Esto brinda mucha agilidad a la hora de evolucionarlo o incluso reescribirlo utilizando una nueva tecnología más afín para resolver el problema para el que se diseñó. Los microservicios deben comunicarse entre sí utilizando una API moderna (aunque también se puede utilizar el paso de mensajes vía broker), y en teoría, como hemos anunciado ya, son libres para elegir la tecnología que mejor se ajuste a su propósito. Dado que se trata de componentes autónomos, si tienen que mantener estado deben contar con su propia base de datos. Esta es una característica que rompe bastante con la arquitectura monolítica, ya que en ese modelo, todos los componentes de la aplicación suelen acceder a una única base de datos, propiedad de la aplicación.

Las ventajas de los microservicios son obvias. Tanto el desarrollo, como el despliegue y la escalabilidad de éstos es independiente. Se puede modificar un microservicio sin necesidad de afectar a la aplicación completa y por tanto al servicio prestado. Se puede dotar de más músculo a aquellos componentes que lo necesiten, sin tener que hacerlo al resto de la aplicación. Y en general existe una mayor granularidad para exponer nuestro negocio, pudiendo incluso tener algunos microservicios en servidores de aplicación de diferentes tecnologías, como JBoss, Tomcat, WAS, o incluso “sin servidor” (serverless), Node, Perl, etc. Los equipos de desarrollo son más ágiles y todos los tiempos del ciclo de vida menores. Maravilloso, impresionante, ¡¡quiero microservicios…!! No tan rápido.

Hemos dicho que los ciclos de desarrollo se reducen, ¿pero qué ocurre si el desarrollo de un nuevo componente requiere de otros microservicios? En este caso necesitaremos un entorno para comunicar nuestro desarrollo con el resto de servicios. Por otra parte se produce una explosión de complejidad para los operadores de sistemas. Más procesos en ejecución, más vías de comunicación, más áreas de que preocuparse... Para llevar a buen término este tipo de tecnología es imprescindible contar con un buen equipo DevOps. En esta arquitectura los equipos de desarrollo y operación deben trabajar de manera conjunta, siendo uno solo, y esto no es fácil de conseguir cuando en una organización, a menudo los equipos son de diferentes empresas y tienen intereses cruzados. Y como también se puede prever, es necesario un nivel técnico superior. Si actualmente con la arquitectura monolítica las cosas no van como la seda, ¿qué ventajas se aportan añadiendo más sistemas, automatizaciones y tecnologías dispares? Por otra parte, existen otros retos que superar, como la centralización de trazas y auditoría, definir un buen versionado con rollback, y quizá el tema más complejo, resolver las incoherencias en las transacciones distribuidas.

¿Pero entonces? ¿Qué se puede hacer cuando una aplicación monolítica crece y se hace demasiado grande? Grande para su evolución, despliegue y verificación. Muy sencillo, se debe refactorizar. Se tiene que analizar su estructura de empaquetamiento, porque es probable que dentro de esta existan diferentes módulos separados por unidad de negocio. A estos módulos se les debe dar más entidad, definir un interfaz de comunicación y modificarlos para que hablen entre sí. Se trata de realizar algo parecido a los microservicios pero con un nivel de granularidad mucho menor. Además, es probable que encontremos módulos que puedan ser desplegados en servidores de aplicaciones libres, como JBoss o Tomcat. Y si la refactorización es un éxito y tenemos diferentes módulos por unidad de negocio que se comunican con un interfaz bien definido (REST o SOAP), podemos exponerlos al resto de la empresa para que sean reutilizados.

Y como último apunte, en el caso que la empresa quiera migrar a microservicios porque necesite sus virtudes, la recfactorización de aplicaciones es una técnica útil para llegar en varias fases a los microservicios. Ya que la alternativa de realizar un big ban y rehacerlo todo de nuevo lo único que puede asegurarte es una gran explosión ;)