10 antipatrones Cloud.

En el mundo del desarrollo llevamos muchos años convirtiendo conceptos de negocio en software. A lo largo de este tiempo se han ido encontrando buenas prácticas para resolver problemas comunes, pero también se ha ido generando un compendio de peores prácticas. De esto queremos escribir hoy en el blog de Paradigma: de antipatrones. En concreto, de aquellos que suelen ser más comunes en ecosistemas Cloud.

Un antipatrón se puede definir como una solución recurrente a un problema que genera consecuencias negativas tales como ineficiencias, vulnerabilidades u otros problemas significativos.

A veces se aprende más de un error o de un mal ejemplo que de algo funcionando correctamente. Por eso, hoy comentaremos los 10 antipatrones más comunes (entre los cientos que existen) en entornos Cloud. Analizaremos en qué consiste cada antipatrón, cuándo ocurren, cuál es su impacto negativo y veremos cómo podemos evitar caer en ellos.

1 Shadow IT

Descripción

Un clásico que no solo aplica al Cloud. De hecho, tiene muchos nombres como “Stovepipe”, “Cocinado en caliente", etc. Consiste en la creación de islas independientes, muchas veces en conflicto unas con otras, dentro de la misma empresa. Cada departamento trata de resolver sus requerimientos de forma independiente, creando soluciones software propias que no están trazadas por el departamento de sistemas de la compañía.

Problemas que genera

La nube favorece que puedas probar e innovar rápido, te pone todo a un click. Por ello también facilita que puedas montarte tu propia solución al margen del control del lento y anticuado departamento corporativo de sistemas. Esto provoca un aumento de costes ocultos, falta de estandarización y falta de reutilización.

Solución

Resulta fundamental establecer una estrategia tecnológica a nivel de compañía donde primen los estándares abiertos, la comunicación entre departamentos, la construcción de interfaces para la integración de los sistemas, y donde se incentive la cooperación entre áreas.

2 Hacer un arco de iglesia

Descripción

Sobreingeniería o “La navaja suiza”. Un error arquitectónico habitual es diseñar sistemas con una complejidad o funcionalidad innecesarias. En muchas ocasiones sucede porque tratan de preveerse necesidades futuras que finalmente nunca se requieren. Un ejemplo de esto puede ser crear una arquitectura de microservicios extremadamente compleja para una aplicación simple en la que un diseño monolítico funcionaría perfectamente.

Problemas que genera

Al implementar soluciones más complejas y más grandes, la consecuencia evidente es que tendrán un coste mayor, habrá que invertir tiempos de desarrollo más prolongados y habrá que dedicar mayor esfuerzo a su mantenimiento.

Solución

Hay que tratar de mantener el enfoque en las necesidades actuales del proyecto y evitar la tentación de sobre-diseñar. Como dicen, aplicar el principio KISS: Keep It Simple, Stupid.

3 Sobreasignar recursos

Descripción

Otro error que suele ser bastante común es aprovisionar instancias o servicios en la nube con excesiva capacidad "por si acaso", asignando recursos de forma similar a como se hace On-Premise.

Problemas que genera

Configurar muchos más recursos de los necesarios impide, de entrada, que el consumo se adapte a la demanda y, por tanto, se produce un incremento innecesario de los costes.

Solución

Implantar buenas prácticas de right-sizing. Implementar el escalado automático para ajustar dinámicamente las capacidades. Utilizar herramientas de análisis de uso (como AWS Cost Explorer o Google Cloud Cost Management) para ajustar recursos según la demanda.

4 Subestimar los costes ocultos

Descripción

Migrar nuestras aplicaciones a la nube sin tener una visión clara de los costes, especialmente en servicios como transferencia de datos, almacenamiento o servicios adicionales puede poner en peligro la adopción de la nube o darnos algún que otro susto financiero.

Problemas que genera

Pueden aparecer facturas inesperadas u ocasionar que nuestro presupuesto se consuma mucho antes de lo esperado.

Solución

Es imprescindible diseñar una estrategia FinOps desde el inicio, monitorizando los costes en tiempo real y estableciendo límites y alertas.

5 Expansión incontrolada

Descripción

Otra mala práctica muy habitual, sobre todo en entornos de desarrollo y pruebas, es crear más recursos de los necesarios y olvidarse de apagarlos o de eliminarlos después de utilizarlos.

Problemas que genera

Esto hace que haya recursos que no se utilizan pero que generan costes recurrentes.

Solución

Como en el antipatrón anterior, la base de la solución debe partir de una estrategia FinOps. Implementar políticas de etiquetado (tagging) para identificar recursos, configurar herramientas de monitorización y establecer procesos para revisar y eliminar recursos inactivos periódicamente.

6 Falta de automatización

Descripción

Gestionar la infraestructura mediante tareas manuales en lugar de automatizarla con herramientas como Terraform, Ansible o CloudFormation. Así como desplegar manualmente nuestras aplicaciones.

Problemas que genera

Hay que invertir mucho tiempo para realizar todas esas tareas repetitivas. Esto es una fuente de errores humanos, hace que los diferentes entornos tengan inconsistencias entre ellos y dificulta la reutilización.

Solución

Adoptar Infraestructura como Código (IaC) desde el inicio para gestionar y versionar la infraestructura y CI/CD para la integración y despliegue de las aplicaciones asegurará la consistencia y la escalabilidad.

7 Utilizar una única AZ

Descripción

Diseñar aplicaciones sin tener en cuenta la alta disponibilidad y configurarlas utilizando solamente servicios cloud en una única zona de disponibilidad (AZ) de una región.

Problemas que genera

Pueden producirse pérdidas de servicio por la falta de disponibilidad.

Solución

Una buena práctica para implementar arquitecturas distribuidas en la nube suele ser utilizar varias AZs o regiones para garantizar una resiliencia adecuada. En definitiva, se trata de diseñar sistemas con tolerancia a fallos.

8 Escalar solo verticalmente

Descripción

Contemplar únicamente la escalabilidad vertical y no la horizontal a la hora de diseñar nuestras aplicaciones. Si únicamente aumentamos el tamaño de las máquinas en lugar de añadir más máquinas, nos estaremos perdiendo algunas de las principales ventajas de la nube.

Problemas que genera

El escalado vertical puede hacer que se alcancen los límites físicos de las instancias y no podamos aumentar más la capacidad. Es probable que no se adapte adecuadamente a la demanda y suponga un incremento de costes. Y también dificultará el escalado automático.

Solución

Diseña aplicaciones que puedan distribuir la carga en varias instancias stateless, utilizando servicios como balanceadores de carga y bases de datos distribuidas.

9 Lock-In

Descripción

También conocido como Vendor Lock-In o, más coloquialmente, como “casarse con el diablo”. Consiste en depender de un solo proveedor al incorporar un producto o servicio, dificultando el cambio a otros proveedores.

Problemas que genera

Comprometerse profundamente con un proveedor sin considerar alternativas a largo plazo se traduce en falta de flexibilidad y costes muy elevados en caso de cambio.

Solución

Diseñar sistemas de manera modular para facilitar la interoperabilidad y la migración. Considerar estrategias multicloud o híbridas para evitar la dependencia de un solo proveedor y utilizar estándares abiertos y tecnologías portables como Kubernetes y contenedores.

10 Desaprovechar los servicios cloud nativos

Descripción

Llevar aplicaciones a la nube sin realizar ningún cambio ni adaptación suele ser rápido pero impide aprovechar las capacidades de la nube. Este antipatrón está íntimamente relacionado con patrones clásicos como Under-Engineering o The Blob, en los que se realiza una planificación y diseños inadecuados y se generan sistemas frágiles y poco confiables. También puede pasar al crear nuevas aplicaciones y, por ejemplo, utilizar máquinas virtuales (VMs) para todo, ignorando servicios cloud nativos como bases de datos gestionadas o funciones serverless.

Problemas que genera

Al no optimizar las aplicaciones haciéndolas más cloud native, los costes se incrementan, el rendimiento no es óptimo y falta escalabilidad. También hace que la complejidad operativa sea mayor.

Solución

En las migraciones, la manera más sencilla de evitar esto es realizar un análisis previo para estudiar si hay que rediseñar la aplicación para beneficiarse de las características nativas de la nube y hacer uso del escalado automático o de servicios serverless, por ejemplo. En todos los casos, estar al día de los servicios gestionados que ofrece cada proveedor y usarlos siempre que sea posible es conveniente para simplificar la operación.

Conclusión

Existen muchas más malas prácticas, hoy solo hemos comentado una pequeña selección de ellas. Pero si estamos alerta, reconocemos y abordamos estos problemas comunes, estaremos bien preparados para mejorar el uso que hacemos de la nube, optimizando los costes, mejorando el rendimiento y aumentando la reutilización y la escalabilidad.

De forma general, podemos decir que la mayoría de antipatrones suelen surgir por la falta de experiencia, por una planificación inadecuada o por las prisas de querer migrar a la nube demasiado rápido. En Paradigma Digital, creemos que la clave está en abordar estos desafíos desde el inicio con una mentalidad proactiva y colaborativa apoyándose en los patrones y buenas prácticas que definen los frameworks de arquitectura de los proveedores cloud. Esto marcará la diferencia entre un proyecto exitoso y uno que se convierta en una fuente de problemas continuos.