Si buscas información sobre microservicios, te encontrarás con algo curioso el manifiesto de sistemas reactivos de 2014. Lo primero que llama la atención es este curioso nombre ¿Qué es un sistema reactivo? ¿a qué “reacciona”? todavía no he encontrado un sentido a ese nombre, si lo veis, me lo decís por favor.

Pero lo importante es el contenido y en este manifiesto hay mucho. Después de un pequeño preámbulo donde se habla que las aplicaciones de hoy en día no son como las de antes…, y tanto que no, sólo hay que pensar que la típica aplicación de hace unos años estaba destinada a unos cientos de usuarios como mucho en horario de oficina, mientras que las que hay ahora pueden llegar, literalmente, a cientos de millones de usuarios en todo el mundo con 24/7.

4 características que definen a los sistemas reactivos

Son cuatro, sólo cuatro, las características que definen este tipo de sistema:

  1. Responsivos
    “Responden de una manera oportuna en la medida de lo posible”.
    Lo primero que debe darnos un sistema es que nos de servicio, en un tiempo máximo predefinido cumpliendo así con la calidad del servicio comprometida.
    Esta característica proporciona confianza al usuario final y, como dice el manifiesto, simplifica el tratamiento de errores y favorece el uso de la aplicación.
  2. Resilientes
    En su segunda acepción, la RAE define la resiliencia como la capacidad de un sistema para recuperar su estado inicial cuando ha cesado la perturbaciónn a la que había estado sometido. Vamos, como diría el clásico, que el sistema debe ser como un junco que se dobla pero no se parte.
    Traducido a nuestros servicios quiere decir simple y llanamente que cuando se encuentra con un fallo, el sistema tiene que continuar y dar una respuesta válida.
  3. Elásticos
    El sistema debe escalar de manera lineal y soportar la carga de trabajo cuando aumenta usando más recursos pero también liberando estos mismos recursos a medida de que ya no se vayan necesitando cuando la carga disminuye.
  4. Orientados a mensajes
    Y cuando dice orientado a mensajes, dice que el sistema debe ser en lo posible asíncrono. Esta quizás sea una de las grandes asignaturas pendientes… no parece que abunden los servicios asíncronos y seguimos pensando en que un servicio debe ser síncrono por defecto.
    Si queremos que el sistema asegure un bajo acoplamiento, un gran rendimiento, tolerante a fallos, etc. etc. tiene que ser asíncronos.

En mi opinión estas características son deseables en todo sistema y deberíamos al menos, plantearnos en el diseño si las tendríamos que cumplir o no, y en caso afirmativo, como podríamos implementarlas. ¿Quien no quiere que su sistema sea tolerante a fallos, que respondan en un tiempo máximo preestablecido o que sean capaces de asumir una gran demanda de carga?. Por supuesto, nada es gratis, y para conseguir esto a buen seguro que tendremos que complicar nuestra implementación por lo que debemos ser conscientes si el beneficio a obtener compensa este coste suplementario.

Y tú ¿estás de acuerdo con que un sistema tiene que cumplir con estas características o esto no es necesario?

Anuncios