Servicios

Para evitar confusiones primero debe saber exactamente qué es un servicio (o web service). Un servicio es cualquier recurso disponible de forma remota que puede responder a solicitudes. Esto significa que los servicios proporcionan los mecanismos que hacen que las URL funcionen. La totalidad de la web (también conocida como la nube) puede verse como una colección de proveedores de servicios de URL (servidores) y consumidores (clientes) que interactúan.

API

Las URL específicas a menudo se denominan endpoints, mientras que los conjuntos de endpoints relacionados se conocen como API. Cuando se trata de describir la arquitectura de la aplicación, los servicios a menudo se denominan API o interfaz de programación de aplicaciones. Esto es para comunicar la unidad de propósito con las API que se encuentran en los paquetes de software, es decir, actúan como interfaces para los puntos de unión entre los componentes del software.

Hablando en términos generales, los clientes "consumidores" utilizan la API de consumo para cumplir su propósito, mientras que la API interna existe para proporcionar las interacciones necesarias para las operaciones de la primera, denominada API de "infraestructura".

Aplicaciones web

El trabajo de las aplicaciones web es proporcionar y consumir servicios. Al final del día, es por eso que existen. La pregunta es: ¿cuál es la mejor manera de diseñar aplicaciones web que sean duraderas, fáciles de mantener y efectivas?

Diseño interno y arquitectura externa

La arquitectura de microservicios (y su predecesora, Arquitectura Orientada a Servicios o SOA), toma el propósito de las aplicaciones web, es decir, exponer servicios, y los convierte en un mecanismo del diseño de la aplicación. Vamos a analizar detenidamente el por qué de esto y a ser honestos sobre si tiene sentido hacerlo y cuándo hacerlo. Porque lo último que tú y yo queremos es aplicar una técnica a una situación porque es genial o está de moda.

Entienda que "micro" se refiere no solo al tamaño de un servicio, sino también a la intención: los microservicios están destinados a contener un conjunto de capacidades relacionadas y exponerlas como un recurso de red. Luego, crea la aplicación a partir de una colección de estos recursos de red, también conocidos como servicios.

La distinción entre diseño de aplicaciones internas y arquitectura de aplicaciones externas se vuelve borrosa. Es difícil decir exactamente qué es el exterior de una aplicación y qué son los elementos o nodos de una aplicación.

Ese siempre ha sido el caso: incluso la base de datos remota, los servicios externos o el cliente del navegador deben verse como elementos de una arquitectura de aplicaciones.

Componentes

La conclusión en el diseño de software es que debe dividir las cosas en partes pequeñas y luego relacionarlas para realizar el trabajo. Esto se hace en todos los niveles del software, desde las funciones en adelante. Cuando se trata de la estructura general de una aplicación, la pregunta es: ¿cómo dividirla para obtener el mejor resultado?

Arquitectura en capas

Durante mucho tiempo, la respuesta a esta pregunta (para aplicaciones web) fue: dividirla en capas. Cada capa con un enfoque distinto, de acuerdo con el propósito técnico (generalmente al menos: acceso a datos, lógica de negocios e interfaz de usuario). Esto demostró ser bastante efectivo. Ver figura 1.

Figura 1. Arquitectura en capas

Estas capas son internas al “nodo” de la aplicación. Estas capas están definidas por los paquetes y módulos internos, y aplicadas por las convenciones de las API dentro de la aplicación.

Estas API se pueden describir como API internas o locales. Son responsables de la estructura interna de alto nivel de cualquier aplicación. Las aplicaciones tradicionales se basan en estas API locales para mayor claridad y organización. Esta idea nacio a medida que aumentaba la disponibilidad y la facilidad de implementación de API remotas. Otro nombre para API remota, como vimos anteriormente, es servicio.

En lugar de dividir el diseño de la aplicación en capas, el microservicio agrupa las partes de la aplicación en nodos de elementos relacionados lógicamente según las necesidades de la aplicacion. Además, y de manera crucial, implementa cada uno de estos nodos por separado y los hace hablar a través de la red.

Evolucionando las aplicaciones monoliticas

Ahora hagamos una pausa por un momento y consideremos una pregunta esencial: ¿por qué dividimos el software en partes (incluidos los microservicios)?

Figura 2. Microservicio basico

Hay muchas respuestas para esta pregunta, pero se reducen a estas dos cosas: hacer que sea facil de utilizar para las personas y hacer que sea eficiente para que funcione correctamente en las computadoras.

Entonces, podemos decir que al separar la aplicación en partes, lo hacemos para que sea más fácil de administrar para los humanos y más eficiente para las máquinas .

Una aplicación de ejemplo

Hagamos las cosas más concretas ahora y consideremos un ejemplo. Revisemos el ejemplo de una aplicación de correo web. ¿Cómo se vería el diseño "monolítico" en capas de esta aplicación? El diseño de la aplicación en capas se ve así (Fig.3):

Figura 3. Detalle arquitectura en capas

Ahora, lo que nos dice la figura 3 es que la persistencia de datos y los elementos de la interfaz de usuario están realmente separados de la aplicación principal, y que la aplicación principal tiene capas para lidiar con la interacción con estos elementos, junto con la capa para hacer su lógica de negocio.

Divisiones de lógica de negocio

Ahora llevemos esto un paso más allá y agreguemos algunos detalles sobre los procesos de negocio reales que están sucediendo en la aplicación (Fig. 4):

Figura 4. Arquitectura en capas con áreas de negocio

El desacoplamiento de lógica de negocios

Por “áreas de negocio”, simplemente nos referimos a diferentes áreas de interés. Por ejemplo, en la aplicación web de correo electrónico, es posible que tenga, al menos: autenticación / autorización, envío de correo, recepción de correo y reenvío de correo (Fig.5):

Figura 5. Detalle aplicación web de correo electrónico

Ahora, lo que los microservicios le sugieren que haga es lo siguiente, como se ve en la Figura 6.

Figura 6. Microservicio aplicación web de correo electrónico

Tenga en cuenta que se trata de una simplificación generalizada, pero confío en que entienda la idea. En lugar de que cada área de negocio se integre en el mismo nodo de la aplicación, se desglosan en unidades implementadas de forma independiente, comunicándose a través de la red. Algo importante a tener en cuenta es que el diseño en capas de los propios nodos permanece. No abandonamos los principios organizativos que hacen que los nodos sean manejables.

Las capas siguen ahí

Es posible que algunos microservicios no requieran las mismas capas (por ejemplo: un servicio podría no exponer una API consumida por la interfaz de usuario). Podemos generalizar las capas de un servicio (micro o de otro tipo) en tres propósitos:

• Proporcionar API
• Lógica de negocio
• Consumir API

Estas capas existirán para todos los servicios, excepto los más simples, como los servicios que no consumen otros servicios para su trabajo. Después de conocer un poco sobre la arquitectura de microservicios, volvamos a la pregunta fundamental: ¿por qué?

Ventajas y desventajas de los microservicios

Es evidente que la arquitectura de microservicios implica una infraestructura adicional comparada con una arquitectura monolitica. Como mínimo, los servicios deben tener máquinas dedicadas para que se ejecuten y la red entre ellas. El objetivo es que cada servicio se pueda mantener y lanzar de forma independiente.

Recordando los dos propósitos: efectividad humana y computacional, podemos decir que los microservicios ofrecen beneficios a ambos. En el primer caso, los componentes fuertemente desacoplados se prestan bien a los equipos de desarrollo que los poseen y facilitan la comprensión de los servicios. Podemos concentrarnos en hacer el trabajo del servicio y exponer su API, sin tender a preocuparnos por los otras partes del sistema. Sin embargo, esto puede convertirse en una espada de dos filos, cuando tenemos que considerar agregar funcionalidades relacionadas en múltiples servicios o refactorizar recursos compartidos.

Desde el punto de vista conceptual, organizativo y de procesos, los microservicios pueden generar beneficios para los equipos de desarrollo. Además, existen posibilidades de rendimiento. Servicios más pequeños significa que los ajustes de rendimiento se pueden ajustar con mayor precisión. Es decir, podemos mejorar el rendimiento de elementos más pequeños de la aplicación que lo necesiten, en lugar de replicar toda la aplicacion cuando solo una pequeña parte está sometida a una gran carga.

¿Cuándo deberíamos utilizar microservicios?

En primer lugar los microservicios son una idea convincente, en su forma idealizada. Desciende directamente de la idea de SOA (Arquitectura Orientada a Servicios). Los problemas que enfrentan los microservicios y SOA pueden llegar a ser muy grandes, puesto que, implementar servicios y administrarlos introduce complejidad y gastos generales.

Todo esto ha impulsado la adopción e introducción de herramientas como Docker y Kubernates. En mi opinion los microservicios realmente necesitan una organización más grande para llevarse a cabo con éxito, y un entorno operativo bastante intenso para que tenga sentido implementarlos. Por último, quiero decir: muchas aplicaciones funcionarán bien con una arquitectura monolitica, deberian haber razones convincentes de rendimiento u organización para utilizar microservicios.

Inevitablemente, aislar los servicios a través de la red obligará a alguien o una parte del tiempo de alguien a lidiar con este trabajo.