Categoría: Arquitectura de Software

Microservicios ¿para qué y cuándo usarlos?

Destacado ~ yoryo77 ~ Deja un comentario

“The ability of your business to change quickly, innovate easily, and meet competition wherever it arises is a strategic necessity today” – Mulesoft.

En esta entrada de blog vamos a hablar acerca de la arquitectura de microservicios y el porque cada ves más las empresas buscan tener soluciones tecnológicas basadas en esta arquitectura que sin duda esta tomando más relevancia en la industria en los últimos años. ¿Qué hace de esta arquitectura una manera de agilizar la TI de la empresa respecto a los objetivos estratégicos de la misma? Ahora lo veremos.

¿Qué son los microservicios?

Son soluciones enfocadas en el negocio que responden al cambio de manera ágil. Ya que cada pieza de software es autónoma, gobernada de manera independiente y fácil de escalar por lo que reaccionar antes los cambios del mercado resulta más eficiente que trabajar de la manera convencional; además los microservicios son piezas de software que se entrelazan para brindar lógica a soluciones de negocio existentes y futuras dando así un mayor retorno de inversión (ROI) para la empresa.

Los microservicios (los cuales encapsulan funciones de negocio) deberían considerarse activos digitales ya que por cada microservicio que se desarrolle dentro de la empresa se esta generando funcionalidad valiosa que se puede reutilizar después en otros contextos para resolver problemáticas nuevas y de esta manera no tener que escribir una y otra vez software para solucionar temas similares. De esta manera el área de TI debe ser capaz de facilitar nuevas capacidades de negocios (cambios) reutilizando estos activos digitales.

Orígenes de los microservicios

Todo nace de hace algunas décadas donde los componentes de software se solían empaquetar en soluciones monolíticas. Todos los módulos tanto los componentes de interfaz gráfica, componentes de negocio, componentes de interacción con base de datos, etc. se empaquetan en un mismo ejecutable el cual se solían desplegar en un servidor de aplicaciones como JBoss o WebSphere.

Algunas desventajas de esta arquitectura monolítica tradicional:

  • Difícil de mantener, todo el código base se suele encontrar junto.
  • El escalamiento se logra creando copias de toda la aplicación.
  • Un error en un módulo dado puede comprometer todo el sistema.
  • Es complicado adoptar nuevas tecnologías, un cambio tecnológico suele afectar la aplicación completa. 

Después vinieron modelos más sofisticados como es la Arquitectura SOA. En cierto modo, los microservicios son la evolución natural de las arquitecturas orientadas a servicios (SOA). La filosofía de SOA es reutilización de componentes de software. Pero hay diferencias importantes entre los microservicios y estas arquitecturas.

Algunas de las desventajas de SOA:

  • Se solían ocupar metodologías waterfall (aún no se utilizaban las metodologías ágiles de hoy en día como scrum).
  • Se solían desplegar las operaciones y servicios como un solo ejecutable, se debía hacer una evaluación de regresión a todo el sistema al hacer un cambio.
  • Al hacer actualizaciones todo el sistema resultaba afectado y debía darse de baja.
  • En las soluciones SOA se solía utilizar SOAP para implementar servicios web.
  • Las arquitecturas SOA solían utilizar Enterprise Service Bus (ESB) para las comunicaciones lo cual hacia la solución más compleja.
  • Las arquitecturas SOA solían compartir una sola base de datos RDMS.
  • Las arquitecturas SOA eran difíciles de escalar ya que se escalaban sistemas completos.

La arquitectura de microservicios vienen a resolver muchas de esas desventajas de monolítico y de las implementaciones fallidas de SOA ya que se aprendió del pasado a continuación ahondaremos un poco más en el origen de los microservicios.

Origen de la palabra microservicio

El término «microservicio» se utilizó por primera vez a mediados de 2011 en un evento de arquitectos de software sobre tecnologías cloud. En 2012, varias compañías de TI (principalmente Netflix y Amazon) comenzaron a considerar la idea de los microservicios, y para 2014, las grandes referencias de TI habían comenzado serias discusiones sobre la inversión en ellos para el futuro.

Pero ¿cómo se consumen estos servicios?

Técnicamente hablando un microservicio es un componente de software que expone su funcionalidad regularmente por medio de la arquitectura REST, el miscroservicio se encuentra alojado ya sea algún lugar de la red, en la nube corporativa o pública de la empresa.

Como cualquier otro servicio REST su contrato se puede definir utilizando algún lenguaje de modelado de APIs REST como RAML o Swagger para hacer la definición formal del contrato. Finalmente la forma de comunicarse al servicio es de manera síncrona o asíncrona y dependiendo de la forma de comunicarse con el es la tecnología a utilizar.

Para un consumidor final es más común que la comunicación con el microservicio sea mediante el protocolo HTTP de manera síncrona y además no llamando de manera directa al servicio sino usando un componente intermedio llamado API Gateway del cual hablaremos más adelante. Los microservicios pueden comunicarse entre sí de forma nativa debido a la adopción en la industria de estándares como HTTP y JSON. En otras palabras, son intrínsecamente interoperables pero también pueden existir otro tipo de comunicación entre ellos, como es la comunicación asíncrona utilizando mecanismos de coreografía; como se trata de una comunicación basada en mensajes, el microservicio cliente asume que la respuesta no se recibirá inmediatamente y que es posible que no haya ninguna respuesta.

Usar la tecnología de los microservicios lo más agnóstico posible

En el mundo de la tecnología las cosas cambian a cada minuto, así que nuevos lenguajes, frameworks y herramientas están saliendo todo el tiempo. ¿Qué pasa si con el tiempo queremos experimentar con una nueva tecnología que resuelva las cosas en menor tiempo y hacernos más productivos? En el mundo de los microservicios esto significa que debemos usar tecnología de integración lo mas estándar posible y no casarla a una tecnología de implementación dada, por lo tanto es recomendable usar tecnología de integración estándar como REST, HTTP y JSON y tampoco casarnos con un lenguaje de programación dado o algún proveedor de servicios cloud particular.

Arquitectura de microservicios

El sitio microservices.com propone el siguiente modelo de referencia de la arquitectura de microservicios, las empresas que han adoptado con éxito los microservicios han usado una serie de patrones arquitectónicos comunes. Esta arquitectura de referencia de microservicios ya la han usado muchas compañías y esta relación entre los componentes del sistema se ha documentado con algunos de los patrones de diseño principales que se han identificado con el paso del tiempo implementando estas arquitecturas.

Reference Architecture Diagram
Arquitectura de referencia para microservicos

Algunos de los componentes a destacar en la arquitectura de referencia son:

A. Discovery: El descubrimiento de servicios asigna nombres de servicios lógicos a direcciones físicas. Los microservicios utilizan el descubrimiento de servicios para encontrar la dirección física de un servicio determinado, ya que podemos tener cientos de servicios o más desplegados en nuestro sistema es necesario tener identificadas las direcciones e IP’s de nuestros microservicios para lograr una organización interna mucho mejor.

B. Microservices: Los microservicios generalmente se implementan en varias instancias para disponibilidad y confiabilidad. Cada microservicio contiene una biblioteca local que controla cómo los microservicios se comunican entre sí.

C. Control layer: Cada microservicio envía y recibe metadatos: datos de latencia, datos de registro, información de enrutamiento, etc. Todos estos metadatos se comparten en una capa lógica llamada Capa de control.

F. Applications: Típicamente escritas por terceros, las aplicaciones realizan funciones especializadas como persistencia o búsqueda. Las aplicaciones suelen tener entradas estáticas en el descubrimiento de servicios y pueden estar detrás de un balanceador de carga.

Para tener una descripción más completa de esta arquitectura de referencia, visitar el sitio microservices.com

Clasificación de los microservicios

Cada empresa puede realizar la clasificación de los microservicios según los estándares internos de la empresa o siguiendo modelos mas generales a nivel industria. Por ejemplo la empresa Mulesoft impulsora de tecnologías como REST y RAML propone la siguiente clasificación:

En la capa de System API’s es donde se definen microservicios de más bajo nivel para gestión directa de entidades de negocio como Cliente, Pedido o Factura. Estas API del sistema están en línea con el concepto de un servicio autónomo que ha sido diseñado con suficiente abstracción para ser agnóstico a cualquier proceso de negocio y típicamente son usadas para hacer operaciones de tipo CRUD sobre una entidad sin tener lógica de negocio asociada o si acaso con lógica muy básica.

Las API del sistema se pueden componer con otras API para formar un agregado, a esta capa se le conoce como Process APIs. La composición de las API del sistema puede tomar la forma de orquestación explícita (llamadas directas) o mediante coreografía (llamadas asíncronas), todo esto para satisfacer un requerimiento de negocio mediante composiciones, por ejemplo para el cumplimiento de pedidos, alta de un cliente en una empresa, hacer un traspaso bancario, etc.

Tanto las API del proceso como las del sistema deben adaptarse de cara al consumidor y a las necesidades de cada canal de negocios y
punto de contacto digital.
Un mecanismo de seguridad particular podría ser necesario en alguno de los canales consumidores; el patrón API Gateway es un buen enfoque porque es donde están estas particularidades están configuradas, aspectos como seguridad, logging, auditoria y el filtrado de datos se configuran en esta capa.

¿Qué tan grandes o pequeños son los microservicios?

La palabra micro apunta a algo muy pequeño y conciso, dado esto ¿Un microservicio se mediría por la cantidad de líneas de código? ¿Por su complejidad ciclomática? ¿Por su granularidad?

Aunque la palabra micro apunta a algo muy pequeño en el tema de los microservicios no siempre es así ya que existen servicios de diversos tamaños, la palabra micro tiene que ver con que el microservicio tiene una interfaz pública o contrato «micro«.

Proporciona la menor cantidad posible de operaciones públicas, literalmente, un servicio «micro». Ejemplo:

Alta cohesión

Si queremos cambiar el comportamiento de algo es mejor que ese algo se encuentre en un mismo lugar, hacer cambios en un montón de lugares distintos puede resultar lento y riesgoso y es por esto que debemos evitar tener una misma funcionalidad regada en diversos servicios por lo tanto es recomendable tener juntas las operaciones que tienen que ver entre si y encontrar las fronteras adecuadas de nuestro microservicio con otros servicios del sistema.

Identificando candidatos a microservicios

El más obvio candidato a microservicio es aquella entidad que representa algo para el negocio, ejemplo para un banco podemos tener un microservicio que tenga que ver con las operaciones de tarjetas de crédito y otro microservicio para tarjetas de débito. Otro ejemplo es la visita que hace un  paciente a un hospital podría ser gestionada por un servicio de gestión de consultas que a su vez hace uso de servicios de más bajo nivel, por ejemplo de un servicio que gestione pacientes y de otro que gestione a los médicos:

También es importante definir la granularidad de cada operación del microservicio. Mientras la granularidad sea mas gruesa mas responsabilidades tendrá una sola operación, mientras la granularidad sea mas ligera la responsabilidad será mas especifica. En este caso hay que tener cuidado de no caer en antipatrones como el conocido como ‘nanoservicio’ en el que las operaciones de un microservicio son demasiado especificas a nivel de dato de una entidad, por ejemplo un servicio de gestión de clientes que tuviera la siguiente operación demasiado especifica ‘setCustomerName’.

Diferencias entre API y Microservicios

  • El API es una interfaz que expone un grupo de operaciones a un consumidor mientras que un microservicio puede ser uno de esos endPoint del API.
  • El API es el contrato para interactuar con el microservicio el cual es la pieza de implementación de todo o parte de ese contrato. 

Principios de Diseño de Servicios

Existen algunos principios de diseño de servicios sugeridos por Thomas Erl en su libro «SOA Principles of Service Design» los cuales son aplicables a la arquitectura de microservicios como:

  • Standardized Service Contract: Contrato estandarizado para todos los microservicios.
  • Reusability: Piezas reusables y adaptables a diferentes contextos dentro del negocio.
  • Las dependencias entre el servicio y su entorno es minimizado aplicando el principio de Loose coupling, los cambios que se apliquen a loa lógica interna del servicio deben afectar lo mínimo o nada a los consumidores.
  • Autonomy, característica de runtime que promueve la mejora de escalabilidad, performance y disponibilidad, los cambios a un servicio por ejemplo el deploy de este no tiene que afectar a otros servicios.
  • Composability, permite a cada servicio entregar valor en diferentes contextos.
  • Discoverability, permite que el servicio esté publicado en un ‘registry’ para exponer lo necesario para ser consumido.

Recomendaciones finales

Es altamente recomendable hacer un análisis para saber si nuestro proyecto es candidato para usar arquitectura de microservicios.  No todos los proyectos son candidatos para utilizar esta arquitectura, por ejemplo si estamos trabajando en un proyecto para resolver una necesidad temporal o en un proyecto pequeño tal vez no sea necesario invertir en una arquitectura compleja de microservicios, recordemos que la arquitectura si bien nos da muchos beneficios también introduce complejidad al estar trabajando en un sistema distribuido.​

La adopción de la arquitectura de microservicios no es simplemente una decisión técnica, también tiene un impacto cultural en la organización. No todas las organizaciones están listas para capitalizar esta arquitectura.

Si ya decidimos que los microservicios son para nosotros entonces sería recomendable analizar los flujos de datos y actividades dentro del sistema, identificar la actividad tanto síncrona como asíncrona. Analizar los ‘paths’ de flujo de la información, este ‘aproach’ es bueno para descomponer el sistema en mensajes y a priori comenzar a identificar potenciales servicios. 

Lejos de que se llegue a un acuerdo del significado de la palabra microservicios tenemos preferiblemente que reflexionar acerca del beneficio que nos da utilizarlos. Así que ¿En qué casos de uso da más valor utilizar microservicios? Yo diría que en aquellos donde queremos tener la habilidad de tener ciclos altos de velocidad de entrega de funcionalidad/software (faster time to market) y en aquellos casos en donde la estrategia de la empresa apunte a desarrollar piezas de software reutilizable que potencialmente pueda usarse para resolver problemas similares a futuro con un alto nivel de ROI (retorno de inversión).

El implementar soluciones con microservicios también conlleva costos:

  • El cómputo distribuido siempre viene acompañado de complejidad (latencia, escalabilidad, incremento de tráfico en la red, únicos puntos de falla, etc).
  • También se debe contar con soluciones robustas de integración continua y despliegues automáticos de software para reaccionar rápido ante los cambios.
  • Las pruebas se complican en el modelo distribuido.

La mayoría de las organizaciones tienen una base de código ‘legacy’ monolítico existente y están migrando poco a poco funcionalidad a microservicios de forma incremental así que no se trata muchas veces de adoptar la tecnología de golpe, sino seguir una estrategia en fases la cual es una buena forma de adoptar gradualmente el cambio de paradigma.

Aquí concluimos con este resumen de lo que es la arquitectura de microservicios y el porque es una apuesta solida en el presente y futuro de la creación de activos de negocio reutilizables. Nos volvemos a encontrar próximamente en más apasionantes temas de tecnología.

Referencias