Las “arquitecturas”
orientadas a servicios y las arquitecturas de microservicios se han vuelto muy
populares en los últimos tiempos. La razón para su popularidad viene dada por:
- Servicios
parecen estar fuertemente desacoplados unos de otros. Como se verá eso es
parcialmente verdad.
- Servicios
parecen soportar independencia de desarrollo y despliegue. De nuevo
veremos que esto es parcialmente verdad.
Arquitectura de servicio
La arquitectura de un
sistema se define por los límites que separan las políticas de alto nivel de
las políticas de bajo nivel y seguir la regla de la dependencia. Por esta razón
usar servicios con la creencia que se está usando una arquitectura es un error.
Los servicios que
simplemente separan el comportamiento de la aplicación son un poco más que
caras llamadas a funciones y no son necesariamente significativas
arquitecturalmente hablando.
Esto no quiere decir que
todos los servicios deberían ser arquitecturalmente significativos. A menudo
hay otros beneficios sustanciales al crear servicios que separan la
funcionalidad entre procesos y plataformas, pueden obedecer la regla de la
dependencia o no. Esto es simplemente que los servicios, en sí mismos, no
definen una arquitectura.
Una analogía útil es la
organización de funciones. La arquitectura de un monolito o un sistema basado
en componentes se define por ciertas llamadas funciones que cruzan límites
arquitectónicos y siguen la regla de la dependencia. Muchas otras funciones en
aquellos sistemas, sin embargo, simplemente separan un comportamiento de otro y
no son arquitecturalmente significativos.
Así que esto son
servicios. Servicios son, después de todo, simplemente llamadas a funciones a
través procesos y /o límites de la plataforma. Algunos de estos servicios son
arquitecturalmente significativos y otros no. Nuestro interés en este capítulo
es con el primero.
¿Beneficios del
servicio?
Esta sección va a retar
la actual y popular ortodoxia de la arquitectura de servicio.
La falacia del
desacoplamiento
Uno de los supuestos
beneficios de romper el sistema en servicios es que los servicios están
desacoplados unos de otros. Después de todo, cada servicio corre en diferentes procesos
o incluso en diferente procesador. Por lo tanto, aquellos servicios no tienen
acceso a las variables de otro. Lo que es más, la interfaz de cada servicio
debe estar bien definida.
Ciertamente, hay algo de
verdad pero no mucha verdad. Sí, los servicios están desacoplados en el nivel
de variables individuales. Sin embargo, todavía pueden estar acoplados por
recursos compartidos en un procesador o en la red. Lo que es más, podrían estar
fuertemente acoplados por los datos que ellos comparten.
Por ejemplo, si se añade
un nuevo campo a un registro de datos que se pasa entre servicios entonces cada
servicio que opera en el nuevo campo se debe cambiar. Los servicios deben estar
de acuerdo en la interpretación de los datos en este campo. De esta manera, los
servicios están fuertemente acoplados a los datos del registro y, por lo tanto,
indirectamente acoplados uno al otro.
Para interfaces que
están bien definidas, esto es ciertamente verdad. Pero no es menos verdad para
las funciones. Las interfaces de servicio no son más formales, ni más rigurosas
y no están mejor definidas que las interfaces de funciones. Claramente,
entonces, estos beneficios son una ilusión.
La falacia de la
independencia de desarrollo y despliegue
Otro de los supuestos
beneficios de los servicios es que un equipo dedicado pueden ser propietarios y
operar con ellos. Ese equipo se debe responsabilizar de escribir, mantener y
operar los servicios como parte de la estrategía de “dev-ops”. Con esta independencia
de desarrollo y despliegue se presume que sea escalable. Se cree que los
grandes sistemas de empresas se pueden crear por docenas, cientos e incluso
miles de servicios que se pueden desarrollar y desplegar independientemente. El
desarrollo, el mantenimiento y la operación del sistema se puede particionar
entre un número similar de equipos independientes.
Hay algo de verdad en
esta creencia, pero sólo algo. Primero, la historia ha mostrado que los grandes
sistemas de empresa se pueden construir de monolitos y sistemas basados en
componentes tan bien como en sistemas basados en servicios. Por lo tanto, los
servicios no son la única opción para construir sistemas escalables.
Segundo, la falacia del
desacoplamiento significa que los servicios no pueden ser siempre
desarrollados, desplegados y operados independientemente. En la medida que
estén acoplados por los datos o el comportamiento, el desarrollo, despliegue y
la operación se deben coordinar.
No hay comentarios:
Publicar un comentario