BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Este contenido es parte de Guía Esencial: Servicios en la nube y cómo aprovecharlos
Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Las herramientas de integración en la nube alivian los más recientes retos de despliegue

Ubicar las herramientas de integración de nube dentro de un despliegue de cómputo en la nube es un proyecto complejo pero necesario.

La integración es un elemento necesario en casi todos los planes modernos de desarrollo de aplicaciones. Con los años, la experiencia con SOA y con el desarrollo web en el front-end ha enseñado a los planificadores y arquitectos mucho sobre la integración. Las primeras experiencias en la virtualización han ampliado esto aún más, pero la nube se rompe con muchas de las prácticas modernas de integración, por lo que los planificadores y arquitectos necesitan iniciar sus proyectos de integración en la nube preguntando por qué la nube es diferente. A continuación, tienen que evaluar los planes de la nube con la integración que tienen en mente. Para la mayoría, el punto clave será cómo acomodar las herramientas de integración de aplicaciones dentro de despliegue en la nube.

En las primeras aplicaciones, los desarrolladores escribieron ya fuera aplicaciones monolíticas o componentes separados estrechamente acopladas en una imagen de carga común. Un gran número de aplicaciones todavía se escriben de esta manera, pero SOA y el desarrollo ágil han animado a los arquitectos a construir componentes funcionales independientes que se pueden montar en las aplicaciones. Mientras las aplicaciones de negocios se integran más con los procesos de negocio y entre ellos, requieren un acoplamiento más flexible entre las piezas simplemente para eliminar una sola imagen de enorme carga, un modelo de TI de todo o nada.

La integración de estos componentes basada en el esquema de  Directorio se ha convertido en la regla. Con la integración basada en directorios, un componente se registra a sí mismo en algún lugar, y a través de ese registro puede ser localizado y enviarle trabajo. Los directorios pueden ser bastante simples, como DNS, o pueden ser un repositorio para la navegación basada en la funcionalidad, como idealmente sería SOA UDDI. En todos los casos, sin embargo, el directorio espera crear un vínculo a un componente cargado o activar el componente de carga para uso inicial.

La nube desafía esto de dos maneras. En primer lugar, la nube supone un alto nivel de asignación dinámica de recursos. Un componente se podría poner en cualquier lugar de la nube, por lo que el tema de cómo llegar a ella tiene pocos límites, mientras que en el pasado se podría asumir que todo residía en por lo menos un centro de datos fijo. En segundo lugar, uno de los objetivos principales de la nube es la gestión de la disponibilidad y el rendimiento a través de la escala de instancias de componentes. Esto significa que muchos de los componentes tendrán que compartir el trabajo o las fallas de conmutación por error (failover) en tiempo real. A menudo, el proceso de establecimiento de enlaces de integración con los componentes no es instantáneo, y en el período de retardo, el procesamiento de transacciones puede verse comprometido.

Hacer frente a estos retos es una cuestión de evaluación de los planes de la nube para identificar los puntos débiles de integración. Para empezar, busque los lugares donde un componente podría tercerizarse a la nube (cloudsourced) bajo carga o en condiciones de fallo. También, busque situaciones donde un componente de la nube podría ser reubicado por el proveedor de la nube para responder a los problemas. Cualquiera de estos escenarios requerirá un manejo especial en la integración con otros componentes y flujos de trabajo.

Los usuarios de la nube reportan una preferencia para el equilibrio de carga basado en DNS como un medio de dirigir componentes del trabajo-a-la-nube que podrían presentar fallas o ser escalados horizontalmente. En las situaciones de escalamiento, el balanceo de cargas basado en DNS permitirá que el trabajo continúe con enlaces a los componentes actuales mientras que se agrega uno nuevo, por lo que el único riesgo en QoE viene con fallo de un componente, algo que la mayoría de las compañías aceptarán. Si el tiempo de inactividad es intolerable, puede ser abordado con tener al menos dos copias de los componentes disponibles en cualquier punto e integradas a través del DNS.

El problema con el equilibrio de carga basado en DNS es que no soporta la navegación por componentes (no hay WSDL) y esto puede crear problemas para los flujos de trabajo a los componentes que ya tienen un estado (stateful). Si no es posible usar el equilibrio de carga basado en DNS por cualquier razón, la segunda mejor estrategia es la de confiar en el UDDI y WSDL o BPEL para seleccionar entre los componentes. Ese es un problema potencial si los procesos de control de aplicaciones que gestionan los vínculos de los componentes no son responsables de los componentes móviles en la nube. Un componente puede ser removido de su enlace si al moverlo cambia la dirección. La solución de Amazon para esto son las direcciones IP elásticas, que le permiten una URL estática referenciar a un componente móvil. Este enfoque de la traducción de direcciones se puede utilizar también dentro de las nubes privadas.

El modelo de dirección IP elástica de Amazon demuestra una verdad básica sobre la integración de la nube. Hay dos formas de tener "movilidad de componentes": una que debe reconocer componentes separados como elementos discretos que se enlazan en los flujos de trabajo, y una que reconoce las copias de componentes sucesores creadas por los procesos de la nube, más que por los procesos de las aplicaciones. Acomodar esta combinación con las herramientas de integración estándar (incluyendo DevOps o CAMP) es más fácil si usted adopta el principio de que la URL es la frontera entre el movimiento de los componentes lógicos y la ubicación de los componentes físicos.

Las herramientas de integración deben ser utilizadas para reunir los componentes siempre que los componentes se encuentren separados explícitamente debido a que los flujos de trabajo tienen que dirigirse a ellos de forma individual. El objetivo de estas herramientas es dirigir el trabajo a las direcciones URL, con la expectativa de que las direcciones URL serán emparejadas en una ubicación de recursos por un proceso separado de integración de servicios en el back-end.

Es posible manejar la dirección representada por una dirección URL en una herramienta de integración, siempre que la herramienta pueda ser invocada por los administradores de recursos cuando la dirección de un componente cambie. La cuestión fundamental no es la gestión del cambio, sino la gestión del impacto de ese cambio sobre las transacciones en proceso. Es muy peligroso permitir que cualquier flujo de estado cambie los elementos a mitad de camino. Esto podría provocar lo que antes se llamaba "fin de la cola", en la que alguien puede introducirse en el extremo de una transacción auténtica y heredar los derechos del iniciador. Por lo tanto es probable que sea mejor para los flujos de trabajo con estado para reportar fallas en las transacciones en proceso antes de cambiar las direcciones URL de destino.

La seguridad y el cumplimiento siempre debería ser el último punto en cualquier lista de verificación de integración. Los flujos de trabajo pueden presentar problemas relacionados con el cumplimiento, la seguridad al final de la cola y el estado, pero incluso los enlaces de componentes pueden crear problemas que harían palidecer una auditoría de seguridad de aplicaciones si se descubren. La elasticidad de la carga de componentes multiplica la oportunidad de presentar una versión no auténtica de un componente. Como resultado, entre más trabajo de integración se requiera en la nube para asegurar que los flujos de trabajo se mantienen a través de la utilización elástica de recursos, más se tendrán que examinar los procesos de embarque de sus componentes para asegurar que usted sólo introduce elementos adecuados y auténticos en sus flujos de trabajo.

Este artículo se actualizó por última vez en julio 2014

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