arrangement-107872_640

 

El término “microservices” es uno de esos “palabros” que cada cierto tiempo, surgen y se ponen de moda. Aunque no sea una cosa nueva por supuesto (el concepto es el mismo que se siguió en el diseño del sistema operativo Unix), parece que le ocurre algo parecido al término REST… no es una cosa reciente, es bastante sencillo en el fondo, y está cobrando mucha relevancia (si no la tiene ya en los “ambientes arquitectónicos”).

Microservicios según Martin Fowler

Según el maestro Fowler, Microservicios es una aproximación de desarrollo que consiste en construir una aplicación sencilla como un conjunto de servicios pequeños. Aquí podéis ver su artículo (de obligada lectura).

Cada uno de estos servicios ejecutándose en su propio proceso y comunicándose entre sí mediante un mecanismo ligero, normalmente mediante un API basado en HTTP. Como aspecto muy importante, estos microservicios se construyen para dar soporte a una funcionalidad de negocio y puede ser desplegados de manera automática y sobre todo, de manera independiente al resto de servicios de la aplicación.

Son tan independientes, que incluso se pueden construir con un lenguaje distinto e incluso uno de estos microservicios podría tener su propia base de datos en la tecnología que le apetezca…

Microservicios versus aplicación monolítica

Quizás este es el cambio más importante de concepto cuando nos enfrentamos a los Microservicios por primera vez. Digamos que estamos habituados a un concepto más tradicional, el de la aplicación monolítica. Y cuando digo esto me refiero a la clásica aplicación web con páginas, lógicas de negocio y base de datos.

Por supuesto, con una aplicación orientada a servicios (SOA) este monolito no debe ser tal. Si lo hacemos bien, tendremos una aplicación sólo para el frontal (más bien varias de ellas para los diferentes canales) unas cuantas aplicaciones que proporcionan varios servicios SOA (no tiene por qué tener una relación uno a uno) y los accesos a las bases de datos, que pueden estar recubiertos a su vez por los servicios de backend o directamente integrada en los servicios anteriores.

Sea como fuere, normalmente, por motivos de gestión y a veces también de rendimiento, los servicios (un conjunto de ellos) se suelen agrupar en lo que llamamos aplicación desplegable, para entendernos, lo que en el mundo Java sería un EAR.

Por otra parte, con lo que he trabajado yo al menos, los backends suelen ser una aplicación única (un único EAR), por ejemplo con toda la lógica de negocio y acceso a datos de la aplicación de Clientes. Quiero decir con esto, que aunque siguiendo SOA tememos varios desplegables, hay veces , como en el caso de los backends que tomadas individualmente se podrían considerar como una aplicación monolítica.

El problema de las aplicaciones monolíticas

Por supuesto, el problema con estas aplicaciones monolíticas es fácil de ver. Cualquier cambio, aunque sea mínimo, implica un “empaquetado” de la aplicación y un despliegue de esta en su conjunto.

Esto como poco, puede resultar una operación tediosa, compleja y con riesgo. A poco que el equipo de desarrollo sea grande y que la aplicación tenga varios módulos, es difícil ponerse todos de acuerdo para subir una versión estable (sobre todo cuando no se usa integración continúa).

Además es posible que en el momento del despliegue de la nueva versión se produzca una interrupción del servicio… si, ya sé que no debería, que tendremos un cluster de nodos, que podemos pararlos y levantarlos de uno en uno para mantener el servicio.. pero las cosas no son tan sencillas. Si cambio por ejemplo, el modelo de datos quizás tenga que parar la base de datos…

Características de los Microservicios

Como decía al principio, el artículo de Fowler es muy interesante si queremos leer de primera mano las experiencias y consideraciones de este hombre. Si no teneis problema con el inglés os recomiendo la lectura del artículo donde explica las características de los microservicios, cuyos puntos básicos son los siguientes:

  1. Componentización vía Servicios
  2. Organización basada en capacidades de negocio
  3. Productos no proyectos
  4. “Smart endpoints and dump pipes”
  5. Gobierno descentralizado
  6. Gestión de los datos descentralizada
  7. Automatización de la infraestructura
  8. Diseño contra fallos
  9. Diseño para la evolución

Microservices y SOA

¿Microservices es lo mismo que SOA? ¿está relacionado? ¿son cosas distintas?… estas son las primeras preguntas que me hice cuando escuché por primera vez acerca de los Microservicios. Obviamente son las preguntas que todo el mundo se hace.

Según Fowler hay una diferencia significativa:

SOA se enfoca en integrar aplicaciones monolíticas entre sí mediante un ESB.

Aquí una frase lapidaria suya contra la que es difícil decir nada:

“En particular hemos visto muchas implementaciones (de SOA) malas y caras, desde la tendencia a ocultar la complejidad en un ESB, hasta iniciativas de varias años y con un coste de varios millones que no proporcionan valor, también modelos de gobierno centralizados que de manera activa inhiben el cambio…”

Sigue diciendo que esto ha provocado que algunos de los que abogan por los microservicios han rechazado la misma etiqueta de “SOA” (por los motivos indicados anteriormente), pero que también, hay otros que consideran que: “Microservicios es en realidad una implementación de SOA, pero esta vez hecha correctamente”.

Como él mismo dice en su artículo, Netflix es una de las empresas que hace esta relación entre SOA y Microservicios explícita… aunque en los últimos tiempos la ha llamado “SOA de grano fino”.

En mi opinión…

En mi humilde opinión, creo que estoy en el segundo grupo. Es decir, hay que diferenciar entre el concepto de SOA y la implementación que se hace. Si vemos el manifiesto SOA (la declaración de principios) ahí no se habla para nada que haya que tener un ESB, ni siquiera que nos tengamos que basar en en web services WS-*… (http://www.soa-manifesto.org/default_spanish.html).

Tampoco en los principios de SOA de Thomas Erl (http://pensandoensoa.com/2010/02/27/principios-de-soa/) se habla que haya que implementar SOA de ninguna manera de las criticadas anteriormente. En especial, se habla del principio de autonomía, de la abstracción, del bajo acoplamiento, de la interoperabilidad…

… y en contra de mi opinión

Y como no quiero recoger únicamente mi opinión, no quiero dejar pasar la ocasión de traer a colación la opinión muy fundada de  Germán del Zotto

Germán y yo mantenemos algunas discusiones (en el mejor de los sentidos) sobre muchos aspectos de T.I. y este no iba a ser menos por supuesto. Tal es así, que no quiere ni que se relacione SOA con Microservices.

Sobre este aspecto , cito (en formato tweet) algunos de sus argumentos que justifican que SOA no es lo mismo que Microservices los siguientes.  A continuación, indico mi opinión (en la que puedo estar equivocado por supuesto).

Los contratos no tienen por qué ser estándar

Esto es un poco discutible…. tal como yo lo veo, cuando SOA dice que los contratos deben estar estandarizados, no significa que deban tener un formato WSDL o WADL. Creo que más bien se refiere a que estén estandarizados en la empresa, es decir, que los servicios puedan usar mayormente el mismo tipo de datos.

Por otra parte, si pretendemos que el contrato del servicio indique cual es su interfaz, esto se puede hacer de muchas formas pero los equipos que pretendan usarlos deberán entenderlo, es decir, debe cumplir algún estándar (aunque sea propietario e inventado en la empresa) que todas las partes entienda… en este sentido se puede considerar como “estándar”.

La granularidad puede ser cualquiera

Creo que tampoco dice nada SOA sobre como tiene que ser la granularidad del servicio.

Evidentemente y como dice el propio Fowler si estamos hablando que la integración entre diferentes servicios se hace en remoto, normalmente mediante HTTP, el grano de los servicios no puede ser muy fino porque el rendimiento se degradaría. Lo normal en este caso es crear operaciones de negocio de cierto nivel, nada de un servicio que actualice un apellido (por poner un ejemplo), en su lugar, lo normal sería un servicio que actualice toda la información de un cliente en una sola llamada.

El discovery es opcional

Tradicionalmente en SOA tenemos dos momentos donde se hace el “discovery” o descubrimiento de los servicios.

  1. Uno en tiempo de diseño realizado por los analistas que buscan si existe un servicio con una funcionalidad determinada dentro de la empresa o si ya exista si se tiene que extender o modificar para incorporar una nuevo requerimiento.
  2. También existe el descubrimiento en tiempo de ejecución, basado en un registro de servicios “inteligente” que es capaz de proporcionar el endpoint en función de varias reglas, por ejemplo dependiendo de quién llama y a que hora del día.

Ahora pongámonos en un entorno más “moderno”, digamos varios servicios REST para la gestión los clientes (tipo CRUD). Pongámonos en el papel de un desarrollollador de Backend que tiene que indicarle al desarrollador de frontend cómo se invocan estos servicios (es decir, su interfaz):

¿Cómo haríamos eso? ¿Cómo sabe qué servicios hay y cuáles son sus parámetros?

Evidentemente siempre podemos recurrir al documento tipo Word donde se describen los servicios con los ejemplos correspondientes. También podemos recurrir a herramientas más sofisticadas como Swagger que con unas anotaciones en el código fuente es capaz de generar una web de documentación de los servicios e incluso que se puedan ejecutar mediante unos mocks.

Por otra parte, si nos referimos en en tiempo de ejecución, el propio “estándar” de REST incorpora HATEOAS es decir, es decir los propios servicios dan “pistas” al desarrollador de cómo se invocan a servicios relacionados. Por ejemplo, en el JSON devuelto al consultar a un cliente, se puede indicar un enlace al servicio de consulta de dirección postal
¿No es esto descubrimiento de servicios? sí, ya sé que con otras técnicas y diferente de lo que se suele ver con web services, pero en mi opinión siguen siendo una especie de descubrimiento.

En definitiva, un tema este el de los Microservicios que me apasiona y que habrá que seguir de cerca… ¿no os parece un tema interesante para debatir en el grupo de Linkedin SOA Hispano?

 

Anuncios