Durante estos últimos años se ha impuesto un nuevo modelo de arquitectura de SW basado en microservicios. Ha cogido mucha fuerza dadas sus capacidades y la novedad frente a modelos anteriores. Actualmente, casi todos los clientes quieren sus aplicaciones basadas en microservicios, o migrar las que tienen a esta arquitectura. Pero ¿realmente es bueno aplicar microservicios a discreción? ¿Cuáles son las ventajas, y desventajas, presenta su uso normalmente?
Como ya comentamos en un artículo anterior, los microservicios son un nuevo modelo de arquitectura donde separamos las distintas funcionalidades de un producto en espacios más compartimentados que se autoabastecen y mantienen conectados.
Este modelo viene a sustituir lo que se conoce como la arquitectura “monolítica”, donde toda la operatividad del proyecto descansa en el mismo código o sistema.
Ambas metodologías de diseño tienen ventajas y desventajas, fortalezas y debilidades que debemos evaluar según el contexto en el que se utilice.
En el caso de los microservicios, si bien es una arquitectura útil en un número elevado de ocasiones, la mayoría de los proyectos de arquitectura informática suelen precisar de una aplicación monolítica o una SOA como base.
¿Por qué? Normalmente nuestros clientes querrán que sus usuarios se conecten todos a un mismo sistema, aplicación o red. Sirve para unificar métodos, proyectos y la comunicación, y muchos están acostumbrados a tener todo en un mismo lugar. Esto no quiere decir que siempre sea la decisión correcta.
Podemos discernir entre los beneficios y las desventajas de los microservicios:
Como hemos dicho alguna vez, cada empresa y cada cliente es un mundo. Todos tienen distintas necesidades que requerirán de un proceso de diseño y estrategia.
Por suerte, muchos clientes también suelen querer características muy similares si buscan el mismo servicio o pertenecen al mismo sector. Después de todo, si le funciona a la competencia, ¿por qué no te va a funcionar a ti?
Es muy útil crear una guía orientativa, tanto para tus programadores como tus clientes, donde expliques las necesidades más comunes de cada tipo de proyecto y las vincules a uno de los dos sistemas de trabajo para poder tomar la mejor decisión desde el principio y facilitar el proceso a tu cliente.
Por ejemplo, los ERPs y CRMs suelen ser aplicaciones monolíticas por su uso desde sistemas muy concretos (ordenadores de trabajo), mientras que los microservicios se están empleando más y más para aplicaciones con varios tipos de dispositivos en mente y un número amplio de conexiones (IoT, web, móvil, …)
Con estos elementos en mano, deberíamos ser capaces de recomendar a nuestros clientes si una arquitectura de microservicios es adecuada o no a sus necesidades. Es muy arriesgado basar toda la programación de nuestros clientes en una sola técnica. Especialmente cuando ésta no se adecua a todos los casos que existen en los distintos sectores de trabajo.