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:
- 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. - 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. - 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. - 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?
Blog de Andrés Hevia 
19/09/2016 at 23:23
Con todo respeto, lo que me llama la atención es que las características mencionadas en el manifiesto y retomadas en este blog podrían aplicarse totalmente a los servicios web y a los servicios REST. No puedo dejar de notar que la elasticidad descrita parece referirse más a la elasticidad del servidor que hospeda los (micro) servicios y no al servicio mismo, pero admito prueba de lo contrario.
Aparte de esto, estos supuestos rasgos de los (micro) servicios son parte de los principios y patrones de diseño de SOA. Entonces, para un blog sobre SOA, ¿no tendría más sentido tratar de identificar qué lo que aportan los (micro) servicios que no aportan los otros servicios ya existentes? ¿Serán los (micro)servicios nada más que una cuarta manera de implementar SOA, complementaria de los servicios web, REST y API?
Algunos blogs sobre (micro)servicios (no éste) hasta tratan de promover los (micro)servicios como una alternativa a las aplicaciones tradicionales monolíticas. ¿A quiénes están tratando de engañar? SOA ha entendido esto desde más de 12 años, y no ha necesitado de los (micro)servicios para ofrecer una alternativa a las aplicaciones monolíticas.
Entonces, en dos platos, ¿que aportan los (micro)servicios que no aportan los servicios web o los servicios REST?
Admito que puede ser un factor importante la diferencia entre las aplicaciones en el entorno corporativo – con centenares o hasta miles de usuarios – y las aplicaciones en el Internet – con millones de usuarios concurrentes. Pero hasta la fecha, no he visto un análisis comparativo de ambos entornos que justifique los (micro)servicios. En todos los casos, si esta diferencia llegara a justificar los (micro)servicios-algo que no descarto-, éstos tendrían que ser presentados como una solución quizás optimizada, para aplicaciones en éste tipo de entorno, pero no una sustitución de los actuales servicios web o servicios REST. O ¿es que estamos de vuelta a que los (micro)servicios son SOA, implementado a como debió haber sido? (y de paso implicar que SOA ha fracasado en sus objetivos).
Atentamente.
20/09/2016 at 19:56
Creo que estamos de acuerdo que los microservicios son una forma de implementar SOA. De la misma manera que implementar SOA con un ESB y son servicios SOAP ha sido la tradicional. Y para muestra un botón, por ejemplo una de las características más importantes de los microservicios que es la independencia de despliegue no es ni más ni menos que el principio de Abstracción de SOA de toda la vida.
Como digo en este post:
En definitiva, viendo el concepto que se suele tener de SOA, yo sólo pediría que no se confunda con SOAP y WS-*. Si bien esta es la implementación tradicional, SOA es un conjunto de principios, que son válidos para implementarlos con REST en aplicaciones monolíticos, en microservicios, etc. etc.
20/09/2016 at 20:28
No había visto el blog en referencia, y está bastante claro. Mi punto es – y sigue siendo- que los micros servicios parecen no ser más que una cuarta manera de implementar SOA (después de los servicios web, servicios REST y API) y no deben ser presentados como una alternativa a SOA, que es lo que muchos blogs hacen, cuando presentan los micros servicios como la alternativa a las aplicaciones monolíticas tradicionales, ignorando SOA.
Sigue también la pregunta de que ¿si los micro servicios son meramente una solución específica para las aplicaciones web con grandes volúmenes de usuarios concurrentes pero, no necesariamente una alternativa a los otros tres tipos de servicios, para aplicaciones corporativas?
De ser así, toda discusión sobre los micro servicios debería ser precedida de la aclaración «de preferencia para aplicaciones con grandes volúmenes de usuarios concurrentes». Si no, se pueden convertir en una distracción innecesaria en el ámbito de SOA y crear expectativas erróneas. salvo que los micros servicios introduzcan un paradigma nuevo y revolucionario que viene a suplantar los demás componentes. Esto era la esencia de mi post inicial.
Saludos Cordiales.
17/10/2016 at 01:39
Amén. Yo veo claramente que los principios SOA siguen vigentes hoy en día, y desconozco el motivo por el que «en general» en una conversación sobre arquitecturas de microservicios puedo parecer un bicho raro, (incluso tirando un poco a dinosaurio) cuando propongo estas ideas, jeje.
17/10/2016 at 10:57
Parece que SOA tiene mala prensa en algunos ambientes, pero creo que realmente las nuevas «tendencias» de Microservicios y ahora Serverless no es más que otra implementación de los mismos principios.