Antipatrones de preparación de la nube

Artículo
03/22/2023

A menudo, los clientes experimentan antipatrones durante la fase de preparación de la adopción de la nube. Estos antipatrones pueden provocar tiempos de inactividad inesperados, problemas de recuperación ante desastres y problemas de disponibilidad.

Antipatrón: suponer que los servicios lanzados están preparados para producción

Dado que la informática en la nube evoluciona rápidamente, las empresas a menudo lanzan versiones preliminares de nuevos servicios. Los clientes tienden a suponer que pueden usar cualquier servicio en la nube disponible en un entorno de producción. Sin embargo, pueden producirse problemas por estos motivos:

Normalmente, los servicios en versión preliminar no proporcionan Acuerdos de Nivel de Servicio (SLA) de tiempo de actividad.
Los nuevos servicios no suelen estar tan desarrollados como los servicios en la nube que ya están disponibles.

Ejemplo: uso de la versión preliminar de un servicio en producción

Un instituto de investigación utiliza en producción la versión preliminar de un servicio en la nube. El servicio parece ser una buena opción para su caso de uso. Sin embargo, el instituto no realiza las debidas diligencias en el servicio. El instituto tampoco sigue las instrucciones y los requisitos de la arquitectura de referencia.

Surgen problemas con el servicio en versión preliminar que provocan un tiempo de inactividad inesperado. El instituto comienza a pensar que los servicios en la nube en general no están tan desarrollados ni son tan resistentes como se había prometido.

Resultado preferido: uso de servicios en la nube aprobados previamente en producción

Al evaluar los nuevos servicios que se encuentran en versión preliminar, solo debe usar estos servicios en escenarios de prueba de concepto (POC). No utilice estos servicios en entornos de producción, ya que no tienen Acuerdos de Nivel de Servicio. Busque el equilibrio adecuado entre funcionalidad y madurez al aprobar servicios en la nube. Consulte Lista de comprobación de diligencia debida de servicios en la nube para obtener un marco establecido que pueda usar para evaluar rápidamente los servicios en la nube.

Antipatrón: suponer una mayor resistencia y disponibilidad

La informática en la nube suele tener ventajas frente a la informática local. Algunos ejemplos son:

Mayor resistencia: Recuperación después de un error.
Disponibilidad: Ejecución en un estado correcto sin tiempo de inactividad relevante.

Dado que la mayoría de los servicios en la nube ofrecen estas ventajas, muchas empresas suponen que todos los servicios en la nube ofrecen resistencia y alta disponibilidad de forma predeterminada. En realidad, estas características a menudo solo están disponibles con un costo y un esfuerzo técnico adicionales.

Ejemplo: suposición de una alta disponibilidad

Una empresa emergente implementa una aplicación crítica en servicios de infraestructura como servicio (IaaS). Los desarrolladores de dicha empresa buscaron una máquina virtual (VM) con un Acuerdo de Nivel de Servicio cuyo tiempo de actividad fuera del 99,9 %. Puesto que su intención era reducir los costos, usan una VM única y almacenamiento prémium.

Cuando se produce un error en la VM, su aplicación no se puede recuperar. Se produce un tiempo de inactividad inesperado. Habían dado por sentado que la nube ofrece alta disponibilidad de forma predeterminada. No tuvieron en cuenta que las garantías de rendimiento pueden diferir entre:

Modelos de servicio tales como plataforma como servicio (PaaS) y software como servicio (SaaS).
Arquitecturas técnicas, como conjuntos de disponibilidad con equilibrio de carga y Availability Zones.

Resultado preferido: reducción de errores y equilibrio de la resistencia y los costos

Consulte los recursos de confianza y desarrollados para obtener información sobre los procedimientos recomendados de arquitectura que pueden reducir el ámbito de los errores:

Identifique el equilibrio adecuado entre costos y características como la alta resistencia y la disponibilidad. El aumento de la resistencia y la disponibilidad normalmente supondrán un aumento de los costos. Por ejemplo:

Una sola VM puede tener un Acuerdo de Nivel de Servicio con un tiempo de actividad garantizado del 99,9 %.
Dos VM que ejecutan la misma carga de trabajo proporcionarán un Acuerdo de Nivel de Servicio con un tiempo de actividad entre el 99,95 y el 99,99 %.

Participe en el proceso esencial de ingeniería de los requisitos cuando diseñe una solución basada en la nube. Use un estimador de Acuerdo de Nivel de Servicio como ayuda para calcular dicho acuerdo de un extremo a otro de la aplicación.

Antipatrón: convertirse en un proveedor de nube

Algunas empresas intentan convertir su departamento de TI interno en un proveedor de nube. A continuación, el departamento de TI se responsabiliza de las arquitecturas de referencia. TI también debe proporcionar IaaS y PaaS a las unidades de negocio. Puesto que este tipo de trabajo no suele formar parte del negocio principal de TI, las ofertas de servicio resultantes pueden carecer de facilidad de uso, resistencia, eficacia y seguridad.

Ejemplo: prestación de servicios en la nube monolíticos administrados

El departamento de TI de una corporación establece un centro de excelencia de la nube (CCoE) que actúa como agente entre TI y las unidades de negocio. Para asegurarse de que la corporación cumple los requisitos de la nube, la junta directiva asigna al CCoE la tarea de proporcionar servicios monolíticos de un extremo a otro. El CCoE configura un portal de compras interno en la nube, que las unidades de negocio pueden usar para solicitar una VM en la nube totalmente administrada como un servicio. Sin embargo, TI controla quién puede acceder a toda la plataforma y utilizarla. Como resultado, TI impide activamente que las unidades de negocio aprovechen toda la gama de servicios que proporciona Azure. Las unidades de negocio no pueden acceder al portal de la nube. Solo obtienen acceso a través de Secure Shell (SSH) y del Protocolo de escritorio remoto (RDP) al servidor que solicitan.

Por varias razones, el CCoE tiene problemas para proporcionar un servicio monolítico administrado para encapsular cada servicio disponible en la nube:

La nube ofrece un gran número de servicios en varias áreas de solución. En comparación con el desarrollo de soluciones IaaS, el diseño y la ingeniería de soluciones de Internet de las cosas (IoT) e IA requieren distintos conocimientos y conjuntos de aptitudes.
Los servicios en la nube cambian con frecuencia.
Intentar proporcionar servicios monolíticos aumenta el tiempo de comercialización de forma sustancial. TI administra el proceso, no las unidades de negocio.

Resultado preferido: suministro de límites de protección

Al adoptar tecnologías de nube, haga que el departamento de TI obtenga una experiencia de primera mano con la nube empezando por las cargas de trabajo de TI. Use Microsoft Cloud Adoption Framework para identificar su primer proyecto de adopción.

Use un modelo operativo de nube desarrollado, como las operaciones centralizadas que atribuyen al departamento de TI la responsabilidad de definir los límites de protección de la plataforma, como la gobernanza. A continuación, las unidades de negocio pueden adoptar proyectos en la nube de forma segura y coherente, dentro de los límites de protección definidos por TI.

Considere la posibilidad de adoptar un solo proveedor principal de nube pública al principio, ya que todas las plataformas principales difieren significativamente en la configuración, la administración y el uso.

Use las soluciones de SaaS tanto como sea posible para las herramientas de TI, como:

Repositorios de código.
Integración continua y entrega continua (CI/CD).
Sistemas de colaboración.

En el caso de cargas de trabajo de la nube, aconseje a TI que use procedimientos conocidos que funcionen de forma segura a escala.