Opiniones | Opinions | Editoriales | Editorials

Aprenda estas lecciones antes de adoptar una nube híbrida

 
Picture of System Administrator
Aprenda estas lecciones antes de adoptar una nube híbrida
by System Administrator - Friday, 31 March 2017, 10:20 PM
Group Colaboradores y Partners

Aprenda estas lecciones antes de adoptar una nube híbrida

La adopción de nubes híbridas va en aumento. Las organizaciones ven las ventajas de los servicios en la nube, pero también quieren permitirse flexibilidad y mantener algunas cargas de trabajo y datos bajo control local.

A pesar de todo el alboroto, la definición "verdadera" de una nube híbrida no siempre ha sido clara para las TI, especialmente debido al ‘lavado’ de nubes. La nube híbrida es un modelo de implementación de TI que utiliza una combinación de servicios en la nube locales (privada) y servicios en la nube de terceros (pública) con orquestación entre ambas plataformas.

MarketsandMarkets estimó que el gasto en nubes híbridas crecerá un 22,5% anual hasta 2021, hasta llegar a casi 92 mil millones de dólares. IDC dijo que el gasto en la infraestructura de TI local tradicional seguirá siendo mayor que el gasto en nube durante los próximos dos años. Aunque, en conjunto, IDC espera que el 32% de los presupuestos de infraestructura de TI vaya a nubes externas y casi el 11% a la nube privada. El híbrido es el modelo preferido entre los usuarios de nube; una popular encuesta de 2016 de RightScale mostró que 71% de los usuarios de la nube operan un entorno híbrido.

Arquitecturas de aplicaciones

Un diseño de nube híbrida es útil en varios escenarios de TI empresariales. Sin embargo, el uso determinará parcialmente lo que funciona y lo que no. Los administradores deben aprender las mejores prácticas de la nube híbrida para que puedan reconocer –y luego evitar– los errores y negligencias comunes que han plagado las implementaciones anteriores de nube.

Una práctica popular de despliegue de nube híbrida es utilizar servicios de nube pública como un centro de datos de recuperación de desastres (DR) o de continuidad de negocios (BC) para una nube privada. Los diseños son en gran parte los mismos, con una diferencia primaria: para BC, la nube pública está siempre activa, mientras que para DR, está en modo de espera y activada solo durante un apagón. En cualquiera de las situaciones, toda la infraestructura necesaria para ejecutar las aplicaciones afectadas debe ser desplegada –o preconfigurada y lista para ser girada– tanto en nubes privadas como públicas.

Un diseño híbrido más avanzado y complejo implica dividir las funciones de aplicación a través de las nubes. En este caso, algunos componentes, a menudo almacenes de datos y directorios de autenticación o autorización, se ejecutan en una nube privada. Otros componentes, como los front-ends de web, la lógica de negocio del middleware y los motores de análisis de big data distribuidos (Hadoop, Spark, etc.), se ejecutan en la nube pública.

Tales diseños bifurcados prometen a TI lo mejor de ambos mundos; ellos ofrecen el control estricto de los datos y la seguridad de los usuarios de la infraestructura privada, combinada con la escalabilidad dinámica de los servicios de nube pública. Este diseño, sin embargo, trae una dificultad añadida a la gestión de la nube híbrida: el desacoplamiento de los datos y el cálculo en los sistemas heredados. Esto significa que las arquitecturas divididas se utilizan mejor con aplicaciones nuevas, no heredadas.

Opciones de infraestructura

Existen varias maneras de construir una infraestructura de nube híbrida que no siempre incluye sistemas locales. Las grandes organizaciones pueden preferir mantener una capacidad sustancial en centros de datos modernos y de gestión privada. De esta forma, pueden conectarse a nubes públicas utilizando redes privadas virtuales a través de internet, o a través de redes WAN privadas que utilizan conexiones cruzadas de nube como Direct Connect de Amazon Web Services (AWS) o Azure ExpressRoute de Microsoft. Las organizaciones más pequeñas cada vez más ejecutan nubes privadas en una instalación de colocación o con un proveedor de servicios administrados. El beneficio obvio es descargar el gasto de capital y la sobrecarga de administración del centro de datos.

Las instalaciones de colocación tienen una conectividad de red superior a la de los operadores y servicios en la nube, lo que hace más fácil y más barato construir conexiones privadas de alta velocidad con la nube pública de elección. De hecho, la importancia de las conexiones rápidas y confiables de baja latencia entre infraestructura de nube pública y privada en una arquitectura híbrida no puede ser exagerada.

Decisiones de diseño híbrido

Una organización debe tomar varias decisiones importantes mientras planea una adopción híbrida de la nube. Evalúe si desea dividir y migrar las aplicaciones existentes o solo las nuevas diseñadas para entornos híbridos. Las aplicaciones heredadas que se pueden ejecutar completamente en infraestructura virtual son buenas candidatas para un diseño híbrido DR/BC. Sin embargo, solo los sistemas no desarrollados (greenfield) deben tratar de desagregar la funcionalidad dentro de una aplicación a través de nubes públicas y privadas (por ejemplo, la computación en la pública y los datos en la privada). Servicios como Azure Site Recovery automatizan el proceso de inventario VM local, replicación de imágenes y datos de VM y despliegue de servicios. Esto simplifica en gran medida el uso de Azure como un sitio de DR/BC de nube híbrida. De hecho, usar la nube para DR es una de las prácticas híbridas más comunes y un buen paso hacia un uso más avanzado de la nube.

Al crear nuevas aplicaciones, decida si desea utilizar infraestructura de bajo nivel como servicio (IaaS) o una más abstracta plataforma como servicio (PaaS). Las opciones PaaS, como Azure App Service y Google App Engine, facilitan el consumo de servicios de nube avanzados, como bases de datos administradas, análisis de big data, aprendizaje automático, equilibradores de carga y redes de distribución de contenido. Aunque IaaS es la opción lógica para mover aplicaciones heredadas cliente-servidor a la nube, significa que los desarrolladores deben elegir proactivamente utilizar servicios nativos de nube como bases de datos SQL gestionadas (por ejemplo, AWS Aurora o Google Cloud SQL) o tiempos de ejecución de contenedores (como AWS Elastic Compute Cloud Container Service o Azure Container Service). Las plataformas PaaS, como Azure App Service, Google App Engine o uno de los proveedores de Cloud Foundry, como IBM Bluemix, liberan a los desarrolladores de las preocupaciones sobre las opciones de infraestructura de tiempo de ejecución; esto permite a los desarrolladores centrarse en la lógica empresarial y en el diseño de bases de datos. Aunque el uso de PaaS aumenta el riesgo de un bloqueo con el proveedor de nube, es una compensación beneficiosa. Reduce los costos porque simplifica el proceso de desarrollo, mejora el rendimiento y elimina los servicios de VM y de almacenamiento sobreprovisionados.

También debe considerar cómo manejar la facturación en la nube. Esto significa, en gran medida, decidir antes de su adopción de nube híbrida si utilizar un cargo retroactivo granular, basada en el uso, para la infraestructura privada –y si asignar finamente los cargos de nube pública por proyecto– o desplegar la implementación de nube híbrida en presupuestos de departamentos o unidades de negocio.

Finalmente, decida cómo integrar el monitoreo del uso de la nube pública en sistemas de facturación de TI legados, y alimentar el modelo de cargo retroactivo antes mencionado. Las nubes públicas proporcionan una variedad de servicios de monitorización potentes, como AWS CloudWatch y Google Stackdriver. Sin embargo, los sistemas de facturación legados deben incorporar y procesar los datos resultantes para asignar los gastos.

Errores a evitar

La adopción híbrida de la nube puede ser el primer intento de una organización para incorporar la nube pública en los servicios de TI. Esto deja a la organización vulnerable a varios errores que le suceden a la mayoría de los novicios en la nube. Evitar estos errores antes de su despliegue de nube híbrida le ahorrará una pena de negocios más adelante.

No olvide completar un acuerdo de nivel de servicio (SLA). Los compradores de nube deben entender lo suficiente de los detalles operativos del proveedor para saber si el servicio puede satisfacer los requisitos de rendimiento, disponibilidad y protección de datos. Un SLA también ayudará a los compradores a comprender y establecer roles y responsabilidades, desempeño disponible y métricas de uso, prácticas de seguridad y consecuencias de la aplicación por incumplimiento. Los compradores también deben comprender los conceptos básicos de la arquitectura de almacenamiento de un proveedor, que pueden incluir lo siguiente: medidas tomadas para proteger contra la pérdida accidental de datos; opciones para diversidad geográfica de instancias de almacenamiento y bases de datos; políticas de retención para los datos recopilados por los proveedores, tales como sus métricas de infraestructura interna; y opciones para migrar tanto datos de clientes como mediciones recopiladas por el proveedor a otro servicio en la nube o centro de datos interno.

No censure de manera inadecuada a los potenciales proveedores de nube. Aunque la nube actúa como una utilidad de información, no es algo comercial, y los servicios en la nube no son todos iguales. Algunos, como Azure, cuentan con una gran cartera de servicios basados ​​en Windows con una estrecha integración con todo el sistema de gestión de Microsoft y el ecosistema de desarrollo de aplicaciones. Otros, como IBM SoftLayer, Oracle Cloud y Rackspace, ofrecen servicios de bare metal que se pueden instanciar dinámicamente y escalar como una VM, pero con un rendimiento altamente predecible y un mayor control sobre los detalles de configuración y seguridad. Algunos, como Azure y Google Cloud, proporcionan una estrecha integración entre los servicios IaaS y PaaS. Esto ofrece a los desarrolladores la facilidad de trabajar con PaaS, así como la opción de usar servicios de infraestructura de bajo nivel cuando sea necesario. Los compradores de nubes híbridas deben identificar claramente sus necesidades y estudiar las alternativas antes de inscribirse.

No empiece demasiado grande. Es mucho mejor construir experiencia en nubes híbridas con pequeños proyectos a corto plazo. La administración de proyectos 101 dice que usted no comienza una nueva y compleja tarea tratando de hervir todo el océano. La gestión de nube híbrida no es diferente. Los compradores deben identificar los proyectos híbridos modestos que se pueden completar en semanas, y así proporcionar un medio de bajo riesgo para desarrollar experiencia en la nube, identificar los cambios necesarios en el proceso de TI y preparar al personal para nuevas responsabilidades.

No deje de redefinir los roles y responsabilidades de TI para reflejar las obligaciones cambiadas al utilizar servicios en la nube. También necesitará recapacitar al personal sobre las nuevas habilidades requeridas en la nube.

No estime inadecuadamente los costos de la nube o monitoree el uso de manera inadecuada. Estas prácticas pueden conducir fácilmente a gastos excesivos.

No cree un diseño de DR incompleto que no tenga en cuenta ni proteja todos los componentes de infraestructura y datos.

No deje de traducir y posteriormente migrar las políticas de seguridad existentes a la infraestructura de la nube. El uso de servicios en la nube cambia el modo en que se implementan las políticas de seguridad, y se pueden desarrollar agujeros de seguridad y nuevas vulnerabilidades si no se abordan durante la migración a la nube.

No automatice de manera inadecuada la infraestructura de nube ni confíe demasiado en los procesos manuales. Los servicios en la nube se pueden multiplicar rápidamente y crear cuellos de botella en la gestión. Sin embargo, como elementos definidos por software, los servicios en la nube son programables, lo que permite que las tareas de rutina sean automatizadas para mayor velocidad y consistencia.

Profundice más

1973 words