.png){kind=small}
.png){kind=small}
Día a día, en el universo tecnológico, se crean nuevas teorías y tendencias para conseguir construir y mantener un nuevo sistema e incluso un nuevo negocio. Habrá visto aquí, en el Blog de Sensedia, mucho sobre la transformación digital, pero un tema muy importante, desde el punto de vista de la innovación y transformación, es cómo el modelo arquitectural destinado a servicios (SOA) pudo abrir caminos hasta uno de los modelos que más se habla en la actualidad, el de Microservicios.Abordaré en este posteo la mayoría de los temas que nos lleva de SOA a Microservicios, pasando es claro que por APIs y REST.
Para hablar en SOA, es imposible no citar a Thomas Erl, que en el libro SOA: Principios del Diseño de Servicios, él plasmó las 8 «reglas» para definir un servicio, y ellas son:
Esta tal vez sea la característica que más comúnmente está asociada al SOA. Cuanto más genérico sea el Servicio mayor es la probabilidad de reutilización. Esto permite que el área de TI entregue rápidas respuestas a nuevos requerimientos de las áreas de negocio de la empresa, siempre que estos Servicios estén definidos en conjunto: TI y área de negocios.Queda claro que un Servicio no es propiedad de un equipo de desarrollo. El Servicio pasa a ser un activo de la empresa.
Todo servicio tiene un «contrato» entre el requirente y el proveedor de este servicio. El «contrato» informa qué hace el Servicio y cómo se comunica (qué debe recibir y qué debe entregar).Es innecesario decir que la empresa debe definir sus modelos de descripción y que eso requiere mucha disciplina.
El acoplamiento se refiere a una medida de dependencia.Un bajo acoplamiento significa que algunas implementaciones específicas de un Servicio pueden ser sustituidas, modificadas y evolucionadas sin que los consumidores de este Servicio sientan alguna discontinuidad. Queda claro que los Servicios no deben expresar la lógica (reglas) del negocio.
Los Servicios son como «cajas negras», lo que significa que la lógica no precisa ni debe ser expuesta, simplificando el contrato formal.Guardando los detalles también permite que podamos modificar la lógica evolucionándola a lo largo del tiempo sin comprometer las «obligaciones» del Servicio publicadas en su contrato formal.
Separar un gran problema en varios pequeños no es una novedad. Este mismo principio se puede utilizar en la construcción de los Servicios. Así, un Servicio puede «llamar» a otro(s) para ejecutar su tarea. La composición también es una forma de reutilización.
Autonomía significa la capacidad de auto gobernarse. Un Servicio autónomo es aquel que no depende de un elemento externo para ejecutar su lógica.
Los servicios evitan información de Estado.Debido al hecho de que un Servicio será reutilizado, se debe tener cuidado de no crear muchas instancias de este Servicio sobre la infraestructura. Esto significa que para que un Servicio tenga disponibilidad, él debe evitar retener informaciones específicas a una determinada actividad.
O sea, estamos hablando de Visibilidad.Un contrato formal bien descrito y estandarizado evita que nuevos requerimientos resulten en Servicios redundantes. Además de esto la arquitectura debe proveer mecanismos que faciliten el descubrimiento de los Servicios por medio de Directorios y Registros.
Para reforzar la definición de SOA, conviene dejar explícito lo que no forma parte de ese concepto.SOA no es:• una tecnología. SOA está más basada en logística y conceptos y menos en herramientas;• un producto, por lo tanto, no es posible comprar SOA;• WebServices, XML y BPM. Ellos están relacionados en el mundo SOA, pero son distintos en el mundo de TI. Por lo tanto: SOA ¡= WebServices ¡= XML ¡= BPM
Quisiera hacerles una pequeña analogía para una mejor comprensión de SOA en nuestro día a día.Entonces, imagina que eres un aplicativo, y necesitas usar servicios para conseguir cumplir tus tareas diarias. Tranquilo, voy a darte un ejemplo.Todos los días, despiertas por la mañana y vas hasta la cafetería a tomar tu desayuno, en ese momento estás utilizando un servicio. El servicio del desayuno de la cafetería.Más tarde en ese mismo día, necesitas lavar tu ropa, entonces utilizas otro servicio disponible, el de la lavandería y así en más.Por otro lado, observa el ejemplo de servicio que no sigue estándares de forma correcta: imagina que en la cafetería es posible comer y lavar la ropa, o sea, el servicio no es específico ni actúa en solo un objetivo.Bueno, en modo general y extremadamente simple, eso es SOA. Son servicios independientes que componen un sistema, pero pueden ser consumidos por otros servicios de forma simple, rápida y muy bien gestionada, haciendo que todas las transformaciones necesarias para que los servicios se comuniquen sin complicaciones.
Un punto muy interesante de tratar es sobre el Gobierno Corporativo dentro de SOA. ¿Qué sería eso?Gobierno Corporativo es un conjunto de personas, políticas e incluso procesos que garantizarán que su estrategia SOA sea implementada y resulte exitosa.Algunas ventajas que el Gobierno Corporativo trae:
Bueno, ahora que ya conoce SOA, trabajemos un poco de cómo logras realizar la orquestación necesaria de sus monolíticos para esta arquitectura.Con la necesidad de hacer el desacoplamiento de un sistema monolítico en servicios especializados, el cual depende solo del equipo que está implementando, se creó una necesidad de conseguir realizar las transformaciones y comunicaciones entre sistemas.O sea, queremos responder la pregunta: ¿Cuál es la mejor forma de desmembrar un sistema monolítico en Microservicios?Esa orquestación de los servicios para que todo funcione de la mejor manera posible puede ser realizada de algunas maneras diferentes, como por ejemplo en código. Así, no es necesaria una herramienta comprada para tener SOA de verdad.Pero la entrada de esas soluciones «armadas» en el mercado ayudó mucho a atomizar el estilo arquitectural en las empresas. De esa manera entramos con un nuevo componente arquitectural que hará ese control, el ESB.ESB, o Enterprise Service Bus, es un Middleware que centralizará toda la integración en una arquitectura SOA, realizando la orquestación de los formatos de salida y entrada de todos los servicios que están con «plugs» en él. De esta manera resulta mucho más amigable para que un desarrollador diseñe y codifique las llamadas de acuerdo con la necesidad.Por otra parte, por ser una capa que hace este control conseguirás realizar logs muy importantes para un posible problema que pudiera ocurrir y requerir seguridad en todas las llamadas, consiguiendo proteger su backend.
Si, parece difícil creer eso, ¿no es así? Pero voy a explicarte por qué.La atención de sus consumidores es lo más valioso que existe. Las marcas están realizando ese trabajo con tanta excelencia en la jornada digital que hoy vale más la pena (para el consumidor) estar atento a una aplicación que en lo que está a su alrededor, físicamente.Al final, ese ambiente virtual permite diversos tipos de distracciones: promociones, productos, trabajo y entretenimiento con redes sociales o juegos.Con la evolución de Internet como un todo, la creación de e-commerces y la posibilidad de interacción entre Cliente y Servidor, se crearon nuevos escenarios en el cual el desarrollador de la comunidad puede ayudar y atomizar su negocio.Si sigues el Blog de Sensedia, debes saber que a partir de aquí estoy hablando del surgimiento de la herramienta que acelera y permite la transformación digital, las APIs.Junto con las APIs, el protocolo HTTP y buenas prácticas RESTFul fueron adoptados para ganar agilidad, practicidad y simplicidad en las integraciones y exposición de sus servicios/aplicaciones.¿Por qué hablar de esos conceptos en un artículo que trata sobre el tema «de SOA a Microservicios»? Bueno, son exactamente los Microservicios que apalancaron la posibilidad de escalabilidad de forma ágil, y para que la arquitectura acompañe esa evolución algo debía cambiar.
En 2012 nace el término Microservicios (o en su original, en inglés, Microservices), una nueva tendencia arquitectural que está considerada como la evolución de SOA.No obstante, hasta 2014, Microservicios no era tan popular ni algo tan definido. El gran «marco» en la historia de este modelado arquitectural fue ese posteo escrito por Martin Fowler, en el cual todas las características fueron definidas, e incluso la idea de que un Microservicio puede ser un producto por si solo fue propuesta y hoy muchas empresas están trabajando de esta manera.Ahora, como primera cosa, es necesario entender el motivo de este nuevo diseño. Entonces, vayamos a los hechos:1. La orientación a Servicios es fundamental, ya que un Microservicio es nada más ni nada menos que un Servicio completamente independiente;2. En el modelo anterior, el banco de datos del servicio es relacional y transcendente a todos los servicios creados, y en el nuevo modelo cada Microservicio posee su propio banco de datos;3. La orquestación de llamadas precisaba de un ESB, que es caro y pesado, y ahora con la implementación del REST, la necesidad de transformaciones y llamadas está simplificada;4. La seguridad y posibilidad de control aumenta aún más, ya que cada Microservicio tiene su propio API Gateway, que puede aplicar capas de seguridad para cada llamada e incluso posee un trace mucho más completo en la comunicación entre Servicios;5. La exposición externa queda a cargo de una API Management Solution, que tendrá todo el control de desarrolladores y aplicaciones, además de seguridad y todas las posibilidades para proteger su backend.¡Ahora estarás pensando en cómo esa maravilla puede ser implementada! ¡Vamos!
Existen algunas maneras de conseguir llegar en el producto final: su Backend totalmente fragmentado en Microservicios. Voy a dar algunos ejemplos de cómo comenzar a modificar su arquitectura dirigida a ese camino. El primer modelo y más adecuado sería realizar la reconstrucción del backend con la arquitectura adecuada.Pero, sabemos que para una gran empresa, este tipo de abordaje es inadecuado por la inversión ya realizada en todos sus servicios creados y por la complejidad de realizar una tarea de ese tipo. Por ese motivo, creo que es posible utilizar algunas estrategias que nos dirijan a un futuro buscando Microservicios y ya dirigiendo el backend para el futuro. Entonces, comenzaré a hablar del segundo modelo.Para eso, primero es necesario crear una API Front, o sea, una pequeña capa en el frente de sus servicios ya implementados en SOA, para que la exposición pase a ser realizada en REST. De esta manera, las transformaciones y orquestaciones del ESB ya no serán necesarias, porque ahora es posible tener solo una herramienta de API Management Suite para realizar este trabajo, ganando en escalabilidad y facilidad para abrir estas APIs a la comunidad.En cuanto a la tercera opción, esta es para las arquitecturas que aún no consiguieron diseñarse para SOA. Para hacer eso, el primer paso es conseguir definir los servicios que compone su monolítico, o sea, crear un diseño que analice el proyecto para el futuro. En este punto es súper interesante usar el apoyo de una consultora especializada en SOA y APIs, ya que su visión de cómo descomponer el backend será mucho más amplia y viable.En otras palabras, ¡hacer el diseño de servicios sin una visión especializada puede ser un desafío y más!Después de este primer diseño, es necesario crear una API Front adaptada al nuevo diseño. Esta capa será entonces responsable por la disrupción inicial de su arquitectura, ya que el consumo interno será realizado por medio de las APIs expuestas de ese modo. Después d eso, tendrás más tiempo para conseguir realizar el refactory de su backend orientado a la visión de servicios creada.Bueno, estas son algunas de las estrategias a ser adoptadas para conseguir adoptar el Agile Architecture, y adaptarse a la evolución digital de manera completa.
Estoy seguro que este universo está siendo muy hablado en su empresa.No sería para menos: Microservicios están en la boca de todos y la duda de cómo surgió y cómo puede ser alcanzado es siempre un debate interesante.Sensedia está a disposición para discutir y ayudarte a abrir puertas al camino de la arquitectura de Microservicios.
Hey, click and join the Sensedia News!
