gummibarchen-359950_640

Al hilo de este artículo en el que se plantea si un microservicio debe tener su propia base de datos,  me viene a la cabeza una reflexión sobre el  principio de autonomía de SOA que dice así:

Para que un servicio pueda llevar a cabo sus funciones de manera consistente y confiable, la lógica se ejecuta dentro del mismo debe tener un grado significativo de control sobre su entorno y recursos.

De la teoría a la práctica

Recuerdo que cuando lo vi por primera vez  no me dejaba de sonar como algo un poco extravagante ¿cómo iba un servicio por si mismo a tener completa autonomía sobre el entorno sobre el que se ejecuta?. Se daba por descontado que cualquier software de este tipo iba a utilizar una base de datos de compartida con otros, en un servidor de aplicaciones igualmente compartido que se ejecutaría sobre una máquina sobre la que se ejecutan estos y otros procesos. En resumen, más bien se consideraba como un principio que se quedaba poco más o menos en el plano teórico.

Pero en los últimos tiempos, con el auge del concepto de microservicios, este principio ha tomado una especial relevancia. Y es que al día de hoy, gracias al cloud y a la contenerización (como Docker) podemos tener un servicio con completa autonomía con un coste y esfuerzo bastante bajo.

image

Gracias a la contenerización que se puede obtener hoy en día, desplegado en un cloud, podemos tener una «maquina» únicamente para un servicio. Por fin, en la práctica podemos cumplir con el principio de autonomía que forma parte de la base de la orientación a servicios.

Principio de autonomía también dentro del propio servicio

Pero yo diría que el concepto de autonomía va incluso más allá… no sólo en lo relativo a los recursos de infraestructura que necesita un servicio para ejecutarse. Habría que aplicarlo también como concepto en el propio código fuente, aunque sea dentro de una sola aplicación, y me explico…

Desde el momento mismo en que aprendemos programación, se nos dice que un trozo de código no puede estar repetido, por aquello de la mejora de mantenimiento. Que tener repetido el mismo código en varias partes de una aplicación es una mala práctica… y por eso diseñamos un software para que tenga clases comunes reutilizadas en todo el código, ya sea mediante la herencia, la delegación, como una paquete de utilidad, etc. etc.

Evidentemente, el mantenimiento mejora porque cuando este código cambie únicamente hay un sitio donde cambiarlo… pero como todo, tiene su contrapartida… y es que nuestro código será más frágil. ¿Que pasa si se cambia esta parte común y ampliamente reutilizada y tenemos un error? pues toda la aplicación se vendrá abajo.

Si pensamos en que nuestra aplicación, por ejemplo, de gestión de clientes tiene, digamos, 25 servicios y todos usan una misma clase común, por ejemplo, la clase padre de Cliente, un sólo cambio con un bug nos echará por tierra los 25 servicios. Ahora bien, si duplicamos el código y cada servicio tiene su propias líneas de código de uso exclusivo (a costa de dificultar el mantenimiento global de la aplicación), es evidente que un problema en una servicio no afectará al resto.

¿Podríamos llamar a esto autonomía de un servicio intra-aplicación? Tal vez… pero en algún caso concreto y tipo de aplicación, yo dormiría más tranquilo teniendo el código un poquito repetido, con unos servicios más autónomos respecto a sus hermanos de aplicación.