Para mi primera entrada en el blog, me gustaría hablar sobre un tipo arquitectura que gana adeptos cada día, sobre todo para el diseño de grandes aplicaciones, donde el rendimiento y la escalabilidad son factores claves. Imaginaos como de grandes tienen que ser las infraestructuras de Amazon o Netflix (por nombrar a dos grandes que usan microservicios) para soportar todo el trafico que reciben. Ahora imaginaos que Netflix saca una nueva serie estrella y de repente gana millones de nuevos suscriptores de la noche a la mañana. Tienen que poder escalar toda su infraestructura de una forma rápida y sencilla para soportar todo ese nuevo tráfico. Lo consiguen, gracias a entre otras cosas, a una arquitectura de microservicios.
¿Que son los microservicios?
La arquitectura orientada a los microservicios es una aproximación de diseño de software que se basa en crear pequeños servicios totalmente desacoplados entre ellos y que exponen una API para poder comunicarse entre ellos. Si con esto no tienes suficiente y/o quieres profundizar mucho mas, Martin Fowler da una muy buena definición.
Este enfoque, aporta muchas ventajas sobre el diseño de aplicaciones monolíticas (una capa de UI, una capa de negocio, una capa de acceso a datos):
- Al ser cada uno de los microservicios totalmente autónomos, la caída de uno de estos servicios podría afectar al funcionamiento de la APP, pero esta podría continuar funcionando en el resto de módulos. Por ejemplo, en una tienda on-line se cae el microservicio que se ocupa del sistema de pago, por lo que el usuario no podrá finalizar su compra mientras no se solucione el problema, pero por el contrario si que podrá seguir navegando por el catálogo de productos sin problemas.
- Si uno de los servicios necesita una actualización, los cambios a realizar estarán muy localizados por lo que será mas sencillo de actualizar y será menos propenso a errores, además, podríamos versionar este servicio individualmente sin afectar al resto.
- Al ser cada servicio una pequeña aplicación, es mas sencillo y mas rápido innovar o mejorar ese servicio.
- Puedes tener equipos separados muy especializados trabajando en cada uno de los componentes, por lo que la calidad del software puede mejorar considerablemente. Además, como (me pongo pesado con esto) cada componente es independiente, cada uno puede ser realizado en la tecnología que mas se adapte a la necesidad.
- Es mucho más fácil escalar, por todo lo comentado anteriormente.
- En caso de tener que realizar cambios, solo tendremos que desplegar el servicio que ha sido cambiado en vez de toda la aplicación.
Si se te ocurren mas ventajas, no dudes en ponerlas en los comentarios y actualizaré la entrada.
Todo esto es muy bonito, pero hemos de tener en cuenta una cosa, sin una buena estrategia de entrega continua y un despliegue automatizado, todas las ventajas de usar microservicios podrían ir en tu contra, ya que en vez de una aplicación has de desplegar muchos microservicios, por lo que los riesgos y complicaciones de un despliegue se multiplican (imagina desplegar decenas, o cientos, de microservicios a mano…).
Los microservicios tienen muchas ventajas, pero también algunas desventajas, por lo que como siempre, has de usar el sentido común y analizar si en tu proyecto vale la pena usar este tipo de arquitectura.
No quiero que queden artículos demasiado largos, por lo que de momento me quedaré aquí, pero en próximas entradas profundizaré un poco mas en el tema, tanto directa como indirectamente y a ser posible con ejemplos y algo de código.
Referencias y enlaces interesantes
La definición por excelencia: Microservicios por Martin Fowler
Una charla muy interesante sobre microservicios: Podcast de El Bruno en el que hablan sobre microservicios
Gran artículo Dani! Creo que con el auge y el crecimiento de Cloud, Contenedores, API’s Rest, ServiceBus, DevOps + CI & CD etc.. tenemos muchos ingredientes como para montar una arquitectura basada en Microservicios. Las tecnologías y las plataformas están ahí, de eso no hay duda, pero para mi lo más importante es tener «cabeza» sobre todo ello. Prefiero pensar en arquitecturas emergentes. En el rediseño y el refactoring contínuo. Prefiero no pensar en crear un monstruo al segundo día del proyecto porque resulta que delante la pizarra hemos creado 300 cajas interconectadas entre sí dando lugar a una arquitectura que aún no se necesita. Prefiero pensar en que, en lugar de ello, primero se evalúa de forma correcta el Dominio, se separan correctamente los boundaries, se realiza un correcto diseño orientado a la separación de responsabilidades y enfocado a comportamiento y a partir de ahí, las necesidades del proyecto y al final del usuario final dictaminarán cómo proseguir. Eso sí, teniendo ya de partida algo bien estudiado y preparado para escalar si realmente se necesita. Con lo que tenemos hoy en día no es especialmente difícil crear nuevas API’s, desplegarlas en contenedores etc. Lo realmente difícil es aplicar bien el desacoplamiento, la definición de los contratos, la separación correcta de los dominios, entender correctamente el funcionamiento de la organización y el comportamiento del usuario para poder crear algo que pueda escalar de forma distribuida si realmente se necesita. Pero qué bien quedan las palabras no? Es tan y tan difícil hacer bien estas cosas! Pero para ello estamos en este mundo no? Para aprender y disfrutar! Sino sería muy aburrido! Un Abrazo!
Estoy totalmente de acuerdo con lo que dices, pero también creo, que si bien es importante definir y evaluar bien desde el principio el dominio y la arquitectura, la realidad nos dice que muchas veces, ni el cliente que te contrata y en teoría conoce su negocio a la perfección sabe lo que quiere, por lo que es muy probable que a lo largo de un proyecto este cambie mucho. Por eso, creo que aplicando bien metodologías ágiles y una buena arquitectura de microservicios es mucho mas «sencilla» la gestión del cambio («el rediseño y el refactoring contínuo» que comentabas).
Como bien dices, las herramientas están ahí, lo complicado es usarlas correctamente.
Un placer verte por aquí, espero leerte mucho mas!
Gracias por los comentarios!
Santi, como toda arquitectura hay que ver las necesidades del proyecto a afrontas y ver si hay mas pros que contras al aplicar microservicios. Para este caso, como comento en el post, un factor clave es que tengas la infraestructura necesaria para aplicar un despliegue totalmente automatizado, si has de hacer cosas a mano en microservicios puedes morir en el intento. Otro factor clave podría ser el tamaño, si el proyecto es pequeñito puede no valer la pena. En tu caso (lo que hemos comentado alguna vez) no creo que aplique, lo tuyo lo miramos con cariño y unas cervezas.
Jordi, cojo el guante y mas adelante prepararé un post que hable de la seguridad en microservicios (ahora tengo algunos en la recamara, pero cuando los tenga me pongo!), pero te adelanto que podrías crear un microservicio que se encargue de la seguridad, y haces un SSO entre todos tus microservicios. Por ejemplo, si te fijas, todos los servicios de Microsoft o Google, acaban todos en el mismo login.
Buen post, te va a dar para una larga serie :), desafíos que te vas a encontrar con microservicios, escenarios en los que aplica o no, ejemplos… Un tema apasionante. ¡Enhorabuena!
Muy interesante el artículo!
Me encantaría que hablases un poco mas (para futuros posts) de los cambios de diseño en el ámbito de la seguridad de una plataforma montada con microservicios. Supongo que para cada microservicio, requerirá unas medidas de seguridad específicas.
Lo primero, felicidades por empezar un blog, te leeré!
Lo segundo… ¿Cómo podemos evaluar cuando es conveniente utilizar microservicios? ¿Hay alguna pauta o elemento de referencia para saber si aplicarlo o no?
Un saludo!