Ir al contenido principal

Cómo lograr una arquitectura de datos descentralizada con microservicios

Achieve decentralized data architecture with-microservices

Las razones que residen tras la aparición de arquitecturas basadas en microservicios son diversas. En primer lugar, se puede decir que los microservicios y la arquitectura orientada a servicios (o SOA) incluso luchan cuando se trata de desacoplar las funciones comerciales de los sistemas de información ejecutiva (SIE) para una gestión descentralizada.

Por otro lado, la implementación y la práctica de SOA se volvieron demasiado complejas, y se requería de una nueva forma de hacer las cosas más directas y menos normativas. Permitiendo así la elección entre diversas técnicas de administración para sacar un mayor provecho.

¿Qué son los microservicios?

Un microservicio es un servicio (en el sentido de SOA) que nunca comparte su contexto de ejecución con otros microservicios, sino que puede comunicarse con ellos.

La arquitectura en la que se basan éstos no es SOA, pues los microservicios son un caso especial de servicios: son servicios pequeños y autónomos que trabajan juntos.

A lo largo de los años, las arquitecturas basadas en los principios de SOA se han vuelto tan complejas como las arquitecturas monolíticas que se suponía que debían reemplazar y superar.

-No te pierdas: Arquitectura monolítica vs. Microservicios-

Los microservicios asumen que un servicio debe hacer una cosa y hacerlo bien. Este principio no es nuevo, ya que es el que subyace en el desarrollo de UNIX desde el principio: hacer las cosas bien y mantenerlas simples.

“Este enfoque ha surgido con el objetivo de responder más fácilmente a los problemas operativos.”

La arquitectura de microservicio establece principios arquitectónicos, indicando soluciones posibles y prácticas para la mayoría de los problemas.

-Antes de continuar: Lectura obligatoria sobre beneficios de la implementación de microservices-

Arquitectura de microservicios

A la mayoría les sorprende que uno de los principios básicos de una arquitectura de microservicios es la falta de una base de datos compartida. Un microservicio se basa en un sistema de persistencia que será el único para administrar y usar, en caso de que necesite hacer un estado persistente o almacenar datos externos.

La arquitectura de microservicios elimina el acoplamiento entre servicios a través de esquemas de base de datos. El único que debe contener semántica es la API de servicios. No es el esquema de una tabla. Esto también evita el acoplamiento entre los equipos.

Por otro lado, la partición del espacio de datos de la empresa de esta manera hace que sea necesario confrontar las actualizaciones de datos para evitar inconsistencias. Una solución es implementar un programa de gestión de datos maestros (MDM). La ejecución será por naturaleza compartida entre todas las bases de datos, lo que va en contra de los principios ontológicos de la arquitectura.

-Artículo técnico: Cómo crear microservicios con el módulo MSF4J de WSO2-

Además evita tener que realizar una limpieza y verificación de datos asegurándose de que nunca se produzcan errores de actualización. Es responsabilidad del equipo a cargo del ciclo de vida del microservicio tomar la decisión de seleccionar las tecnologías de implementación.

Otra consecuencia de la arquitectura de microservicios es que el equipo es responsable de su servicio durante todo su ciclo de vida. Esto significa que el equipo especifica, diseña, implementa, prueba, integra, implementa el servicio, pero lo más importante, proporciona soporte y mantenimiento al usuario.

Buenas prácticas para diseñar microservicios

En general, el diseño de microservicios debe garantizar un acoplamiento débil para permitir modificar los servicios de forma independiente y garantizar la autonomía en su funcionamiento.

Los servicios que están débilmente acoplados aprovecharán al máximo la arquitectura de microservicio, como tolerancia a fallos, adaptación a la carga, facilitación de implementaciones, etc.

Además debe tener gran unión para garantizar que los intercambios entre estos servicios sean lo más coherentes posible mediante las siguientes reglas:

  • Regla de la modularidad y la composibilidad: diseñar microservicios simples que se puedan componer o vincular a otros.
  • Regla de separabilidad: requiere que se aíslen las interfaces del motor. Las interfaces son estructurantes, no los microservicios internos.
  • Regla de representación: diseñar microservicios controlados por datos, que tengan una operación más simple, serán más robustos y su escalabilidad será mejor.
  • Regla de generación: no codificar cosas repetitivas y triviales y utilizar programas para codificar sin limitarte a usar archivos WSDL para generar código para las interfaces.
  • Regla de diversidad: tomar las decisiones tecnológicas y metodológicas necesarias según el problema a resolver y no porque haya un catálogo de software o una pila certificada por un gurú corporativo.
  • Regla de extensibilidad: tener en cuenta los cambios futuros en las elecciones de diseño. Al diseñar un esquema de representación, piensa quién tomará la suite y quién necesitará agregar atributos sin tener que cambiar el código de microservicio que funciona con la versión anterior.

-Leer más: Ventajas y desventajas de los microservices-

Claves para implementar la gestión de datos descentralizada en una arquitectura de microservicios

Antes de implementar la gestión descentralizada, es muy importante que te preguntes si realmente merece la pena. En caso de que la innovación en el negocio es frecuente e incierta y el SIE debe seguirla.

Un SIE diseñado sobre los principios de los microservicios es dinámico y escalable, incluso si su gobierno, que se ha descentralizado, no tiene nada que ver con lo que prevalecía cuando el SIE estaba compuesto por bloques funcionales más pesados.

El desarrollo de un microservicio por parte de un equipo autónomo e independiente no es una opción, es una condición necesaria para que este enfoque sea viable.

“Al practicar la arquitectura de microservicio, se busca una forma de estabilidad en cambio permanente. En este contexto, las reglas deben ser simples, pocas y relevantes.”

En ese sentido, la Micro Services Architecture (MSA) apoya la gobernanza descentralizada de tecnologías de información, con la finalidad de las organizaciones alcancen sus objetivos mediante el uso efectivo y eficiente de las tecnologías.

Por su parte, cuando se habla de SOA, hay que hacer énfasis en que la gobernabilidad de SOA permite la creación de servicios reutilizables, definiendo cómo se desenvolverá en el tiempo. De igual modo, se pueden establecer acuerdos que benefician a las organizaciones y a sus usuarios.

Si quieres conocer más sobre microservicios o quieres implementarlos en tu compañía, hazlo con un partner tecnológico con experiencia. ¡Contáctanos!

microservicios guía