¿Qué es Cloud Native?

Sugerencia

Este contenido es un extracto del libro electrónico, Arquitectura de aplicaciones .NET nativas de nube para Azure, disponible en .NET Docs o como un PDF descargable gratuito que se puede leer sin conexión.

Descargar PDF

Detenga lo que está haciendo y pida a sus compañeros que definan el término "Cloud Native". Hay una buena oportunidad de obtener varias respuestas diferentes.

Comencemos con una definición sencilla:

La arquitectura y las tecnologías nativas de la nube son un enfoque para diseñar, construir y operar cargas de trabajo integradas en la nube y aprovechar al máximo el modelo de informática en la nube.

Cloud Native Computing Foundation proporciona la definición oficial:

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 servicio, los microservicios, la infraestructura inmutable y las API declarativas ejemplifican este enfoque.

Estas técnicas permiten sistemas acoplados flexiblemente resistentes, manejables y observables. Junto con una automatización sólida, permiten a los ingenieros realizar cambios de alto impacto con frecuencia y predicción con un trabajo mínimo.

La nube nativa consiste en la velocidad y la agilidad. Los sistemas empresariales evolucionan desde la habilitación de capacidades empresariales a armas de transformación estratégica que aceleran la velocidad y el crecimiento del negocio. Es imperativo conseguir nuevas ideas para comercializar inmediatamente.

Al mismo tiempo, los sistemas empresariales también se han vuelto cada vez más complejos con los usuarios que exigen más. Esperan una capacidad de respuesta rápida, características innovadoras y un tiempo de inactividad cero. Los problemas de rendimiento, los errores recurrentes y la incapacidad de mover rápidamente ya no son aceptables. que harán que los usuarios empiecen a pensar en irse a la competencia. Los sistemas nativos en la nube están diseñados para adoptar cambios rápidos, grandes escalas y resistencia.

Estas son algunas empresas que han implementado técnicas nativas de nube. Piense en la velocidad, agilidad y escalabilidad que han logrado.

Empresa	Experiencia
Netflix	Tiene más de 600 servicios en producción. Realiza implementaciones 100 veces al día.
Uber	Tiene más de 1000 servicios en producción. Despliega varios miles de veces cada semana.
WeChat	Tiene más de 3000 servicios en producción. Despliega 1,000 veces al día.

Como puede ver, Netflix, Uber y WeChat exponen sistemas nativos en la nube que constan de muchos servicios independientes. Este estilo arquitectónico les permite responder rápidamente a las condiciones de mercado. Actualizan instantáneamente áreas pequeñas de una aplicación activa y compleja, sin una reimplementación completa. Escalan individualmente los servicios según sea necesario.

Los pilares de los elementos nativos de la nube

La velocidad y agilidad de la nube nativa derivan de muchos factores. Lo más importante es la infraestructura en la nube. Pero hay más: Otros cinco pilares fundamentales que se muestran en la figura 1-3 también proporcionan la base para los sistemas nativos de la nube.

Figura 1-3. Pilares fundamentales nativos de la nube

Dediquemos un tiempo a comprender mejor la importancia de cada pilar.

La nube

Los sistemas nativos en la nube aprovechan al máximo el modelo de servicio en la nube.

Diseñado para prosperar en un entorno dinámico y virtualizado en la nube, estos sistemas hacen un uso amplio de la infraestructura de proceso de plataforma como servicio (PaaS) y los servicios administrados. Tratan la infraestructura subyacente como descartable (aprovisionada en minutos y cambiada de tamaño, escalada o destruida a petición) a través de la automatización.

Tenga en cuenta la diferencia entre cómo tratamos las mascotas y los productos básicos. En un centro de datos tradicional, los servidores se tratan como mascotas: una máquina física, con un nombre significativo y cuidado. Para escalarlos, agregue más recursos a la misma máquina (escalado vertical). Si el servidor se enferma, lo cuidas hasta que recupere la salud. Si el servidor se vuelve inaccesible, todos se dan cuenta.

El modelo de servicio de productos básicos es diferente. Aprovisiona cada instancia como una máquina virtual o un contenedor. Son idénticos y asignados a un identificador del sistema, como Service-01, Service-02, etc. Puede escalar mediante la creación de más instancias (escalado horizontal). Nadie observa cuándo una instancia deja de estar disponible.

El modelo de productos básicos adopta una infraestructura inmutable. Los servidores no se reparan ni modifican. Si se produce un error o se requiere la actualización, se destruye y se aprovisiona uno nuevo, todo ello a través de la automatización.

Los sistemas nativos en la nube adoptan el modelo de servicio de productos básicos. Siguen ejecutándose cuando la infraestructura se escala o se reduce horizontalmente, independientemente de las máquinas en las que se ejecutan.

La plataforma en la nube de Azure admite este tipo de infraestructura altamente elástica con funcionalidades de escalado automático, recuperación automática y supervisión.

Diseño moderno

¿Cómo diseñaría una aplicación nativa de nube? ¿Qué aspecto tendría la arquitectura? ¿A qué principios, patrones y procedimientos recomendados se adhiere? ¿Qué problemas operativos y de infraestructura serían importantes?

La aplicación Twelve-Factor

Una metodología ampliamente aceptada para construir aplicaciones basadas en la nube es la aplicaciónTwelve-Factor. Describe un conjunto de principios y prácticas que siguen los desarrolladores para construir aplicaciones optimizadas para entornos de nube modernos. Se presta especial atención a la portabilidad entre entornos y automatización declarativa.

Aunque es aplicable a cualquier aplicación basada en web, muchos profesionales consideran Twelve-Factor una base sólida para crear aplicaciones nativas de la nube. Los sistemas creados sobre estos principios pueden implementar y escalar rápidamente y agregar características para reaccionar rápidamente a los cambios de mercado.

En la tabla siguiente se resalta la metodología de Twelve-Factor:

Factor	Explicación
1 - Base de código	Una base de código única para cada microservicio, almacenada en su propio repositorio. Se realiza un seguimiento con el control de versiones, se puede implementar en varios entornos (QA, Ensayo, Producción).
2- Dependencias	Cada microservicio aísla y empaqueta sus propias dependencias, adoptando cambios sin afectar a todo el sistema.
3 - Configuraciones	La información de configuración se mueve fuera del microservicio y se externaliza a través de una herramienta de administración de configuración fuera del código. La misma implementación se puede propagar entre entornos con la configuración correcta aplicada.
4 - Servicios de respaldo	Los recursos auxiliares (almacenes de datos, cachés, agentes de mensajes) deben exponerse a través de una dirección URL direccionable. Si lo hace, desacopla el recurso de la aplicación, lo que le permite ser intercambiable.
5- Compilación, versión, ejecución	Cada versión debe aplicar una separación estricta entre las fases de compilación, versión y ejecución. Cada uno debe etiquetarse con un identificador único y permitir la reversión. Los sistemas de CI/CD modernos ayudan a cumplir este principio.
6 - Procesos	Cada microservicio debe ejecutarse en su propio proceso, aislado de otros servicios en ejecución. Externalice el estado necesario a un servicio de respaldo, como una caché distribuida o un almacén de datos.
7: Enlace a puerto	Cada microservicio debe estar independiente con sus interfaces y funcionalidades expuestas en su propio puerto. Al hacerlo, se proporciona aislamiento de otros microservicios.
8: Simultaneidad	Cuando se necesite aumentar la capacidad, escale los servicios en sentido horizontal mediante varios procesos idénticos (copias) en lugar de escalar en sentido vertical una sola instancia grande sobre la máquina más potente disponible. Desarrolle la aplicación para que sea simultánea, lo que hace que el escalado horizontal en entornos en la nube sea sin problemas.
9 - Desechabilidad	Las instancias de servicio deben poder descartarse. Favorece el inicio rápido para aumentar las oportunidades de escalabilidad y el apagado elegante para dejar el sistema en un estado adecuado. Los contenedores de Docker junto con un orquestador cumplen inherentemente este requisito.
10 - Paridad entre Desarrollo y Producción	Mantenga los entornos en el ciclo de vida de la aplicación lo más parecido posible, lo que evita métodos abreviados costosos. Aquí, la adopción de contenedores puede contribuir considerablemente al promover el mismo entorno de ejecución.
11 - Registro	Trate los registros generados por microservicios como flujos de eventos. Procesarlos usando un agregador de eventos. Propague los datos de registro a herramientas de administración de registros o minería de datos, como Azure Monitor o Splunk y, finalmente, al archivo a largo plazo.
12 - Procesos de administración	Ejecute tareas administrativas o de administración, como limpieza de datos o análisis informáticos, como procesos puntuales. Use herramientas independientes para invocar estas tareas desde el entorno de producción, pero por separado de la aplicación.

En el libro Beyond the Twelve-Factor App, el autor Kevin Hoffman detalla cada uno de los 12 factores originales (escritos en 2011). Además, analiza tres factores adicionales que reflejan el diseño moderno de aplicaciones en la nube actuales.

Nuevo factor	Explicación
13 - API Primero	Convierte todo en un servicio. Supongamos que el código lo consumirá un cliente front-end, una puerta de enlace u otro servicio.
14- Telemetría	En una estación de trabajo, tienes una visión profunda de tu aplicación y su comportamiento. Sin embargo, en la nube, no sucede lo mismo. Asegúrese de que su diseño incluya la recopilación de datos de supervisión, datos específicos del dominio y datos de salud o sistema.
15 - Autenticación y autorización	Implemente la identidad desde el principio. Considere las características de RBAC (control de acceso basado en rol) disponibles en nubes públicas.

Nos referiremos a muchos de los 12 factores de este capítulo y a lo largo del libro.

Marco de buena arquitectura de Azure

Diseñar e implementar cargas de trabajo basadas en la nube puede ser difícil, especialmente al implementar la arquitectura nativa de la nube. Microsoft proporciona procedimientos recomendados estándar del sector para ayudarle a usted y a su equipo a ofrecer soluciones sólidas en la nube.

Microsoft Well-Architected Framework proporciona un conjunto de principios rectores que se pueden usar para mejorar la calidad de una carga de trabajo nativa de la nube. El marco consta de cinco pilares de excelencia de la arquitectura:

Principios	Descripción
Gestión de costes	Céntrese en generar el valor incremental al principio. Aplique los principios build-Measure-Learn para acelerar el tiempo de comercialización, a la vez que evita soluciones de uso intensivo de capital. Utilice una estrategia de pago por uso para invertir a medida que escala horizontalmente, en lugar de ofrecer una gran inversión por adelantado.
Excelencia operativa	Automatice el entorno y las operaciones para aumentar la velocidad y reducir los errores humanos. Revierta las actualizaciones de problemas o póngalas al día rápidamente. Implemente la supervisión y el diagnóstico desde el principio.
Eficacia del rendimiento	Satisfaga de forma eficaz las demandas que se colocan en las cargas de trabajo. Favorezca el escalado horizontal y diséñelo en los sistemas. Realice continuamente pruebas de rendimiento y carga para identificar potenciales cuellos de botella.
Confiabilidad	Cree cargas de trabajo que sean resistentes y disponibles. La resistencia permite que las cargas de trabajo se recuperen de errores y sigan funcionando. La disponibilidad garantiza el acceso de los usuarios a la carga de trabajo en todo momento. Diseñe aplicaciones para esperar errores y recuperarse de ellas.
Seguridad	Implemente la seguridad en todo el ciclo de vida de una aplicación, desde el diseño y la implementación hasta la implementación y las operaciones. Preste mucha atención a la administración de identidades, el acceso a la infraestructura, la seguridad de las aplicaciones y la soberanía y el cifrado de datos.

Para empezar, Microsoft proporciona un conjunto de evaluaciones en línea que le ayudarán a evaluar las cargas de trabajo actuales en la nube con los cinco pilares bien diseñados.

Microservicios

Los sistemas nativos de la nube adoptan microservicios, un estilo arquitectónico popular para construir aplicaciones modernas.

Creado como un conjunto distribuido de servicios pequeños e independientes que interactúan a través de un tejido compartido, los microservicios comparten las siguientes características:

• Cada uno implementa una funcionalidad empresarial específica dentro de un contexto de dominio mayor.

• Cada uno se desarrolla de forma autónoma y se puede implementar de forma independiente.

• Cada uno es autónomo y encapsula su propia tecnología de almacenamiento de datos, dependencias y plataforma de programación.

• Cada se ejecuta en su propio proceso y se comunica con otros usuarios mediante protocolos de comunicación estándar como HTTP/HTTPS, gRPC, WebSockets o AMQP.

• Se unen para formar una aplicación.

La figura 1-4 contrasta un enfoque de aplicación monolítica con un enfoque de microservicios. Observe cómo el monolito se compone de una arquitectura superpuesta, que se ejecuta en un único proceso. Normalmente consume una base de datos relacional. Sin embargo, el enfoque de microservicios separa la funcionalidad en servicios independientes, cada uno con su propia lógica, estado y datos. Cada microservicio hospeda su propio almacén de datos.

Figura 1-4. Arquitectura monolítica frente a microservicios

Tenga en cuenta cómo los microservicios promueven el principio Procesos de la aplicación deTwelve-Factor, descrito anteriormente en el capítulo .

Factor 6 especifica "Cada microservicio debe ejecutarse en su propio proceso, aislado de otros servicios en ejecución".

¿Por qué microservicios?

Los microservicios proporcionan agilidad.

Anteriormente en el capítulo, comparamos una aplicación de comercio electrónico creada como monolítica con los microservicios. En el ejemplo, vimos algunas ventajas claras:

• Cada microservicio tiene un ciclo de vida autónomo y puede evolucionar de forma independiente e implementar con frecuencia. No tiene que esperar a que una versión trimestral implemente una nueva característica o actualización. Puede actualizar un área pequeña de una aplicación activa con menos riesgo de interrumpir todo el sistema. La actualización se puede realizar sin una reimplementación completa de la aplicación.

• Cada microservicio se puede escalar de forma independiente. En lugar de escalar toda la aplicación como una sola unidad, solo se escalan horizontalmente los servicios que requieren más potencia de procesamiento para satisfacer los niveles de rendimiento deseados y los acuerdos de nivel de servicio. El escalado específico proporciona un mayor control del sistema y ayuda a reducir los costos generales a medida que se escalan partes del sistema, no todo.

Una excelente guía de referencia para comprender los microservicios es microservicios de .NET: Arquitectura para aplicaciones .NET en contenedor. El libro profundiza en el diseño y la arquitectura de microservicios. Es un complemento para una arquitectura de referencia completa de microservicios disponible como descarga gratuita de Microsoft.

Desarrollo de microservicios

Los microservicios se pueden crear en cualquier plataforma de desarrollo moderna.

La plataforma Microsoft .NET es una excelente opción. De código abierto y gratuito, tiene muchas características integradas que simplifican el desarrollo de microservicios. .NET es multiplataforma. Las aplicaciones se pueden compilar y ejecutar en Windows, macOS y la mayoría de los tipos de Linux.

.NET es muy eficaz y ha puntuado bien en comparación con Node.js y otras plataformas de competencia. Interesantemente, TechEmpower llevó a cabo un amplio conjunto de pruebas comparativas de rendimiento en muchas plataformas y marcos de aplicaciones web. .NET se ubicó entre los 10 mejores, muy por encima de Node.js y otras plataformas competidoras.

.NET es mantenido por Microsoft y la comunidad de .NET en GitHub.

Desafíos del microservicio

Aunque los microservicios nativos de nube distribuidos pueden proporcionar una gran agilidad y velocidad, presentan muchos desafíos:

Comunicación

¿Cómo se comunicarán las aplicaciones cliente front-end con microservicios principales de back-end? ¿Permitirá la comunicación directa? O bien, ¿podría abstraer los microservicios de back-end con una fachada de puerta de enlace que proporcione flexibilidad, control y seguridad?

¿Cómo se comunicarán los microservicios principales de back-end entre sí? ¿Permitirá llamadas HTTP directas que puedan aumentar el acoplamiento e impactar el rendimiento y la agilidad? ¿O podría considerar la posibilidad de usar una mensajería desacoplada con tecnologías de cola y tema?

La comunicación se trata en el capítulo Patrones de comunicación nativos de la nube.

Resistencia

Una arquitectura de microservicios mueve su sistema de la comunicación de red dentro del proceso a fuera del proceso. En una arquitectura distribuida, ¿qué ocurre cuando el servicio B no responde a una llamada de red desde el servicio A? O bien, ¿qué ocurre cuando el servicio C deja de estar disponible temporalmente y otros servicios que lo llaman se bloquean?

La resiliencia se trata en el capítulo Resiliencia nativa en la nube.

Datos distribuidos

Por diseño, cada microservicio encapsula sus propios datos, exponiendo operaciones a través de su interfaz pública. Si es así, ¿cómo se consultan los datos o se implementa una transacción en varios servicios?

Los datos distribuidos se tratan en el capítulo Patrones de datos nativos de la nube.

Secretos

¿Cómo almacenarán y administrarán de forma segura los microservicios y los datos de configuración confidenciales?

Los secretos se tratan en detalle en Seguridad nativa de la nube.

Administración de la complejidad con Dapr

Dapr es un entorno de ejecución de aplicación de código abierto distribuido. Gracias a una arquitectura de componentes que se pueden conectar, simplifica drásticamente los entresijos que hay tras las aplicaciones distribuidas. Proporciona un pegamento dinámico que enlaza la aplicación con funcionalidades y componentes de infraestructura pregenerados desde el entorno de ejecución de Dapr. En la figura 1-5 se muestra Dapr a 20 000 pies.

Figura 1-5. Dapr a 20 000 pies.

Fíjese que en la primera fila de la imagen, Dapr proporciona los SDK específicos del lenguaje de varias plataformas de desarrollo conocidas. Dapr v1 incluye compatibilidad con .NET, Go, Node.js, Python, PHP, Java y JavaScript.

Aunque los SDK específicos del lenguaje mejoran la experiencia del desarrollador, Dapr es independiente de la plataforma. En segundo plano, el modelo de programación de Dapr expone funcionalidades a través de protocolos de comunicación HTTP/gRPC estándar. Cualquier plataforma de programación puede llamar a Dapr a través de sus API NATIVAs HTTP y gRPC.

Los cuadros azules en el centro de la imagen son los bloques de creación de Dapr. Cada uno de ellos expone código estructural pregenerado para una funcionalidad de aplicación distribuida que la aplicación puede consumir.

La fila de componentes representa un gran conjunto de componentes de infraestructura predefinidos que la aplicación puede consumir. Piense en los componentes como código de infraestructura que no tiene que escribir.

La fila inferior resalta la portabilidad de Dapr y los diversos entornos en los que se puede ejecutar.

Al mirar adelante, Dapr tiene el potencial de tener un impacto profundo en el desarrollo de aplicaciones nativas de la nube.

Contenedores

Es natural que se mencione el término contenedor en cualquier conversación nativa de la nube. En el libro, Cloud Native Patterns, el autor Cornelia Davis observa que"Los contenedores son un gran habilitador del software nativo de la nube". Cloud Native Computing Foundation coloca la contenedorización de microservicios como primer paso en su mapa de pistas deCloud-Native : guía para las empresas que comienzan su recorrido nativo de la nube.

La empaquetación de un microservicio en contenedores es fácil y directa. El código, sus dependencias y el entorno de ejecución se empaquetan en un binario denominado imagen de contenedor. Las imágenes se almacenan en un registro de contenedor, que actúa como repositorio o biblioteca para imágenes. Un registro se puede ubicar en el equipo de desarrollo, en el centro de datos o en una nube pública. Docker mantiene un registro público a través de Docker Hub. La nube de Azure incluye un registro de contenedor privado para almacenar imágenes de contenedor cerca de las aplicaciones en la nube que las ejecutarán.

Cuando una aplicación se inicia o escala, transforma la imagen de contenedor en una instancia de contenedor en ejecución. La instancia se ejecuta en cualquier equipo que tenga instalado un motor en tiempo de ejecución de contenedor. Puede haber tantas instancias del servicio en contenedor como sean necesarias.

En la figura 1-6 se muestran tres microservicios diferentes, cada uno de ellos en su propio contenedor, que se ejecuta en un único host.

Figura 1-6. Varios contenedores que se ejecutan en un host de contenedor

Tenga en cuenta cómo cada contenedor mantiene su propio conjunto de dependencias y tiempo de ejecución, que puede ser diferente entre sí. Aquí, vemos diferentes versiones del microservicio Product que se ejecuta en el mismo host. Cada contenedor comparte un segmento del sistema operativo del host subyacente, la memoria y el procesador, pero está aislado entre sí.

Tenga en cuenta cómo el modelo de contenedor incorpora el principio de Dependencias de la ApplicationTwelve-Factor.

Factor 2 especifica que "Cada microservicio aísla y empaqueta sus propias dependencias, adoptando cambios sin afectar a todo el sistema".

Los contenedores admiten cargas de trabajo de Linux y Windows. La nube de Azure adopta abiertamente ambos. Interesantemente, es Linux, no Windows Server, que se ha convertido en el sistema operativo más popular en Azure.

Mientras existen varios proveedores de contenedores, Docker ha capturado la mayor parte en el mercado. La empresa ha sido una gran impulsora del movimiento de contenedores de software. Se ha convertido en el estándar de facto para empaquetar, implementar y ejecutar aplicaciones nativas de nube.

¿Por qué los contenedores?

Los contenedores proporcionan portabilidad y garantía de coherencia entre entornos. Al encapsular todo en un único paquete, aísla el microservicio y sus dependencias de la infraestructura subyacente.

Puede implementar el contenedor en cualquier entorno que hospede el motor en tiempo de ejecución de Docker. Las cargas de trabajo en contenedores también eliminan el gasto de configurar previamente cada entorno con marcos, bibliotecas de software y motores en tiempo de ejecución.

Al compartir los recursos del sistema operativo y del host subyacentes, un contenedor tiene una superficie mucho menor que una máquina virtual completa. El tamaño menor aumenta la densidad o el número de microservicios que un host determinado puede ejecutar al mismo tiempo.

Orquestación de contenedores

Aunque las herramientas como Docker crean imágenes y ejecutan contenedores, también necesita herramientas para administrarlas. La administración de contenedores se realiza con un programa de software especial denominado orquestador de contenedores. Cuando se trabaja a escala con muchos contenedores que funcionan de manera independiente, la orquestación es esencial.

En la figura 1-7 se muestran las tareas de administración que automatizan los orquestadores de contenedores.

Figura 1-7. Qué hacen los orquestadores de contenedores

En la tabla siguiente se describen las tareas comunes de orquestación.

Tareas	Explicación
Programación	Aprovisionamiento automático de instancias de contenedor.
Afinidad/antiafinidad	Aprovisione contenedores cercanos o alejados entre sí, lo que ayuda a la disponibilidad y el rendimiento.
Monitoreo de la salud	Detectar y corregir errores automáticamente.
Conmutación por error	Aprovisionamiento automático de cualquier instancia con errores en una máquina en buen estado.
Ampliación	Agregue o quite automáticamente una instancia de contenedor para satisfacer la demanda.
Redes	Administre una superposición de red para la comunicación de los contenedores.
Detección de servicios	Habilite los contenedores para localizarse entre sí.
Actualizaciones graduales	Coordinar las actualizaciones incrementales con una implementación sin tiempo de inactividad. Revierta automáticamente los cambios problemáticos.

Tenga en cuenta que los orquestadores de contenedores usan los principios de Descartabilidad y Simultaneidad de Twelve-Factor Application.

Factor #9 especifica que "Las instancias de servicio deben ser descartables, favoreciendo inicios rápidos para aumentar las oportunidades de escalabilidad y apagados elegantes para dejar el sistema en un estado adecuado". Los contenedores de Docker junto con un orquestador cumplen de manera inherente este requisito".

Factor 8 especifica que "Los servicios se escalan horizontalmente en un gran número de pequeños procesos idénticos (copias), en oposición al escalado vertical de una sola instancia grande en la máquina disponible de mayor potencia".

Aunque existen varios orquestadores de contenedores, Kubernetes se ha convertido en el estándar de facto para el mundo nativo de la nube. Es una plataforma portable, extensible y de código abierto para administrar cargas de trabajo en contenedores.

Podría hospedar su propia instancia de Kubernetes, pero después sería responsable del aprovisionamiento y la administración de sus recursos, lo que puede ser complejo. La nube de Azure incluye Kubernetes como servicio administrado. Tanto Azure Kubernetes Service (AKS) como Red Hat OpenShift (ARO) de Azure le permiten aprovechar completamente las características y la eficacia de Kubernetes como servicio administrado, sin tener que instalarla y mantenerla.

La orquestación de contenedores se trata en detalle en Escalado de aplicaciones nativas de la nube.

Servicios de respaldo

Los sistemas nativos de nube dependen de muchos recursos auxiliares diferentes, como almacenes de datos, agentes de mensajes, supervisión y servicios de identidad. Estos servicios se conocen como servicios de respaldo.

En la figura 1-8 se muestran muchos servicios de respaldo comunes que consumen los sistemas nativos de la nube.

Figura 1-8. Servicios de respaldo comunes

Puede hospedar sus propios servicios de respaldo, pero después sería responsable de las licencias, el aprovisionamiento y la administración de esos recursos.

Los proveedores de nube ofrecen una amplia variedad de servicios de respaldo administrados. En lugar de poseer el servicio, simplemente lo consume. El proveedor de nube opera el recurso a escala y asume la responsabilidad del rendimiento, la seguridad y el mantenimiento. La supervisión, la redundancia y la disponibilidad están integradas en el servicio. Los proveedores garantizan el rendimiento del nivel de servicio y respaldan completamente sus servicios gestionados: abra una incidencia y solucionan su problema.

Los sistemas nativos en la nube favorecen los servicios de respaldo administrados de los proveedores de nube. El ahorro en el tiempo y la mano de obra pueden ser significativos. El riesgo operativo de gestionar tu propio servidor y si surgen problemas, puede volverse rápidamente costoso.

Un procedimiento recomendado es tratar un servicio de respaldo como un recurso asociado, enlazado dinámicamente a un microservicio con información de configuración (una dirección URL y credenciales) almacenada en una configuración externa. Esta guía se explica en la Twelve-Factor Aplicación, que se ha descrito anteriormente en el capítulo .

Factor 4 especifica que los servicios de respaldo "deben exponerse a través de una dirección URL direccionable. Si lo hace, desacopla el recurso de la aplicación, lo que le permite ser intercambiable".

Factor #3 especifica que "La información de configuración se mueve fuera del microservicio y se externaliza a través de una herramienta de administración de configuración fuera del código".

Con este patrón, un servicio de respaldo se puede adjuntar y desasociar sin cambios de código. Cualquier microservicio se puede promover de QA a un entorno de ensayo. Actualice la configuración del microservicio para que apunte a los servicios de respaldo del almacenamiento provisional e inserte la configuración en el contenedor a través de una variable de entorno.

Los proveedores en la nube proporcionan API para comunicarse con sus servicios de respaldo propietarios. Estas bibliotecas encapsulan la complejidad y los entresijos de los servicios propietarios. Sin embargo, la comunicación directa con estas API acoplará estrechamente el código a ese servicio de respaldo específico. Es una práctica ampliamente aceptada para aislar los detalles de implementación de la API del proveedor. Introduzca una capa de intermediación o una API intermedia, exponiendo operaciones genéricas al código de servicio y encapsulando el código del proveedor dentro de él. Este acoplamiento flexible le permite intercambiar un servicio de respaldo para otro o mover el código a otro entorno en la nube sin tener que realizar cambios en el código de servicio de línea principal. Dapr, descrito anteriormente, sigue este modelo con su conjunto de bloques de creación precompilados.

Por último, los servicios de respaldo también promueven el principio de Falta de estado de Twelve-Factor Application, que ya se ha explicado en este mismo capítulo.

Factor #6 especifica que" Cada microservicio debe ejecutarse en su propio proceso, aislado de otros servicios en ejecución. Externalice el estado necesario a un servicio de respaldo, como una caché distribuida o un almacén de datos".

Los servicios de respaldo se describen en patrones de datos nativos de la nube y patrones de comunicación nativos de la nube.

Automatización

Como ha visto, los sistemas nativos de la nube adoptan microservicios, contenedores y diseño moderno del sistema para lograr velocidad y agilidad. Pero eso es solo parte de la historia. ¿Cómo aprovisiona los entornos en la nube en los que se ejecutan estos sistemas? ¿Cómo se implementan rápidamente las características y actualizaciones de la aplicación? ¿Cómo se completa la imagen?

Introducción a la práctica ampliamente aceptada de Infraestructura como código, o IaC.

Con IaC, automatiza el aprovisionamiento de plataformas y la implementación de aplicaciones. Básicamente, aplica prácticas de ingeniería de software, como pruebas y control de versiones a las prácticas de DevOps. La infraestructura y las implementaciones son automatizadas, coherentes y repetibles.

Automatización de la infraestructura

Herramientas como Azure Resource Manager, Azure Bicep, Terraform desde HashiCorp y la CLI de Azure, le permiten crear scripts declarativos de la infraestructura en la nube que necesita. Los nombres de recursos, las ubicaciones, las capacidades y los secretos son parametrizados y dinámicos. El script tiene versiones y se inserta en el repositorio del control de código fuente como un artefacto del proyecto. El script se invoca para aprovisionar una infraestructura coherente y repetible en entornos del sistema, como QA, ensayo y producción.

En segundo plano, IaC es idempotente, lo que significa que se puede ejecutar el mismo script una y otra vez sin efectos secundarios. Si el equipo necesita realizar un cambio, edita y vuelve a ejecutar el script. Solo se ven afectados los recursos actualizados.

En el artículo ¿Qué es la infraestructura como código?, el autor sam Guckenheimer describe cómo" Los equipos que implementan IaC pueden ofrecer entornos estables rápidamente y a escala. Evitan la configuración manual de entornos y aplican la coherencia mediante la representación del estado deseado de sus entornos a través del código. Las implementaciones de infraestructura con IaC son repetibles y evitan problemas en tiempo de ejecución causados por el desfase de configuración o las dependencias que faltan. Los equipos de DevOps pueden trabajar conjuntamente con un conjunto unificado de prácticas y herramientas para ofrecer aplicaciones y su infraestructura auxiliar de forma rápida, confiable y a gran escala".

Automatización de implementaciones

La Twelve-Factor Aplicación, que se ha descrito anteriormente, llama a pasos independientes al transformar el código completado en una aplicación en ejecución.

Factor 5 especifica que "Cada versión debe aplicar una separación estricta entre las fases de compilación, versión y ejecución. Cada una de ellas debe etiquetarse con un identificador único y permitir la reversión".

Los sistemas de CI/CD modernos ayudan a cumplir este principio. Proporcionan pasos de compilación y entrega independientes que ayudan a garantizar un código coherente y de calidad que esté disponible fácilmente para los usuarios.

En la figura 1-9 se muestra la separación a lo largo del proceso de implementación.

Figura 1-9. Pasos de implementaciones en una canalización de integración continua y entrega continua

En la ilustración anterior, preste especial atención a la separación de tareas:

1. El desarrollador crea una característica en su entorno de desarrollo, iterando a través de lo que se denomina "bucle interno" de código, ejecución y depuración.
2. Cuando haya finalizado, ese código se inserta en un repositorio de código, como GitHub, Azure DevOps o BitBucket.
3. El envío desencadena una fase de compilación que transforma el código en un artefacto binario. El trabajo se implementa con una canalización de integración continua (CI). Compila, prueba y empaqueta automáticamente la aplicación.
4. La fase de versión recoge el artefacto binario, aplica información de configuración de entorno y aplicación externa y genera una versión inmutable. La versión se implementa en un entorno especificado. El trabajo se implementa con una canalización de entrega continua (CD). Cada versión debe poder identificarse fácilmente. Puede decir: "Esta implementación ejecuta la versión 2.1.1 de la aplicación".
5. Por último, la característica publicada se ejecuta en el entorno de ejecución de destino. Las versiones son inmutables, lo que significa que cualquier cambio debe crear una nueva versión.

Al aplicar estas prácticas, las organizaciones han evolucionado radicalmente cómo envían software. Muchos han pasado de las versiones trimestrales a las actualizaciones a petición. El objetivo es detectar problemas al principio del ciclo de desarrollo cuando son menos costosos de corregir. Cuanto mayor sea la duración entre las integraciones, más costoso se vuelve resolver los problemas. Con la coherencia en el proceso de integración, los equipos pueden confirmar los cambios de código con más frecuencia, lo que conduce a una mejor colaboración y calidad de software.

La infraestructura como automatización de código e implementación, junto con GitHub y Azure DevOps, se describen en detalle en DevOps.

Siguiente anterior