¿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.
Google+
@durbon
Editor en Genbetadev
