carloscastilla - Fotolia

Gestionar Aprenda a aplicar las mejores prácticas y optimizar sus operaciones.

Supere los desafíos de implementación de apps en una estrategia multinube

¿Buscas adoptar un modelo de nubes múltiples? Asegúrese de abordar primero estos desafíos comunes de despliegue, reasignación y escalado de aplicaciones.

No todas las nubes públicas se crean iguales en términos de desarrollo de aplicaciones y características de implementación, una realidad que puede crear muchos desafíos para quienes persiguen una estrategia de múltiples nubes.

Las dificultades surgen especialmente cuando usted escala o vuelve a implementar un componente de la aplicación en una plataforma en la nube diferente a aquella en la que normalmente se ejecuta. Este problema se divide en dos categorías: implementación/administración y ejecución. El primer desafío surge de las diferencias en el despliegue de la aplicación entre las principales plataformas en la nube, algo que los equipos de desarrollo deben resolver con herramientas y prácticas ágiles de orquestación.

El segundo conjunto de desafíos se debe a las diferencias en el funcionamiento de los servicios web de los proveedores de servicios en la nube; las llamadas a los servicios de un proveedor generalmente no funcionarán si el componente de la aplicación se ejecuta en otra nube.

Existen tres estrategias que los equipos de desarrollo pueden usar para acomodar esta variabilidad en una estrategia de múltiples nubes:

  1. Escale y vuelva a implementar aplicaciones solo dentro del mismo entorno de alojamiento.
  2. Implemente despliegues paralelos en cada una de las plataformas en la nube que usa para evitar escalar entre ellas.
  3. Utilice técnicas de abstracción, como el Patrón de Diseño del Adaptador, para hacer que los componentes de la aplicación sean más portátiles entre nubes híbridas y nubes múltiples.

Echemos un vistazo a cada enfoque, junto con sus pros y contras.

Escale y vuelva a desplegar en la misma plataforma

En muchos casos, las empresas eligen alojar diferentes aplicaciones en diferentes plataformas en la nube debido a precios o características especiales. Si ese es el caso, entonces no es necesario escalar o conmutar por error entre plataformas en la nube.

Sin embargo, el gran desafío en este escenario son las diferentes prácticas de implementación y escalado en cada plataforma en la nube. Si tiene un conjunto separado de herramientas y procedimientos para cada proveedor, corre el riesgo de confusión y errores, especialmente cuando realiza cambios en las aplicaciones o sus reglas de escalamiento y redistribución.

Para evitar esto, cree una estrategia de implementación y escalado homogénea. Dos tipos de herramientas pueden ayudar. Primero, una herramienta como Apache Mesos o Mesosphere DC/OS puede proporcionar una capa de abstracción en una estrategia de múltiples nubes, creando un proceso de orquestación uniforme para todas las plataformas en uso. Hace poco, Docker y Kubernetes introdujeron una capacidad de plano de aplicación que ofrece este mismo beneficio. En segundo lugar, una empresa podría usar herramientas DevOps, como Ansible, Chef o Puppet, con complementos para cada plataforma en la nube que utiliza, y luego definir procesos uniformes para la implementación y escalado de aplicaciones, lo que podría requerir un trabajo adicional.

Implementaciones paralelas

Las implementaciones paralelas son similares al enfoque de escalamiento y redistribución anterior; usted implementa el mismo componente de una aplicación de múltiples nubes en cada nube que usa y, en lugar de escalar o volver a desplegar en otras plataformas, comparte el trabajo –como las transacciones o el soporte de conexión del usuario– entre ellos. En este caso, usted maneja la implementación y escala de la aplicación como se describe arriba, y porque nada más que el trabajo se mueve entre las plataformas de la nube, no se requieren técnicas de desarrollo especiales para soportar el movimiento de los componentes de la aplicación.

Sin embargo, hay algunos desafíos. Por ejemplo, deberá cargar el equilibrio entre los componentes de la aplicación duplicados desplegados en cada nube. Un equilibrador de carga VPN, como Cloudflare, funcionará para el tráfico interno, y algo como MODAClouds, un enfoque de desarrollo impulsado por modelos, funcionará para el acceso general de clientes/usuarios.

Técnicas de abstracción

En el tercer escenario, los componentes de la aplicación necesitan escalar o cambiar de sistema a través de los límites de la nube. Cuando esos componentes se basan en servicios web nativos del proveedor, los desarrolladores deben alinearlos con las API específicas de esos servicios. Para evitar tener que mantener múltiples versiones de componentes, uno para cada nube que use, cree un tipo de middleware privado, basado en el Patrón de Diseño de Adaptador antes mencionado. Esto le permite adaptar las APIs del servicio web de los proveedores de la nube en una única especificación API de su propio diseño, que los desarrolladores pueden usar.

Por ejemplo, si dos plataformas en la nube muestran datos móviles de una manera ligeramente diferente, un patrón de diseño del adaptador puede convertir una sola llamada de API que puede funcionar en cualquier nube, incluso dinámicamente en el tiempo de ejecución.

Sin embargo, es posible que los servicios web de proveedores que usted utiliza en una estrategia de varias nubes difieran más allá de sus APIs. Por ejemplo, algunos proveedores abordarán características como el reconocimiento de voz o la compatibilidad con aplicaciones móviles de maneras completamente diferentes, lo que significa que los cambios de API pueden no resolver las cosas. Para superar esto, crea una abstracción de nivel superior o un nivel común donde puedes asignar una API que diseñas a una serie de características en cada nube que usted utiliza.

Si los dispositivos móviles de los usuarios finales difieren en términos de cómo intercambian datos con una aplicación, entonces podría ser necesario dividir su aplicación en un componente funcional que sea independiente de los servicios web de los proveedores, así como un componente en la nube que tenga que coincidir con la nube específica en uso. El componente de la nube podría usar múltiples APIs de proveedores de la nube de diferentes maneras. Esto es casi como escribir middleware específico de la nube, pero el principio de abstracción es el mismo.

Muchos desarrolladores están familiarizados con las nociones de abstracción y middleware, pero no todos. Si los equipos de desarrollo no se sienten cómodos con las aplicaciones de estructuración para separar los componentes específicos de la nube de la funcionalidad general, entonces es mejor no escalar o conmutar por error a través de los proveedores de nube que ofrecen implementaciones diferentes de la misma función. En su lugar, busque enfoques alternativos y manténgase al tanto de las herramientas, especialmente Kubernetes, que continúan avanzando rápidamente.

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close