Patrones de diseño para aplicaciones nativas en la nube

Capítulo 1. Introducción a la Nube Nativa Introducción a la Nube Nativa

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

El panorama del desarrollo de software cambia y evoluciona constantemente mediante paradigmas y tecnologías arquitectónicas modernas. De vez en cuando, la arquitectura del software experimenta un cambio fundamental con la aparición de tecnologías y enfoques revolucionarios. Uno de esos avances es la arquitectura nativa de la nube. Se trata de un cambio tan importante en el contexto del desarrollo de aplicaciones de software, que cambia la forma en que construimos, distribuimos y gestionamos las aplicaciones de software. La arquitectura nativa de la nube se ha convertido en un facilitador de agilidad, velocidad, seguridad y adaptabilidad para las aplicaciones de software.

Este capítulo te ayuda a entender qué es la nube nativa explorando las características clave de las aplicaciones nativas de la nube. También presentaremos una metodología de desarrollo que puedes utilizar durante todo el ciclo de vida de las aplicaciones nativas de la nube. Luego nos centraremos en la importancia de utilizar patrones de diseño para desarrollar aplicaciones nativas de la nube. Comencemos nuestro debate definiendo la nube nativa.

¿Qué es la nube nativa?

Entonces, ¿cuál es la definición formal de nube nativa? La triste noticia es que no existe tal definición. Nube nativa significa cosas diferentes para personas diferentes. La definición general más cercana es la de la Cloud Native Computing Foundation (CNCF), una organización dedicada a crear ecosistemas sostenibles y fomentar comunidades que apoyen el crecimiento y la salud de las aplicaciones nativas de la nube de código abierto. La CNCF sirve de sede neutral para muchos de los proyectos de código abierto de más rápido crecimiento que pueden utilizarse para crear aplicaciones nativas de la nube.

Definición de Nube Nativa del CNCF

Las tecnologías nativas de la nube permiten a las organizaciones crear y ejecutar aplicaciones escalables en entornos modernos y dinámicos, como nubes públicas, privadas e híbridas. Los contenedores, las mallas de servicios, los microservicios, la infraestructura inmutable y las API declarativas ejemplifican este enfoque. Estas técnicas permiten sistemas poco acoplados que son resistentes, gestionables y observables. Combinadas con una automatización robusta, permiten a los ingenieros realizar cambios de gran impacto de forma frecuente y predecible con un esfuerzo mínimo.

A efectos de este libro, adoptamos un enfoque ascendente para definir la nube nativa. Examinamos todas las características de las aplicaciones nativas de la nube, en todos los ámbitos, pasando por cada etapa del ciclo de vida de una aplicación nativa de la nube, incluidos el diseño, el desarrollo, el empaquetado, la implementación y la gobernanza. Basándonos en esas características, hemos llegado a la siguiente definición:

La nube nativa es la construcción de aplicaciones de software como una colección de servicios independientes, débilmente acoplados y orientados a la capacidad empresarial (microservicios) que pueden ejecutarse en entornos dinámicos (públicos, privados, híbridos, multicloud) de forma automatizada, escalable, resistente, gestionable y observable.

Explorar más a fondo estas características nos ayuda a comprender las aplicaciones nativas de la nube. Veamos más detenidamente las características en nuestra definición.

Diseñado como una colección de microservicios

Una aplicación nativa de la nube se diseña como una colección de servicios independientes y débilmente acoplados que sirven a una capacidad empresarial bien definida. Se conocen como microservicios. Los microservicios son el principio arquitectónico fundamental que resulta esencial para construir aplicaciones nativas de la nube. Es prácticamente imposible construir una aplicación nativa de la nube adecuada sin conocer los fundamentos de la arquitectura de microservicios .

Arquitectura de microservicios es un estilo de construir aplicaciones de software. Antes de la llegada de la arquitectura de microservicios, solíamos construir aplicaciones de software como aplicaciones monolíticas que respondían a diversos escenarios empresariales complejos. Estas aplicaciones monolíticas son intrínsecamente complejas, difíciles de escalar, caras de mantener y dificultan la agilidad de los equipos de desarrollo. Las aplicaciones monolíticas se comunican entre sí mediante protocolos de comunicación propietarios y a menudo comparten una única base de datos.

Consejo

La arquitectura de microservicios consiste en construir una aplicación de software como una colección de servicios independientes, autónomos (desarrollados, implementados y escalados independientemente), orientados a la capacidad empresarial y débilmente acoplados.¹

Arquitectura orientada a servicios(SOA) surgió como un estilo arquitectónico mejor para abordar las limitaciones de la arquitectura de aplicaciones monolíticas. La SOA se basa en el concepto de modularidad y en construir una aplicación de software como una colección de servicios para servir a una capacidad empresarial específica. Las realizaciones de SOA, como los servicios web, se implementaron utilizando normas y formatos de mensajes complejos, e introdujeron componentes monolíticos centralizados en la arquitectura.

En un diseño típico basado en SOA, las aplicaciones de software se construyen utilizando un conjunto de servicios de grano grueso, como los servicios web, que a menudo aprovechan estándares abiertos y una capa de integración monolítica central conocida como el bus de servicios empresariales(ESB). Se puede utilizar una capa de gestión de API sobre esta arquitectura para que puedas exponer las capacidades como API gestionadas.

La Figura 1-1 muestra una sencilla aplicación minorista online diseñada mediante SOA. Todas las capacidades empresariales se crean en la capa de servicios como servicios de grano grueso que se ejecutan en un servidor de aplicaciones monolítico en tiempo de ejecución. Esos servicios y el resto de los sistemas se integran mediante un ESB. A continuación, se coloca una pasarela API como puerta de entrada a la implementación SOA, desde donde se controlan y gestionan las capacidades empresariales .

Este enfoque ha funcionado para muchas empresas, y muchas aplicaciones de software empresarial se siguen construyendo utilizando SOA. Sin embargo, sus complejidades y limitaciones inherentes dificultan la agilidad del desarrollo de aplicaciones de software. La mayoría de las implementaciones de SOA dan lugar a una falta de aplicaciones escalables de forma independiente, dependencias entre aplicaciones que dificultan el desarrollo y la implementación de aplicaciones independientes, problemas de fiabilidad por ser una aplicación centralizada, y limitaciones en el uso de diversas tecnologías para la aplicación.

La arquitectura de microservicios, por otra parte, elimina las limitaciones de las implementaciones SOA introduciendo servicios de grano más fino y orientados al negocio, al tiempo que elimina componentes centralizados como el ESB. En la arquitectura de microservicios, una aplicación de software se diseña como una colección de servicios autónomos y orientados al negocio que son desarrollados, implementados y, a menudo, gestionados de forma independiente por diferentes equipos. La granularidad del servicio viene determinada por la aplicación de conceptos como el contexto acotado en el paradigma del Diseño Dirigido.²

Figura 1-1. Un escenario de aplicación minorista en línea construido mediante una SOA/ESB con gestión de API

Podemos transformar nuestra anterior aplicación minorista online basada en SOA/ESB en microservicios, como se muestra en la Figura 1-2. La idea principal aquí es introducir microservicios para cada capacidad de negocio que identifiquemos durante la fase de diseño, ya que aplicamos los conceptos del diseño orientado al dominio (explicados más adelante en este capítulo) y eliminamos la integración centralizada en la capa ESB.

Nota

Las técnicas de transformación de monolítico a microservicio se tratan en detalle en Building Microservices, de Sam Newman (O'Reilly).

Figura 1-2. Una aplicación de venta online construida con arquitectura de microservicios

En lugar de utilizar una capa ESB para integrar los servicios, los propios microservicios crean las composiciones mediante la comunicación ligera interservicios necesaria para construir la capacidad empresarial que ofrece el microservicio. Por lo tanto, estos microservicios se denominan extremos inteligentes que se conectan a través de dumb pipes, que se refiere a las técnicas de comunicación ligera interservicios.³ Los microservicios pueden conectarse a otros sistemas existentes y, en algunos casos, pueden exponer una interfaz simplificada (a menudo conocida como fachada) también para esos sistemas.

Los microservicios no comparten bases de datos, y las partes externas sólo pueden acceder a los datos a través de la interfaz del servicio. Cada microservicio debe implementar la lógica empresarial, así como las características de comunicación entre servicios, que incluyen resistencia, seguridad, etc.

Como las aplicaciones nativas de la nube se diseñan como una colección de microservicios, casi todos los conceptos que se aplican en los microservicios se relacionan también con el contexto nativo de la nube. Por lo tanto, tratamos la mayoría de los patrones y fundamentos de la arquitectura de microservicios a lo largo del libro .

Utilizar la contenedorización y la orquestación de contenedores

Al igual que los microservicios son importantes en la fase de diseño y desarrollo de aplicaciones nativas de la nube, los contenedores son importantes en el empaquetado y ejecución de aplicaciones nativas de la nube. Al desarrollar aplicaciones nativas de la nube, los microservicios que construimos se empaquetan en imágenes de contenedor y se ejecutan sobre un host de contenedor. Profundicemos para entender lo que esto significa realmente.

¿Qué son los contenedores?

Un contenedor es un proceso en ejecución que está aislado del sistema operativo anfitrión y de otros procesos del sistema. Un contenedor interactúa con su propio sistema de archivos privado, que proporciona una imagen de contenedor. La imagen del contenedor es un binario que se forma empaquetando todo lo necesario para ejecutar una aplicación: el código de la aplicación, sus dependencias y el tiempo de ejecución. Estas imágenes de contenedor son inmutables y suelen almacenarse en un repositorio conocido como registro de contenedores.

Para ejecutar un contenedor, puedes crear un proceso en ejecución a partir de la imagen del contenedor, que se conoce como instancia de contenedor. La instancia de contenedor se ejecuta sobre el motor de ejecución del contenedor.

La Figura 1-3 compara la ejecución de tres tiempos de ejecución de microservicios en máquinas virtuales (VMs) frente a un motor de ejecución de contenedores. Ejecutar microservicios como contenedores es drásticamente diferente de la ejecución convencional de una VM, que ejecuta un sistema operativo invitado completo con acceso virtual a los recursos del host a través de un componente conocido como hipervisor. Dado que los contenedores se ejecutan sobre un tiempo de ejecución de contenedor, comparten el núcleo de la máquina anfitriona, el procesador y la memoria con otros contenedores. Por lo tanto, ejecutar microservicios en contenedores es un proceso ligero y discreto en comparación con ejecutarlos sobre una máquina virtual. Por ejemplo, una aplicación que se ejecuta en una VM y tarda varios minutos en cargarse, puede tardar sólo unos segundos en cargarse en contenedores.

El proceso de convertir microservicios o aplicaciones para que se ejecuten sobre contenedores se conoce como contenerización. Docker se ha convertido en la plataforma de facto para construir, ejecutar y compartir aplicaciones en contenedores.

La contenerización hace que tus microservicios sean portátiles y garantiza la coherencia de la ejecución en múltiples entornos. Los contenedores son una fuerza impulsora clave para hacer que los microservicios sean independientes y autónomos, ya que son autosuficientes y están encapsulados, lo que te permite sustituir o actualizar uno sin interrumpir los demás, al tiempo que utilizan mejor los recursos que las máquinas virtuales. También eliminan la preconfiguración adicional en tiempo de ejecución, y son mucho más ligeros en comparación con las máquinas virtuales.

Figura 1-3. Comparación de la ejecución de aplicaciones en máquinas virtuales frente a contenedores

La contenedorización de tus microservicios y su ejecución aprovechando un motor de contenedores es sólo una parte del ciclo de vida de desarrollo de tu aplicación nativa en la nube. Pero, ¿cómo gestionas la ejecución de tus contenedores y el ciclo de vida de los mismos? Ahí es donde entra en escena la orquestación de contenedores.

¿Por qué orquestación de contenedores?

La orquestación de contenedores es el proceso de gestión del ciclo de vida de los contenedores. Cuando operas aplicaciones nativas de la nube en el mundo real, es casi imposible gestionar manualmente los contenedores. De ahí que un sistema de orquestación de contenedores sea una parte esencial de la construcción de una arquitectura nativa de la nube.

Veamos de cerca algunas de las características y capacidades clave de un sistema de orquestación de contenedores:

Aprovisionamiento automático

Aprovisiona automáticamente instancias de contenedores e implementación de contenedores

Alta disponibilidad

Reprograma automáticamente los contenedores cuando falla el tiempo de ejecución de uno de ellos

Escalado

En función de la demanda, añade o elimina automáticamente instancias de contenedor para ampliar o reducir la aplicación

Gestión de recursos

Asigna recursos entre los contenedores

Interfaces de servicio y equilibrio de carga

Expone los contenedores a sistemas externos y gestiona la carga que llega a los contenedores

Abstracciones de la infraestructura de red

Proporciona una superposición de red para crear comunicación entre contenedores

Descubrimiento de servicios

Ofrece la capacidad integrada de descubrir servicios con un nombre de servicio

Plano de control

Proporciona un único lugar para gestionar y monitorear un sistema en contenedores

Afinidad

Contenedores de provisiones cercanos o alejados unos de otros, ayudando a la disponibilidad y el rendimiento

Monitoreo de la salud

Detecta automáticamente los fallos y proporciona autocuración

Mejoras por rodadura

Coordina actualizaciones incrementales sin tiempo de inactividad

Componenciación y aislamiento

Introduce la separación lógica entre varios dominios de aplicación utilizando conceptos como los espacios de nombres

En el panorama de la nube nativa, Kubernetes se ha convertido en el sistema de orquestación de contenedores de facto.

Kubernetes

Kubernetes crea una capa de abstracción sobre los contenedores para simplificar la orquestación de los mismos, automatizando la implementación, el escalado, la tolerancia a fallos, la conexión en red y otros requisitos de gestión de los contenedores de los que hemos hablado antes.

Dado que Kubernetes se adopta en múltiples plataformas y proveedores de nube, se está convirtiendo en la plataforma universal de gestión de contenedores. Todos los principales proveedores de nubes ofrecen Kubernetes como servicio gestionado.

Las aplicaciones diseñadas para ejecutarse en Kubernetes pueden implementarse en cualquier servicio en la nube o centro de datos local que admita Kubernetes, sin realizar ningún cambio en la aplicación (siempre que no utilices ninguna función específica de la plataforma, como equilibradores de carga). Kubernetes hace que las cargas de trabajo de las aplicaciones sean portátiles, más fáciles de escalar y más fáciles de ampliar. Ahora es la plataforma estandarizada para la que puedes diseñar tu aplicación, de modo que no esté acoplada a ninguna infraestructura subyacente. Kubernetes aporta abstracciones clave que ayudan a estandarizar las aplicaciones y simplifican la orquestación de contenedores(Figura 1-4).

Figura 1-4. Componentes fundamentales de una plataforma Kubernetes

Un clúster Kubernetes está formado por un conjunto de nodos que se ejecutan en máquinas virtuales o físicas. Entre estos nodos hay al menos un nodo del plano de control y varios nodos trabajadores. El nodo del plano de control es responsable de gestionar y programar las instancias de aplicación en todo el clúster. Por tanto, los servicios que ejecuta el nodo del plano de control de Kubernetes se conocen como plano de control de Kubernetes.

El servidor API de Kubernetes se encarga de toda la comunicación entre el plano de control y los nodos trabajadores. Cuando hay que asignar una determinada carga de trabajo a un nodo concreto, el kube-scheduler asigna cargas de trabajo a cada nodo trabajador en función de los recursos y políticas disponibles. Cada nodo Kubernetes ejecuta un proceso agente conocido como kubelet, que mantiene los estados de los nodos. Éste es el componente que se comunica directamente con el servidor API de Kubernetes, recibiendo instrucciones e informando de los estados de cada nodo.

Un pod es la unidad básica de implementación que representa un tiempo de ejecución de una aplicación que se ejecuta en un nodo determinado. Un pod puede tener uno o más contenedores ejecutándose en su interior. A un pod se le asigna una dirección IP única dentro del clúster Kubernetes.

Kubernetes simplifica aún más la implementación y gestión de aplicaciones introduciendo abstracciones como Service, Implementación y ReplicaSet. Un Servicio proporciona una agrupación lógica para un conjunto de pods como servicio de red, de modo que un servicio puede tener varios pods con equilibrio de carga. Un ReplicaSet define el número de réplicas que debe tener la aplicación. La Implementación gestiona cómo se despliegan los cambios en la aplicación.

Todos estos objetos de Kubernetes se especifican utilizando YAML o JavaScript Object Notation (JSON) y se aplican a través del plano de control de Kubernetes interactuando con el servidor API de Kubernetes. Puedes consultar la documentación oficial de Kubernetes para obtener más información sobre Kubernetes.

Funciones sin servidor

Un microservicio determinado de una aplicación nativa en la nube puede modelarse como una función sin servidor. Esta función programática sirve a la capacidad empresarial de un microservicio que se ejecuta en una infraestructura en la nube. Con las funciones sin servidor, la mayor parte de la gestión, las redes, la resiliencia, la escalabilidad y la seguridad ya las proporciona la plataforma sin servidor subyacente.

Las plataformas sin servidor, como AWS Lambda, Azure Functions y Google Cloud Functions, ofrecen escalado automático basado en la carga, compatibilidad con múltiples lenguajes de programación y funciones integradas relacionadas con la comunicación de resiliencia, la seguridad y la observabilidad. Los microservicios que necesitan soportar ráfagas de cargas, trabajos por lotes y servicios basados en eventos son adecuados para ser implementados utilizando funciones sin servidor.

Cuando utilizas una función sin servidor, puedes estar utilizando contenedores por debajo, pero eso es transparente para el desarrollador de microservicios. Puedes simplemente escribir una función con la lógica de negocio de tu microservicio y entregarla a la plataforma sin servidor para que la ejecute. Los detalles de cómo se ejecuta e implementa también están ocultos para el usuario.

Máquinas virtuales

Tú puedes optar por ejecutar tus microservicios sin utilizar contenedores. Aunque el uso de contenedores para crear aplicaciones nativas de la nube no es obligatorio, necesitas gestionar las complejidades y la sobrecarga de ejecutar aplicaciones sobre máquinas virtuales. Por esta razón, en la mayoría de las implementaciones del mundo real de la arquitectura nativa de la nube, a menudo vemos la adopción de contenedores, orquestaciones de contenedores o abstracciones de más alto nivel, como las funciones sin servidor .

Automatizar el ciclo de vida del desarrollo

Cuando se trata de la entrega de aplicaciones nativas de la nube, es importante ser ágil, rápido y seguro. Para conseguirlo, necesitamos agilizar todo el ciclo de vida del desarrollo de aplicaciones nativas de la nube y automatizar todos los pasos posibles.

La automatización en el contexto de las aplicaciones nativas de la nube consiste en automatizar las tareas manuales del ciclo de vida del desarrollo. Esto incluye tareas como la ejecución de pruebas de integración, compilaciones, lanzamientos, gestión de la configuración, gestión de la infraestructura e integración continua (CI) y entrega/implantación continua (CD).

En el ciclo de vida de desarrollo que se muestra en la Figura 1-5, puedes ver todas las etapas de la creación de una aplicación nativa de la nube.

Figura 1-5. Ciclo de vida del desarrollo de aplicaciones nativas en la nube

El ciclo de vida del desarrollo comienza cuando los desarrolladores desarrollan su código, y luego ejecutan, depuran y empujan sus cambios a un repositorio central de control de código fuente, como Git. Cuando se empuja el código, se activa automáticamente el proceso de integración continua. Aquí es donde se construye el código, se ejecutan las pruebas y la aplicación se empaqueta en un binario. Una herramienta de integración continua construye y ejecuta automáticamente pruebas unitarias sobre los nuevos cambios de código para sacar a la luz inmediatamente cualquier error.

Al desplegar artefactos en distintos entornos, entra en acción el proceso de implementación continua. Elige el artefacto binario construido y aplica una configuración específica del entorno mediante herramientas de gestión de la configuración, y despliega la versión en un entorno especificado. En esta fase, podemos ejecutar varias etapas de prueba en paralelo antes de pasar los cambios a una implementación de producción. El envío final al entorno de producción puede estar totalmente automatizado o implicar un paso de aprobación manual.

La diferencia entre la entrega continua y la implementación continua es que en la entrega continua es necesaria la aprobación manual para actualizar a producción. Con la implementación continua, la actualización a producción se produce automáticamente, sin aprobación explícita.

Para automatizar la creación del entorno de destino (dev, staging o producción), se suele utilizar la técnica de infraestructura como código(IaC). Con el modelo IaC, la gestión de la infraestructura (redes, máquinas virtuales, equilibradores de carga y topología de conexión) se realiza mediante un modelo declarativo similar al código fuente de una aplicación. Con este modelo, podemos crear continuamente el entorno necesario utilizando el descriptor sin ninguna intervención manual. Esto mejora la velocidad y la eficacia del proceso de desarrollo, manteniendo la coherencia y reduciendo la sobrecarga de gestión. Por lo tanto, las técnicas de IaC son parte integrante del pipeline de entrega continua.

Una vez que definimos el estado diseñado de la implementación, plataformas como Kubernetes pueden encargarse de mantener ese estado de implementación con el uso de bucles de conciliación. La idea clave es mantener el estado de implementación sin intervención del usuario. Por ejemplo, si especificamos que una aplicación determinada debe ejecutar tres réplicas en un momento dado, la reconciliación de Kubernetes se asegura de que tres aplicaciones se estén ejecutando todo el tiempo.

Gestión dinámica

Cuando las aplicaciones nativas de la nube se implementan en un entorno de producción, necesitamos gestionar y observar el comportamiento de la aplicación. Éstas son algunas de las capacidades clave necesarias para gestionar dinámicamente las aplicaciones nativas de la nube:

Autoescalado

Amplía o reduce las instancias de la aplicación en función del tráfico o la carga

Alta disponibilidad

En caso de fallo, proporciona la capacidad de generar nuevas instancias en el centro de datos actual o desplazar el tráfico a centros de datos diferentes

Optimización de recursos

Garantiza un uso óptimo de los recursos, con escalado dinámico y sin costes iniciales, pero con respuesta automatizada en tiempo real a las necesidades de escalado

Observabilidad

Permite registros, métricas y seguimiento de la aplicación nativa de la nube con control centralizado

Calidad de servicio (QoS)

Permite la seguridad de extremo a extremo, la regulación, el cumplimiento y el control de versiones en todas las aplicaciones.

Plano de control central

Proporciona un lugar central para gestionar cada aspecto de la aplicación nativa de la nube

Provisión de recursos

Gestiona la asignación de recursos (CPU, memoria, almacenamiento, red) para cada aplicación

Soporte multicloud

Proporciona la capacidad de gestionar y ejecutar la aplicación en varios entornos de nube, incluidas las nubes privadas, híbridas y públicas (ya que una aplicación determinada puede requerir componentes y servicios de varios proveedores de nubes).

La mayoría de las capacidades de gestión dinámica se ofrecen como parte de servicios populares en la nube, como Amazon Web Services (AWS), Microsoft Azure y Google Cloud Platform (GCP). Los contenedores y los sistemas de orquestación de contenedores, como Kubernetes, desempeñan un papel importante en la democratización de tus aplicaciones en estas plataformas en la nube, de modo que tus aplicaciones no estén vinculadas a un proveedor específico.

Metodología para crear aplicaciones nativas en la nube

Construir aplicaciones nativas de la nube requiere que sigas una nueva metodología de desarrollo, diferente del enfoque convencional que muchos de nosotros hemos practicado. Algunas personas creen que la forma de construir aplicaciones nativas de la nube es utilizar la metodología de las Apps de Doce Factores. Sin embargo, hemos descubierto que esta metodología tiene varias lagunas; no cubre todos los aspectos del ciclo de vida del desarrollo de aplicaciones nativas de la nube.

Por lo tanto, hemos ideado una metodología más completa y pragmática para crear aplicaciones nativas en la nube. Dividimos este enfoque en fases y reutilizamos algunas de las metodologías existentes siempre que es necesario. La Figura 1-6 ilustra las fases clave de nuestra metodología para construir aplicaciones nativas de la nube.

Figura 1-6. Metodología para crear aplicaciones nativas en la nube

Profundicemos en los detalles de cada fase.

Diseñar la aplicación

Cuando está construyendo una aplicación nativa de la nube que comprende microservicios, no puedes lanzarte de inmediato al desarrollo de la aplicación. Tienes que diseñar la aplicación en torno a las capacidades empresariales que quieres atender. Esto requiere que identifiques claramente las capacidades empresariales que la aplicación tiene que ofrecer, así como las dependencias externas (servicios o sistemas) que la aplicación necesita consumir.

Por tanto, en la fase de diseño, debes examinar más detenidamente el caso de uso empresarial e identificar los microservicios que quieres construir. El diseño de una aplicación nativa en la nube puede utilizar la metodología de diseño impulsado por el dominio (DDD), que construye abstracciones sobre la compleja lógica de negocio y las representa en los componentes de software .⁴

El proceso DDD comienza con el análisis del dominio empresarial (por ejemplo, comercio o sanidad) y la definición de los límites dentro de ese dominio en los que se aplica un modelo de dominio concreto. Se conocen como contextos delimitados. Por ejemplo, una organización puede tener contextos delimitados como ventas, recursos humanos (RRHH), soporte, etc. Cada contexto delimitado puede dividirse a su vez en agregados, agrupaciones de objetos de dominio que pueden tratarse como una sola unidad.

Estos contextos delimitados pueden o no asignarse directamente a un microservicio. Cuando diseñamos una aplicación nativa de la nube, normalmente podemos empezar con un servicio para cada contexto delimitado y dividirlo en servicios más pequeños que se construyen en torno a agregados a medida que avanzamos. Una vez completado el DDD para la aplicación nativa de la nube, también puedes finalizar las interfaces/definiciones de los servicios y los estilos de comunicación mientras identificas los microservicios.

Desarrollar la aplicación

En la fase de desarrollo, construimos la aplicación basándonos en los casos de uso empresarial y las interfaces de servicio que hemos identificado en la fase de diseño. En esta sección, esbozamos los aspectos clave del proceso de desarrollo que permiten las aplicaciones nativas de la nube.

Código base independiente

Cada microservicio de una aplicación nativa en la nube debe tener una base de código rastreada en un sistema de control de versiones (como Git). Se ejecutarán varias instancias del servicio, conocidas como implementaciones. Así que, como muestra la Figura 1-7, puedes implementar el servicio en distintos entornos, como desarrollo, montaje y producción, todos ellos con la misma base de código (pero pueden utilizar versiones distintas de la base de código).

Tener una base de código independiente significa que el ciclo de vida del microservicio puede ser completamente independiente del resto del sistema. Y puedes importar explícitamente dependencias externas, como bibliotecas.

Figura 1-7. Una única base de código con múltiples implementaciones en distintos entornos

Dependencias explícitas

Todas las dependencias a nivel de código de un microservicio deben declararse explícitamente y aislarse unas de otras. Las dependencias deben declararse en un manifiesto que forme parte del código del microservicio, y el servicio no debe depender de ninguna dependencia a nivel de sistema que no se declare explícitamente.

Configuraciones desacopladas

Como hemos comentado antes en, las aplicaciones nativas de la nube contienen una única base de código de un servicio que se implementa en varios entornos. Esto sólo es posible si la configuración del microservicio está totalmente desacoplada del código del microservicio. El código base de un servicio es agnóstico del entorno, y la configuración varía entre las distintas Implementaciones.

Pruebas independientes

Un microservicio debe tener pruebas autónomas que verifiquen independientemente su funcionalidad. Normalmente, estas pruebas son parte integrante del ciclo de desarrollo del microservicio, y la verificación del microservicio se produce durante las etapas de construcción e implementación. Podemos considerar estas pruebas unitarias ya que están localizadas en el ámbito de un microservicio determinado.

Sin embargo, como una aplicación nativa de la nube contiene varios microservicios que funcionan juntos para servir a un determinado caso de uso empresarial, las pruebas unitarias por sí solas no pueden probar la funcionalidad global de la aplicación. También necesitamos pruebas de todo el sistema, conocidas como pruebas de integración. Estas pruebas reúnen microservicios y otros sistemas y los prueban como una sola unidad para verificar que colaboran como se pretende, para lograr la capacidad empresarial más amplia. Puedes encontrar más detalles sobre las pruebas de microservicios en "Testing Strategies in a Microservice Architecture", de Toby Clemson.

Contenedorización

La mayoría de los conceptos que hemos tratado en los pasos anteriores pueden demostrarse mediante la contenedorización de los microservicios que construyas. Aunque la contenedorización no es obligatoria para construir aplicaciones nativas de la nube, es bastante útil para implementar la mayoría de sus características y requisitos.

Encapsular una aplicación nativa de la nube en un único paquete con todas las dependencias, tiempos de ejecución y configuraciones es posible gracias a la contenerización. La contenerización (mediante tecnologías como Docker) hace que los microservicios sean inmutables, lo que significa que pueden iniciarse o detenerse en un momento dado y descartar cualquier instancia defectuosa en lugar de arreglarla o actualizarla. Esto requiere que los microservicios que contenemos tengan un tiempo de arranque rápido y tiempos de apagado elegantes. Por tanto, la contenedorización funciona mejor cuando aprovechas los marcos y tecnologías nativos de los contenedores. (Si no se puede conseguir un tiempo de arranque rápido debido a una limitación inherente a las aplicaciones que contenedorizamos, los sistemas de orquestación de contenedores como Kubernetes proporcionan comprobaciones de disponibilidad y liveness para garantizar que las aplicaciones están listas para servir a sus consumidores).

Al desarrollar microservicios, a menudo se requiere conectar con otros microservicios y/o exponer capacidades empresariales a consumidores externos como API. Atendemos a estos requisitos en la siguiente fase, al establecer la conectividad.

Conectividad, composiciones y API

Como comentamos al principio de este capítulo, las aplicaciones nativas de la nube son aplicaciones distribuidas que están conectadas mediante comunicación de red. Al diseñarlas como una colección de microservicios, a menudo necesitamos que haya interacciones entre esos servicios y sistemas externos. Por tanto, tener conectividad entre los servicios y definir adecuadamente las API y las interfaces de servicio es fundamental.

Interacciones dirigidas por el servicio

Todos los microservicios y aplicaciones deben exponer sus capacidades como un servicio. Del mismo modo, cualquier capacidad y recurso externo que consuma un microservicio también debe declararse como servicio (a menudo conocido como servicio de respaldo).

La noción de servicio es una abstracción que ayuda de muchas maneras a la interacción entre microservicios. Un servicio es un habilitador para el descubrimiento dinámico de servicios, que mantiene un repositorio/registro de metadatos de servicios. También te permite implementar conceptos como el equilibrio de carga. Por eso la abstracción de servicio está integrada en plataformas de orquestación de contenedores como Kubernetes como una abstracción de primera clase. Por tanto, cuando construyes una aplicación nativa de la nube con un conjunto de microservicios, sus capacidades pueden declararse como servicios (por ejemplo, un servicio de Kubernetes). Cualquier aplicación/servicio o recurso externo (como una base de datos o un corredor de mensajes) que consumamos también debe declararse como un servicio que podemos consumir a través de la red.

Comunicación interservicios y composiciones

La interacción entre servicios y otros sistemas es una parte clave del desarrollo de aplicaciones nativas de la nube. Estas interacciones se producen a través de la red, utilizando diversos patrones y protocolos de comunicación. Estas interacciones pueden implicar consumir varios servicios, crear composiciones, crear consumidores o productores basados en eventos, etc. También tenemos que construir ciertas características -como la seguridad a nivel de aplicación, la comunicación resistente (disyuntores, lógica de reintento con backoff y tiempos de espera), el enrutamiento, la publicación de métricas y las trazas a herramientas de observabilidad- como parte de la lógica de comunicación entre servicios, aunque en realidad no formen parte de la lógica empresarial. (Tratamos en detalle la comunicación interservicios y la composición en los capítulos 2, 3 y 5).

Por lo tanto, como desarrollador de servicios, necesitas disponer de las capacidades necesarias en la pila tecnológica que utilizas para construir los servicios. Algunas de las características básicas que no están directamente relacionadas con la lógica empresarial de los servicios (por ejemplo, la comunicación resistente) pueden implementarse fuera de la capa de aplicación (a menudo utilizando las plataformas de tiempo de ejecución subyacentes, como el proveedor de la nube que ejecuta nuestras aplicaciones). Trataremos todos estos patrones en detalle en los próximos capítulos.

Exponer capacidades como API gestionadas

Para ciertas capacidades de, la noción de servicio puede extenderse aún más al concepto de API gestionada. Dado que la mayoría de las capacidades empresariales de una aplicación nativa de la nube pueden exponerse a partes externas e internas, queremos que sea un servicio/API gestionado. Esto significa que puedes utilizar una pasarela de API y un plano de gestión (plano de gestión/control de API) para implementar capacidades (de las API que expones a los consumidores), como seguridad, estrangulamiento, almacenamiento en caché, versionado, monetización (crear ingresos a partir de las API expuestas), habilitar un portal para desarrolladores, etc.

La pasarela API actúa como puerta de entrada a tus capacidades, y un portal para desarrolladores puede alimentar un ecosistema en torno a tus API. La gestión de API debe hacerse tanto para el consumo externo como interno de tus servicios. Sin embargo, la gestión de API no está integrada en plataformas de orquestación de contenedores como Kubernetes. Por tanto, necesitas utilizar explícitamente tecnologías de gestión de API para exponer tus microservicios como API gestionadas.

Automatización del desarrollo, lanzamiento e implementación

Como hemos señalado anteriormente en este capítulo, automatizar tantos pasos como sea posible en el proceso de desarrollo, lanzamiento y entrega es una parte vital de la creación de aplicaciones nativas de la nube Las diversas etapas de la creación de aplicaciones nativas de la nube (como las pruebas, el empuje de código, la compilación, las pruebas de integración, el lanzamiento, la implementación y la ejecución) deben automatizarse mediante el uso de técnicas y marcos de integración continua, implementación continua, IaC y entrega continua.

Nota

Entrega continua de Jez Humble y David Farley (Addison-Wesley Professional) es una gran referencia sobre cómo implantar una estrategia de entrega continua para tus aplicaciones de software.

Funcionamiento en un entorno dinámico

En la fase de ejecución, o ejecución, de tu aplicación nativa de la nube, puedes configurar las aplicaciones para que se desplieguen y ejecuten en un entorno de ejecución como parte de la fase anterior. La idea clave aquí es garantizar que tu aplicación sea independiente del entorno de ejecución y que pueda ejecutarse en varios entornos de ejecución (dev, staging, producción, etc.) sin ningún cambio en el código de la aplicación. Dado que utilizas contenedores como modelo de entrega, el entorno de ejecución suele contener un sistema de orquestación de contenedores. El entorno de ejecución puede ser un entorno local, una nube pública, híbrida o privada, o incluso varios entornos de nube.

Dado que Kubernetes es la opción más popular para la orquestación de contenedores, podemos utilizarlo como abstracción de tiempo de ejecución universal para implementar nuestras aplicaciones, de modo que su comportamiento sea similar en todos los entornos de ejecución y escenarios multicloud. La naturaleza dinámica del entorno -incluido el aprovisionamiento de contenedores, la gestión de recursos, la inmutabilidad y el autoescalado- puede descargarse completamente en Kubernetes. Además, como la plataforma de orquestación de contenedores proporciona la mayoría de las funciones relacionadas con la ejecución dinámica, la aplicación sólo tiene que preocuparse de las capacidades que están dentro de su alcance (por ejemplo, escalado, requisitos de concurrencia de un único tiempo de ejecución).

Las plataformas de orquestación, como Kubernetes, ejecutan por defecto tu aplicación como un proceso sin estado (el estado de la aplicación no se mantiene ni persiste). Sin embargo, si la aplicación requiere estado, tienes que utilizar explícitamente un almacén de estado externo para mantener el estado de la aplicación fuera de tu aplicación (como en un almacén de datos), de modo que puedas desacoplar el estado de la aplicación del ciclo de vida del contenedor. Si planeas ejecutar aplicaciones nativas de la nube en un centro de datos local o en una nube privada, puedes seguir beneficiándote de Kubernetes, ya que se encarga de muchas de las complejidades de la orquestación de contenedores.

Plano de control para la gestión dinámica

En esta fase, utilizamos una capa central de gestión y administración conocida como plano de control que te permite controlar el comportamiento de los entornos dinámicos en los que se ejecutan tus aplicaciones. Este plano de control es el principal punto de interacción entre los DevOps y los desarrolladores que ejecutan su aplicación en un entorno de ejecución. Normalmente, estos planos de control de la nube constan de una interfaz web, así como de una API de transferencia de estado representacional (REST) o de llamada a procedimiento remoto (RPC). La mayoría de los proveedores de nubes ofrecen estos planos de control como parte de su oferta de servicios en la nube.

Observabilidad y monitoreo

Una vez que despliega y ejecuta sus aplicaciones, la siguiente fase de la creación de aplicaciones nativas de la nube consiste en observar su comportamiento en tiempo de ejecución. La observabilidad, en el contexto de una aplicación de software, se refiere a la capacidad de comprender y explicar el estado de un sistema sin desplegar ningún código nuevo. Esto es esencial para la resolución de problemas, el registro de transacciones empresariales, la identificación de anomalías, la identificación de patrones empresariales, la generación de perspectivas, etc.

En la fase de observabilidad y monitoreo, necesitas habilitar aspectos clave de observabilidad en tu aplicación nativa de la nube. Entre ellos están el registro, las métricas, el rastreo y la visualización del servicio. Hay herramientas creadas explícitamente para cada uno de estos aspectos, y la mayoría de los proveedores de la nube ofrecen estas capacidades listas para usar como servicios gestionados en la nube. Desde el nivel del código de la aplicación, puede que tengas que habilitar agentes o bibliotecas cliente sin cambiar el código de tu aplicación.

Con esto, hemos discutido todas las fases de la metodología para construir aplicaciones nativas de la nube.

Patrones de diseño para crear aplicaciones nativas de la nube

En las secciones anteriores de, hemos explorado todas las características clave de las aplicaciones nativas de la nube y la metodología para construirlas. Como has visto, la arquitectura nativa de la nube requiere un cambio significativo en la metodología, la tecnología y la arquitectura para construir aplicaciones de software.

No podemos ceñirnos simplemente al patrón de diseño convencional para construir aplicaciones de software. Algunos patrones se están quedando obsoletos, otros requieren ciertos cambios o retoques, y están surgiendo nuevos patrones para satisfacer las necesidades específicas de la arquitectura nativa de la nube. Estos patrones pueden aplicarse en distintas fases del ciclo de vida de desarrollo de una aplicación nativa de la nube. Aunque el sector tiende a centrarse en la implementación y entrega de aplicaciones nativas de la nube, a menudo se ha pasado por alto la complejidad de construir la lógica empresarial, utilizar diversos patrones de comunicación y conectar las aplicaciones nativas de la nube.

En este libro, nos centramos en los patrones de diseño que puedes utilizar al construir aplicaciones nativas de la nube. Estos son los patrones que tienes que aplicar cuando construyas la lógica de negocio de las aplicaciones nativas de la nube, las conectes y permitas que las partes externas las consuman. Dependiendo de la naturaleza de la aplicación nativa de la nube y de los patrones que utilices para construirla, las capacidades transversales como la implementación, el escalado, la seguridad y la observabilidad también pueden implementarse de forma diferente. Discutiremos esas capacidades desde la perspectiva del desarrollo de aplicaciones nativas de la nube y nos sumergiremos en ellas cuando sea necesario.

En los capítulos siguientes, examinamos los patrones en el contexto de seis áreas clave: comunicación, conectividad y composición, gestión de datos, arquitectura basada en eventos, procesamiento de flujos y gestión y consumo de API. Resumamos brevemente cada una de ellas.

Patrones de comunicación

Como has aprendido, una aplicación nativa de la nube se compone de una colección de microservicios, distribuidos a través de una red. Los patrones de comunicación nativos de la nube tienen que ver con la forma en que estos servicios pueden comunicarse entre sí y con entidades externas.

Para construir incluso un caso de uso empresarial muy sencillo, tu aplicación necesita consumir servicios externos (que podrían ser otro servicio, una base de datos o un corredor de mensajes, por ejemplo). Por lo tanto, construir la interacción entre tu aplicación y estos servicios externos se está convirtiendo en una de las tareas más comunes y a la vez más complejas en la construcción de aplicaciones nativas de la nube.

La mayoría de los patrones y tecnologías de comunicación interservicios convencionales del mundo de la informática distribuida no son directamente aplicables en el contexto del desarrollo de aplicaciones nativas de la nube. Tenemos que seleccionar patrones de comunicación que se adapten bien a los atributos nativos de la nube de la aplicación (por ejemplo, patrones que permitan la autonomía y escalabilidad del servicio), así como al caso de uso empresarial (por ejemplo, algunos pueden requerir garantías de entrega, mientras que otros pueden necesitar respuestas en tiempo real).

La comunicación interservicios entre aplicaciones nativas de la nube se implementa utilizando patrones de comunicación síncrona o asíncrona. En la comunicación síncrona, utilizamos patrones como solicitud/respuesta y RPC. En la comunicación asíncrona, utilizamos patrones como la mensajería basada en colas y editor-suscriptor (pub-sub). En la mayoría de los casos de uso del mundo real, necesitas utilizar ambas categorías juntas para construir las interacciones del servicio. Las definiciones de interfaz de servicio y los contratos también desempeñan un papel vital cuando se trata de patrones de comunicación, ya que son la forma estándar de expresar cómo se puede consumir un servicio determinado.

Además de las interacciones entre servicios, algunas aplicaciones nativas de la nube pueden tener que comunicarse con partes externas, como clientes frontales o servicios de respaldo. Como desarrollador de aplicaciones, tienes que trabajar con muchas piezas móviles y muchas interacciones con servicios y sistemas externos.

En el Capítulo 2, tratamos en detalle todos estos patrones de comunicación, junto con las tecnologías y protocolos de implementación relacionados.

Patrones de conectividad y composición

Cuantos más microservicios tengas, más comunicación interservicios tendrá lugar. Por tanto, cuando diseñas aplicaciones nativas de la nube, necesitas aportar ciertas capacidades y abstracciones que reduzcan la complejidad de la comunicación interservicios. Ahí es donde entran en escena los patrones de conectividad y composición.

Conectividad

En el contexto de la comunicación entre servicios, la conectividad se refiere al establecimiento de un canal de comunicación fiable, seguro, detectable, gestionable y observable entre servicios. Por ejemplo, cuando un servicio determinado llama a otro, necesitas aplicar ciertos patrones de fiabilidad, como reintentar o establecer un canal de comunicación seguro. No forman parte de la lógica empresarial de la aplicación, pero son esenciales para crear una conectividad sólida.

En el Capítulo 3, tratamos varios patrones relacionados con la comunicación resistente, la seguridad, el descubrimiento de servicios, el encaminamiento del tráfico y la observabilidad en la comunicación interservicios. También exploraremos cómo facilitan estos requisitos las infraestructuras de conectividad interservicios, como la malla de servicios y la arquitectura sidecar.

Composiciones

Cuando se construyen aplicaciones nativas de la nube, es bastante habitual crear un servicio mediante la conexión, o integración, de uno o más servicios o sistemas. Esto se conoce como composiciones (también llamadas servicios compuestos y servicios de integración).

Como comentamos al principio del capítulo, los servicios y sistemas se construían a menudo utilizando SOA antes de la era nativa de la nube. En SOA, todos los servicios, datos y sistemas se integran utilizando un ESB-así que al crear composiciones, el ESB era la opción por defecto. En esta arquitectura se utilizaba una plétora de patrones de composición, que se conocían comúnmente como patrones de integración empresarial(EIP).

Sin embargo, en la era nativa de la nube, no utilizamos una capa de composición central. Todas esas tareas deben realizarse como parte de los servicios que desarrollamos. Por lo tanto, en el Capítulo 3, nos sumergimos en todos esos patrones de composición e identificamos cuáles debemos aplicar para construir aplicaciones nativas de la nube.

Patrones de gestión de datos

La mayoría de las aplicaciones nativas de la nube que desarrollas necesitan ocuparse de cierta gestión de datos. Tu aplicación suele estar respaldada por una base de datos que actúa como almacenamiento persistente para guardar el estado de la aplicación o los datos de negocio necesarios para construir el servicio. Como has aprendido anteriormente, las aplicaciones nativas de la nube son inherentemente distribuidas. Por lo tanto, la gestión de datos también se realiza de forma totalmente descentralizada.

En las aplicaciones monolíticas convencionales de, solíamos tener un almacén de datos central y compartido, con el que interactuaban muchas aplicaciones. Con las aplicaciones nativas en la nube, dejamos que un microservicio determinado sea dueño de su almacén de datos, y las partes externas sólo pueden interactuar con él a través de esa interfaz de servicio. Con este enfoque segregado de gestión de datos, acceder, compartir y sincronizar datos entre microservicios se convierte en un reto. Por eso, conocer los patrones de gestión de datos nativos de la nube es esencial para el desarrollo de aplicaciones nativas de la nube.

En el Capítulo 4, exploramos una amplia gama de patrones de gestión de datos nativos de la nube que abarcan la gestión descentralizada de datos, la composición de datos, el escalado de datos, las implementaciones de almacenes de datos, la gestión de transacciones y el almacenamiento en caché.

Patrones de Arquitectura Dirigida por Eventos

Cuando hablamos de los patrones de comunicación nativos de la nube en, hablamos de la mensajería asíncrona como técnica de comunicación entre servicios. Esa es la base de las aplicaciones nativas de la nube dirigidas por eventos. La arquitectura dirigida por eventos(EDA) se ha utilizado ampliamente en el desarrollo de aplicaciones durante décadas. En el contexto de las aplicaciones nativas de la nube, EDA desempeña un papel vital, ya que es una forma estupenda de habilitar microservicios autónomos. A diferencia de las técnicas de comunicación síncrona, como las consultas o RPC, EDA permite interacciones de microservicios más desacopladas.

Por tanto, dedicamos el Capítulo 5 a explorar la mayoría de los patrones de uso común en EDA y cómo aprovecharlos para construir aplicaciones nativas de la nube. Cubrimos varios aspectos de la AED nativa de la nube, incluidos los patrones de entrega de eventos (basados en colas, pub-sub), semántica y fiabilidad de la entrega, esquemas de eventos y tecnologías y protocolos de implementación relacionados.

Patrones de procesamiento de flujos

En los AED, tratamos en con un único evento cada vez. En otras palabras, la lógica empresarial del microservicio está escrita para tratar un único evento cada vez. No hay correlación entre eventos posteriores. Un flujo, por otra parte, es una secuencia de eventos o elementos de datos disponibles a lo largo del tiempo. Esos eventos son procesados por la aplicación de una manera dinámica.

La arquitectura de implementación y despliegue de un microservicio de este tipo cambia drásticamente con respecto a un microservicio basado en eventos, porque tiene que manejar el estado, realizar un procesamiento de datos eficiente, gestionar diversas semánticas de escalado y concurrencia, etc. Por eso hemos dedicado el Capítulo 6 a los patrones nativos de la nube basados en flujos.

La noción de construir lógica de aplicación para procesar o producir dicho flujo se conoce comúnmente como procesamiento de flujo. Construir aplicaciones nativas de la nube utilizando una arquitectura basada en flujos se está convirtiendo en algo habitual, ya que permite a los microservicios procesar flujos masivos de datos continuos de forma estatal.

Gestión de la API y pautas de consumo

En la mayoría de los casos de uso a media o gran escala de la arquitectura nativa de la nube, tienes que exponer ciertas capacidades empresariales de tus aplicaciones a partes externas o internas que están fuera del ámbito de tu aplicación. Necesitas exponer esas capacidades como servicios gestionados o API. Esto te permite un mayor control sobre la forma en que las partes externas consumen esas capacidades, y permite a las partes externas descubrir fácilmente esas API y proporcionar comentarios al respecto.

La exposición de estas capacidades suele hacerse utilizando una capa de pasarela de API independiente que actúa como puerta de entrada a todas las API que expones. La pasarela API también incluye un plano de gestión y un portal para desarrolladores que se construyen en torno a las API expuestas. El Capítulo 7 cubre varios patrones relacionados con la gestión y el consumo de API.

Ahora que has aprendido los conceptos fundamentales del desarrollo de aplicaciones nativas de la nube, vamos a colocar esos conceptos en un modelo de referencia para que puedas entender cómo se utilizan en una arquitectura de aplicaciones nativas de la nube del mundo real.

Arquitectura de referencia para aplicaciones nativas en la nube

En la mayoría de las aplicaciones nativas de la nube del mundo real, solemos ver una combinación de estrategias de desarrollo. La Figura 1-8 muestra estas diversas estrategias en una arquitectura generalizada. Esta arquitectura de referencia comprende múltiples microservicios que se comunican con diferentes patrones de comunicación. Cada servicio puede utilizar su propio almacén de datos o persistente, y también existe una infraestructura de corredor de eventos compartida o privada. La interacción entre microservicios representa todos los patrones de comunicación que podemos implementar. Cada enlace de comunicación puede implementarse utilizando patrones de conectividad relacionados con la fiabilidad, la seguridad, el enrutamiento, etc.

Figura 1-8. Una arquitectura generalizada para construir aplicaciones nativas de la nube con API, eventos y flujos

Como puedes ver, los microservicios están creando compuestos a partir de uno o más servicios, como los microservicios A, E y G. Estos servicios se construyen utilizando varios patrones de composición. Cuando esa aplicación necesita exponerse como una capacidad empresarial gestionada fuera del ámbito de tu aplicación, puedes aprovechar la gestión de API. Todas las aplicaciones externas pueden consumir esas capacidades a través de una pasarela API, y tú la gestionas a través de los demás componentes de la capa de gestión de API. Para los servicios que se basan en EDA, a menudo es esencial disponer de una solución de corredor de eventos. Los servicios pueden utilizar un corredor compartido como infraestructura de eventos simple o pueden tener también sus corredores de eventos privados.

Los servicios de procesamiento de flujos siguen un enfoque similar, pero la lógica de procesamiento de flujos puede implementarse utilizando un conjunto drásticamente diferente de patrones y tecnologías. Tanto los servicios basados en eventos como los basados en flujos presentan una gestión de eventos/flujos para el lado productor (receptor) del servicio.

Esta arquitectura de referencia puede parecer compleja a primera vista, pero en los próximos capítulos nos sumergiremos en cada aspecto y exploraremos los patrones, las tecnologías de implementación y los protocolos que puedes utilizar para realizarla.

Resumen

La nube nativa es un estilo arquitectónico moderno que permite a las organizaciones construir aplicaciones de software ágiles, fiables, seguras, escalables y gestionables. Nativo de la nube es una forma de construir aplicaciones de software como una colección de servicios orientados a la capacidad empresarial, débilmente acoplados, que pueden ejecutarse en entornos dinámicos de forma automatizada, escalable, resistente, gestionable y observable.

Las aplicaciones nativas de la nube se diseñan como una colección de microservicios, se empaquetan en contenedores y se gestionan con sistemas de orquestación de contenedores como Kubernetes, se automatizan con CI/CD, y se gestionan y observan en un entorno dinámico. Teniendo en cuenta todas estas características, podemos utilizar una metodología completa y pragmática para construir aplicaciones nativas de la nube que abarque el diseño, el desarrollo, la interconectividad, la gestión de API, y la ejecución y gestión en un entorno dinámico.

Podemos aplicar una amplia gama de patrones de diseño al construir aplicaciones nativas de la nube. En este libro, nos centramos principalmente en los patrones de desarrollo que debes aplicar al construir la lógica empresarial de las aplicaciones nativas de la nube, conectarlas y permitir que las partes externas las consuman. Discutimos estos patrones en seis áreas clave: comunicación, conectividad y composición, gestión de datos, arquitectura basada en eventos, procesamiento de flujos, y gestión y consumo de API. En el próximo capítulo, nos sumergiremos en los patrones de comunicación nativos de la nube.

¹ Fuente: Microservicios para la empresa, de Kasun Indrasiri y Prabath Siriwardena (Apress).

² Fuente: Capítulo 2 de Microservicios para la empresa.

³ Puedes encontrar más información en "Smart Endpoints and Dumb Pipes" de Martin Fowler.

⁴ Para más información sobre el diseño basado en dominios, consulta Diseño basado en dominios, de Eric Evans (Addison-Wesley Professional).