¿Qué pasa cuando tu aplicación corporativa no para de engordar? Vamos echándole encima más y más servicios. Llega un punto en que parece que lo único que podemos hacer es escalar en hardware (más maquinas) hasta llegar al colapso.
¿Dónde está el problema? Párate a pensar que naturaleza tiene tu arquitectura. Cúal es el punto de entrada y cómo despliega la aplicación que debe ofrecer el soporte al resto de aplicaciones y servicios. Quizás te empieces a dar cuenta del enorme “cuello de botella” que representa ese monolito creado a base de meter más madera.
El uso de microservicios
Para evitar tener una enorme piedra “monolítica” se empieza a escuchar hablar sobre microservicios. ¿Recordáis los servicios SOAP? El cóctel .WSDL, JEE y ESB para los javeros (y equivalente para la gente de Microsoft) ha mejorado con el tiempo. Ahora tenemos APIs REST que exponen pequeños comportamientos y se comunican de forma distribuida entre servicios, sin importan que no estén en la misma aplicación.
La ventajas de una arquitectura basada en microservicios
-
Combinar los servicios como nos interesen. Incluso, reutilizarlos para distintos uso dentro de la empresa. Como piezas de puzzle podemos crear aplicaciones que usen una misma lógica de negocio sin estar cautiva en una aplicación monolítica.
-
Escalar a nivel de microservicios. Cada uno de ellos expone una funcionalidad, así podemos distribuirlo según nuestras necesidad pensando en la demanda y el balanceo de carga de cada aplicación. Esto contrapone la idea poco eficiente de replicar aplicaciones enteras cargadas de funcionalidad por unas pocas que represente la mayor carga.
-
Simplificamos el mantenimiento. Cumplen a la perfección el principio SOLID. Podemos desechar componentes que no reutilizando o extenderlos en otros para engancharlo en nuestra aplicación. Es más fácil tirar algo que no usemos a la basura que mantenerlo como código legacy dentro de una aplicación monolítica.
-
Su fallo no arrastra a todo el sistema. Si un componente no funciona correctamente no afecta al resto. Se puede aislar y manejar el error, desplegando por separado.
-
El despliegue puede ser progresivo sin parar todo de golpe. Empezamos a ver más luz a la integración continua alcanzando mayores cifras de disponibilidad. Aunque recuerda que esto implica que ya no tienes un único contenedor, sino que hay que estar pendiente de n contenedores de aplicaciones.
El camino hacia los microservicios no es trivial. Al igual que mencionamos que todo trabaja en conjunto, llegar ahí necesita portar el código legacy de la aplicación monolítica y parcelarlo. No te vuelvas loco en convertir en microservicios tu actual aplicación. Comienza poco a poco explorando este tipo de arquitectura con las nuevas funcionalidades/servicios que crees.
Para entender más en detalle lo qué son los microservicios os recomiendo a un clásico como Martin Fowler. Él aporta todo ese halo filosófico y teórico, sin importar el lenguaje o la plataforma, en su artículo sobre la arquitectura de Microservicios.
