Anti-patrones de diseño en soluciones nativas en nube

Hoy en día las empresas de tecnología consideran en el diseño de sus soluciones el modelo “Cloud native” (nativo en nube en español). Al diseñar soluciones bajo este modelo se consigue que las aplicaciones modernas sean fácilmente escalables, flexibles al momento de actualizarlas y altamente tolerables a fallos. Con el modelo nativo en nube, se busca que cambios frecuentes en las aplicaciones no afecten la prestación de servicios a los usuarios finales [1].

Sin embargo, el diseño de soluciones basado en el modelo nativo en nube conlleva otro tipo de consideraciones que el modelo tradicional de diseño de software no contempla [2] [3]:

  • Desarrollo de software basado en entrega continua (DevOps).
  • Diseño de software basado en arquitectura de microservicios.
  • Uso de contenedores y herramientas de orquestación.
  • Ejecución de código en ambientes sin servidor (serverless).

 

Si esas “consideraciones” no son puestas en marcha al momento de diseñar software o los problemas derivados de cada una no son identificados y solventados a tiempo, la adopción del modelo nativo en nube puede conllevar problemas graves; anulando las ventajas del modelo.

Para la implantación de este modelo, las empresas deben tener un nivel de madurez aceptable tanto en desarrollo de aplicaciones escalables como un uso previo computación basada en la nube. Muchas veces el salto a desarrollo de soluciones bajo el modelo nativo en nube de forma temprana incurre en la aplicación de anti-patrones de diseño. Es por ello por lo que se han identificado varios de estos a medida que la adopción del modelo nativo en nube ha ido creciendo.

Vamos a revisar los 6 principales anti-patrones del modelo nativo en nube y evitar diseñar software que pueda quedar obsoleto o no escalable antes de su puesta en ejecución.

1. Adopción del modelo nativo en nube sin establecer objetivos
2. Desarrollo o despliegue de aplicaciones monolíticas
3. Falta de automatización en despliegues
4. Ignorar la optimización de recursos y costos de servicios en nube
5. .Uso de servicios basados en la nube sin estrategia definida
6. Diseñar soluciones con muchos componentes que almacenen estados.
7. Bibliografía

 

1. Adopción del modelo nativo en nube sin establecer objetivos [4]

Este es el anti-patrón más común al momento no solo de adoptar el modelo nativo en nube sino al momento de adoptar estrategias de uso de la computación en la nube. Este patrón ocurre cuando no se define indicadores u objetivos medibles en la adopción del modelo. Siempre se deben realizar dos preguntas al momento de adoptar este modelo:

  • ¿Por qué queremos adoptar el modelo?
  • ¿Que beneficios en tema rendimiento, costos y operatividad vamos a lograr en relación con el modelo que actualmente estamos trabajando?

 

2. Desarrollo o despliegue de aplicaciones monolíticas [5]

Una de las consideraciones básicas para el diseño de soluciones en el modelo nativo en nube es el desarrollo de aplicaciones bajo arquitectura de microservicios. Si no se pone en marcha un desarrollo basado en dominio (Domain Driven Design – DDD) para la construcción de software, se desaprovecha el uso y ventajas de la computación en nube. Sin embargo, la adopción de arquitecturas monolíticas no necesariamente es mala, pero si incompatible con el modelo nativo en nube.

 

3. Falta de automatización en despliegues [5]

Antes de adopción del modelo nativo en nube, se debe definir un sistema de integración y despliegue continuo. El realizar despliegues manuales o “pseudo automáticos” puede conllevar a errores, más aún si es que se tienen varios microservicios en ejecución. Así mismo anula la velocidad en cuanto la entrega continua de software, principal ventaja del modelo nativo en nube. Todas las plataformas de computación en nube tienen herramientas de automatización, garantizando incluso la monitorización de los servicios de despliegue.

 

4. Ignorar la optimización de recursos y costos de servicios en nube [6]

Las soluciones pensadas bajo el modelo nativo en nube se diseñan bajo el uso de servicios de los diferentes proveedores de computación en nube. Sin embargo, estos servicios acarrean costos de operación. Además de un buen diseño de interoperabilidad de cada uno de estos servicios, se debe tener en cuenta el correcto dimensionamiento de estos servicios. Si ignoramos este aspecto y sobredimensionamos recursos sin aparente razón, los costos de operación pueden aumentar significativamente y sin control.

 

5. Uso de servicios basados en la nube sin estrategia definida [5] [6]

Los proveedores de computación en nube presentan una vasta cantidad de servicios. Sin embargo, utilizar muchos servicios de estos sin una clara estrategia puede complicar la gestión de solución en su conjunto. La definición del uso de cada servicio debe estar justificada en la fase de análisis y diseño.

 

6. Diseñar soluciones con muchos componentes que almacenen estados [6]

Es casi imposible diseñar soluciones sin algún componente que almacene estado (una base de datos es casi una obligación en el diseño de soluciones). Sin embargo, los componentes basados en estados o persistencia evitan que las soluciones puedan escalar de forma automática y sean tolerante a fallos. Así mismo, estos componentes de la solución (si no están bien afinados) pueden convertirse en cuellos de botella aumentando tiempos de respuesta.

Por esa razón el modelo nativo en nube se debe implementar bajo una arquitectura de microservicios (donde cada microservicio tiene su base de datos) o sobre arquitecturas sin servidor (ejecución de código en servidor y uso de colas para su posterior persistencia o consumo de información).

 

Bibliografía

  1. Amazon Web Services, Inc., «What Is Cloud Native?,» 2023
    https://aws.amazon.com/en/what-is/cloud-native
  2. D. Gannon, R. Barga and N. Sundaresan, «Cloud-Native Application»
    https://www.researchgate.net/publication/321398848_Cloud-Native_Applications
  3. Aplyca, «Cloud Native: principios, aplicaciones y desafíos,» 10 October 2022
    https://www.aplyca.com/blog/cloud-native-principios-aplicaciones-y-desafios
  4. Microsoft Coporation, «Antipatrones de estrategia de nube: adoptar la nube sin establecer los objetivos
    https://learn.microsoft.com/es-es/azure/cloud-adoption-framework/antipatterns/strategy-antipatterns#antipattern-adopt-the-cloud-without-establishing-goals
  5. Alibaba Group, «Five Typical Anti-Patterns of the Cloud-Native Architecture»
    https://www.alibabacloud.com/blog/five-typical-anti-patterns-of-the-cloud-native-architecture_598780
  6. A. Xu, «ByteByteGo Blog – Cloud Native Anti Patterns
    https://blog.bytebytego.com
Anterior

Implementa Firebase Authentication y Firestore en tus aplicaciones Android

Siguiente

The Composable Architecture (TCA)

Talento O2O

¿Te apetece formar parte de nuestro equipo?

Mira las oportunidades