Contenido


La envolvente arquitectura de referencias de integración híbrida

Cómo garantizar que su entorno de integración mantiene el ritmo de la transformación digital

Comments

Con el tiempo, la integración incrementa inevitablemente su complejidad. Esta complejidad es el resultado de la mayor diversidad de recursos que tenemos que integrar, en las siempre crecientes permutaciones de infraestructuras y plataformas. Es más, las personas implicadas en la integración de sistemas ya no están centralizadas en un único equipo técnico, sino que están esparcidas a través de la empresa y fuera de ella.

En paralelo, y en parte como resultado de este incremento de la complejidad, el impulso de la competición tiene por objetivo simplificar y racionalizar la integración. Las APIs web han madurado para convertirse en una plataforma común y en una forma en la que las aplicaciones se comunican independientemente del lenguaje. La infraestructura está incluso más virtualizada y separada en contenedores, para liberar los tiempos de ejecución de hardware y de sistemas operativos específicos y para habilitar la coordinación elástica de las cargas de trabajo. Los equipos están aprendiendo a reunir de forma más efectiva a su personal de desarrollo de operaciones, y a automatizar desde la construcción hasta el despliegue para conseguir ciclos de liberación rápidos.

Los desafíos verdaderamente son híbridos en muchos sentidos diferentes. Ubicaciones, equipos, métodos, plataformas y demás están divergiendo continuamente. La arquitectura de la integración a través de este entorno híbrido está evolucionando a un ritmo rápido.

Este artículo explora cómo ha evolucionado la integración híbrida. Primero, examinamos cómo ha cambiado el enfoque de la integración con el movimiento a la nube. Después, definimos las características de alto nivel de una capacidad de integración híbrida. Después, explicamos cómo TI cada vez es menos una función central de dentro de la organización. Continuamos echando un vistazo a los bloques de construcción fundamentales de la arquitectura de integración híbrida y cómo se puede producir la integración a través de la economía de la API. Finalmente, destacamos cómo es posible reconocer y satisfacer las necesidades del equipo digital y mejorar la consistencia a través del entorno híbrido.

La extendida superficie del área de una integración híbrida

En la actualidad, las fronteras de la propiedad de una empresa se extienden más allá de sus muros, abarcando los activos de TI que se encuentra a lo largo de un verdadero entorno híbrido. En esta arquitectura, las aplicaciones ya existentes se trasladan hacia la Infraestructura como servicio (IaaS) de los proveedores en la nube. Las aplicaciones nuevas a menudo se construyen en la nube en forma de Plataforma como servicio (PaaS). En línea con esta tendencia, también está teniendo lugar un aumento de la utilización de software como servicio (SaaS) basado en la nube y preconstruido.

Además, la interacción con partes externas, ya sean clientes o asociados de negocios, se está automatizando cada vez más. Normalmente, el grado de automatización con esas partes externas es un diferenciador empresarial.

Extended surface area of hybrid integration
Extended surface area of hybrid integration

Como tal, toda capacidad de integración debe abordar fundamentalmente la conectividad a través de límites de la nube. Esta capacidad también debe simplificar los problemas de seguridad y gestión que conlleva y adoptar los estándares que evolucionan dentro de las arquitecturas híbridas.

La integración híbrida a menudo se define de una forma simplista como la habilidad de integrar sistemas de dentro de las instalaciones con sistemas en la nube. Para la mayor parte de las organizaciones la realidad abarca mucho más. Una verdadera arquitectura de integración híbrida considera la integración entre todos los entornos que pertenecen a la organización, abarcando entornos en instalaciones y en nube, sin importar si la nube es local, dedicada o pública. También abarca desde un entorno autoconstruido pasando por plataformas hasta SaaS. También debe tener en cuenta cómo la empresa conecta con sus asociados y clientes. La integración híbrida tiene un ámbito enorme. El desafío principal es cómo interpretar esa complejidad y encontrar patrones comunes en su arquitectura para ayudar a simplificar el problema.

Capacidades principales de la integración híbrida

A un nivel alto, la integración híbrida es una infraestructura de integración amplia. Conecta constantemente todos los entornos pertenecientes a la organización, ya sean fuentes de datos directos, aplicaciones o APIs, y puede realizar conexiones a ellos independientemente de donde se puedan encontrar: en las instalaciones, IaaS, PaaS or SaaS.

Capabilities and scope of hybrid integration
Capabilities and scope of hybrid integration

La integración híbrida debe contener amplias capacidades de conectividad para las aplicaciones modernas basadas y para los igualmente críticos viejos sistemas de registro (SOR). Debe tener herramientas para simplificar y acelerar la productividad, como mapeo y transformación rápidos y flexibles. Desde una perspectiva no funcional, también debe brindar escalabilidad, seguridad y resilencia de nivel empresarial y de nivel de Internet.

Sin embargo, es importante definir la integración híbrida como un todo, debemos considerar la forma en la que las necesidades de integración están cambiando y reconocer que hay dos audiencias diferentes implicadas.

Adopción de TI por el negocio

Desde hace algunos años, y particularmente acelerado por la revocación móvil, el departamento de TI centralizado se ha bifurcado en al menos dos campos: a menudo denominados TI empresarial y TI digital.

La TI empresarial mantiene su rol vital de garantizar que los sistemas críticos el negocio mantienen sus niveles de servicio y brindan el tipo de integridad de los datos y la gobernanza segura que se espera de sistemas principales de los que la empresa depende. Sin embargo, este entorno fuertemente regulado y controlado no satisface las necesidades de la línea de negocio (LOBs), quienes deben mantener fresca la imagen pública de la empresa con proposiciones e innovaciones nuevas en un mercado que cambia rápidamente.

Las LOBs cada vez están más centradas en requisitos, como los de los siguientes ejemplos:

  • Agilidad Las LOBs necesitan explorar y adaptarse, iterando rápidamente sobre los prototipos, y cuando sea necesario, errando rápidamente y pasando a la siguiente idea. Este enfoque implica la utilización de técnicas diferentes para construir aplicaciones formadas por más componentes, como una arquitectura de microservicios. También significa incrementar el enfoque en una cultura de DevOps, donde se minimiza la distancia entre los cambios de implementación y la entrega de la producción.
  • Escalabilidad. Si se lanza un prototipo, las LOBs deben ser capaces de escalarlo elásticamente, que el prototipo pase de un puñado de usuarios patrocinados al mercado abierto, sin un considerable esfuerzo de desarrollo adicional. Las LOBs deben ser capaces de incrementar y reducir la infraestructura mediante la utilización de un modelo de costos simple y predecible, que implique la utilización de IaaS o PaaS, y mediante la adhesión a una arquitectura de aplicaciones escalable por naturaleza.
  • Latencia. Las LOBs también pueden tener diferentes necesidades en lo concerniente a la respuesta en tiempo real de las aplicaciones que brindan. La latencia requerida para crear una experiencia móvil cautivadora puede ser considerablemente menor que la latencia que brindan los actuales sistemas de registro. La latencia puede requerir la utilización de datos en caché o pre-agregados, y diseñar entre complejos problemas de duplicación de datos y consistencia eventual. También pueden requerir de una gestión adecuada del tráfico para priorizar las cargas de trabajo.
  • Disponibilidad. La reputación de una empresa que es principalmente online se puede ver dañada de una forma irreversible incluso por el menor tiempo de inactividad en el peor momento. La disponibilidad comprobada es una gran diferenciadora. Las LOBs necesitan aplicaciones que sean diseñadas para una alta disponibilidad continua. Estas aplicaciones a menudo requieren diferentes abordajes para la resiliencia, que usted podría escoger para las aplicaciones internas de la empresa.

Debido a estos requisitos, puede ver porque dentro de las LOBs han surgido los departamentos de TI oculta y ahora están adquiriendo nuevos proyectos importantes por utilizar técnicas que son diferentes de las técnicas utilizadas por el departamento TI central. Estos departamentos de TI de las LOBs están saliendo rápidamente de las sombras y están siendo reconocidos como el equipo de TI digital que es responsable de crear la siguiente generación de aplicaciones. A menudo este equipo tiene un enfoque y una cultura diferentes, y recluta personas con mentalidad empresarial y habilidades técnicas y no sólo especialistas técnicos. Como tal, el foco del equipo es ganar ingresos y cuota de mercado mediante la utilización de innovaciones rápidas. Sin embargo, las aplicaciones que están creando esas personas representan la imagen pública de la compañía. Por lo tanto, también requieren de conocimientos técnicos sólidos para satisfacer los principales requisitos no funcionales.

Los equipos de TI empresarial y TI digital tienen necesidades de integración. Necesitan integrarse dentro de sus propios dominios y entre ellos. En un nivel alto, esas capacidades de integración híbrida parecen similares, como conectividad, transformación, exposición de la API y composición. Sin embargo, difieren drásticamente en sus detalles.

Conectar la división bimodal

En una arquitectura de referencia simplista para la integración, como en el ejemplo que se muestra en el siguiente diagrama, un equipo central de TI puede realizar la mayoría de la integración. Esencialmente, el equipo conecta la división bimodal dando autoridad a los equipos digitales. Realiza la integración profunda necesaria para sacar a la luz los sistemas de registro como APIs y eventos en el gateway central de la API.

Integrating across bi-modal IT
Integrating across bi-modal IT

Otro aspecto importante pero sutil del diagrama es la afinidad a la nube. Este concepto representa deliberadamente algo continuo en vez de una línea divisoria de la arquitectura. Como se explicó para superficie del área de la integración híbrida, cualquier parte de la arquitectura se puede ubicar en las instalaciones o puede estar totalmente basada en la nube. Los componentes próximos a la parte inferior del diagrama, como los sistemas de registro, tienen másprobabilidad de estar en las instalaciones, pero se puede desplegar cualquier sistema de registro nuevo en una infraestructura en la nube, o incluso puede ser un SaaS. De manera similar, los componentes próximos a la parte superior del diagrama tienen más probabilidad de estar basados en la nube, aunque multitud de organizaciones todavía alojan sus propias aplicaciones de sistemas de compromiso. La realidad de cualquier organización es una mezcla de componentes de dentro y fuera de las instalaciones y, en cualquier caso, toda arquitectura de integración híbrida debe habilitar la conectividad.

Para esta integración central de la empresa, los requisitos son amplios y bien conocidos, siendo las principales preocupaciones:

  • El bajo nivel de conectividad existente entre un amplio rango de formatos de datos, transportes y el protocolo para garantizar la toma de contacto con todos los sistemas de registro que poseen actualmente o que adquieran, independientemente de la antigüedad por diferencia de plataforma.
  • La integridad de los datos mediante la utilización de transacciones para garantizar que los sistemas de registro se mantengan en un estado consistente.
  • La exposición de la API técnica o del servicioa una limitada audiencia de otras aplicaciones que están predominantemente dentro de la organización (incluyendo los orígenes de datos de la TI digital) mediante la utilización de técnicas más modernas, como las RESTful APIs y los servicios web.
  • Los servicios de mensajería empresarial para brindar una entrega garantizada de los datos críticos para la empresa entre los sistemas de multitud de plataformas.

Posteriormente, en este artículo, contrastamos estos requisitos con los de la TI digital, pero primero vamos a considerar cómo se relacionan con iniciativas de integración típicas, como la arquitectura orientada a servicios (SOA).

Algunos podrían equiparar el diagrama de integración bimodal al de SOA, pero con protocolos más modernos para el servicio o la exposición de la API. De hecho, la evolución es más pronunciada desde la SOA inicial. La sofisticación y el propósito del gateway han madurado considerablemente. Los Gateways Modernos de la API están más enfocados en la experiencia del cliente. Brindan portales para que el desarrollador navegue y se suscriba a APIs, analíticas sobre la utilización de la API y modelos modernos de seguridad y gestión del tráfico para un acceso seguro y controlado a las APIs.

Exposición Pública al API

La evolucionada abundancia de mecanismos para suministrar APIs ha llevado a que las empresas exploren la exposición pública de APIs y se unan a la economía de la API. Arquitectónicamente hablando, se puede reconocer esta exposición por el segundo (superior) gateway de la arquitectura, como se muestra en el siguiente diagrama. Esta sección repasa el cómo y el porqué de la diferencia entre los gateways públicos y los internos.

Aunque en esta arquitectura de referencia lógica mostramos dos gateways separados para enfatizar los dos estilos de esta exposición, en algunos escenarios el mismo gateway físico podría brindar esos dos gateways.

Challenges of public API exposure
Challenges of public API exposure

El concepto de sistema de compromiso se refiere generalmente a aplicaciones para el usuario, como aplicaciones móviles y aplicaciones web de página única. Estas aplicaciones abordan los canales digitales modernos con interfaces de usuario adaptables y de alta adherencia que impulsan nuevas oportunidades de ingresos para la empresa. Sin embargo, se puede estar introduciendo un nuevo canal de negocio en forma de APIs accesibles públicamente. Estas APIs se construyen pensando en los desarrolladores externos, con el objetivo de acelerar la innovación mediante nuevos modelos empresariales de colaboración masiva. Aunque son técnicamente similares a las APIs internas, las APIs públicas son radicalmente diferentes en el cómo, el por qué, dónde se crean y quién crea:

  • Cómo. Las APIs se construyen y evolucionan rápidamente según cambian las tendencias del mercado. Como tales, típicamente se construyen en una infraestructura ligera y en paradigmas de diseño, como los microservicios, lo que las permite una gran agilidad y, si tienen éxito, escalabilidad elástica instantánea.
  • Por qué. Las visión más correcta de las APIs públicas debería ser productos para la venta dentro de la economía de la API mediante la utilización de múltiples modelos de financiación. A menudo se diseñan para nichos de clientes, en vez de como interfaces genéricas que lo abarcan todo.
  • Quién. Las APIs públicas a menudo se crean y se mantienen por un equipo de TI diferente que está más enfocado al negocio o al mercado y que está especializado en arquitecturas ligeras.
  • Dónde. Las APIs públicas son susceptibles de ser construidas y desplegadas en la nube para sacar provecho de la rápida aceleración de nuevos entornos y de los modelos de escalado de costos de elasticidad lineal.

Para habilitar técnicamente la exposición de la API pública, se necesitan capacidades más amplias dentro y alrededor del gateway. Por ejemplo, las APIs públicas pueden tener una gestión de tráfico basada en suscripciones más avanzada y robusta. Podrían tener portales digitales a través de los cuales los desarrolladores pueden descubrir y suscribirse a las APIs. También podrían tener modelos de seguridad de Internet (como el OAuth), mayor protección contra amenazas, analíticas más enfocadas en el marketing y un mecanismo de feedback conectado directamente al desarrollador, como los foros de comunidad de soporte.

Necesidades de integración de TI digital

Para que los equipos de TI digital brinden APIs nuevas, cautivadoras y coherentes, necesitan hacer más que simplemente volver a exponer las APIs internas. Necesitan componer las APIs existentes en la compañía y fuera de ella, para proporcionar capacidades que puedan abordar de forma precisa los nuevos canales de mercado. Están mucho menos enfocados en los problemas de integración a bajo nivel de protocolos complicados y plataformas diferentes a los que la TI empresarial se enfrenta. Las aplicaciones y APIs creadas por esos equipos se comunican principalmente mediante la utilización de protocolos que se popularizaron más recientemente, como REST (típicamente JSON/HTTP) que necesitan poco trabajo pesado para su integración. Por lo tanto, se pueden centrar más en añadir funcionalidad.

Una aplicación móvil moderna con éxito atiende a un enorme número de usuarios concurrentes activos, y todos demandan tiempos de respuesta inferiores al segundo. Esta demanda impulsa una necesidad de llevar los datos más cerca del borde de la empresa, en vez de recuperarlos en el momento de la ejecución desde sistemas de registro, que no están diseñados pensando en una baja latencia y en la escalabilidad de un mercado masivo. El resultado es la necesidad de patrones de movimiento de datos, cacheado y patrones de persistencia potencialmente más complejos, como la consistencia eventual.

Los equipos digitales utilizan internamente la comunicación asíncrona ligera para reducir las dependencias directas y brindar mayor resiliencia y escalabilidad. También buscan externamente métodos asíncronos, por ejemplo mediante la utilización de un modelo de comparación entre inserción y extracción para las aplicaciones móviles. Los equipos digitales a menudo utilizan una arquitectura de microservicios para que les ayude a llevar a la vanguardia esos patrones tecnológicos, y con el objetivo de mejorar la agilidad, la escalabilidad y la residencia. Los microservicios y su relación con la integración son demasiado complicados como para describirlos en este artículo. Para una explicación más detallada, vea Microservicios, SOA y APIs: ¿Amigos o enemigos?.

Basándose en la siguiente imagen, cuando profundiza en las necesidades de integración de los equipos digitales, ve la necesidad de algo más que simplemente un gateway que exponga sus APIs. Aunque estas aplicaciones y APIs nuevas se pueden fabricar mediante la utilización de tiempos de ejecución de lenguaje sin procesar, muchos de los desafíos de la composición son patrones de integración ya conocidos, como el mapeo y el enriquecimiento. Por lo tanto, tiene sentido utilizar herramientas e infraestructuras simples para acelerar la implementación de esas APIs.

Adding the integration requirements of the digital                     team
Adding the integration requirements of the digital team

Además del gateway externo para las APIs, los equipos digitales también tienen las siguientes necesidades para la integración:

  • Composición de la API para habilitar la creación de APIs más sofisticadas agregando y componiendo llamadas a APIs que existen tanto dentro como fuera de la mesa.
  • API y descubrimiento de eventos especialmente para descubrir y consumir las capacidades que la TI empresarial expone de la forma más constante posible, independientemente de los límites de la nube.
  • Gestión de asociado dependiente para gestionar sus relaciones con dependencias externas, manejando las suscripciones, conexiones, certificados y credenciales, y gestionando y monitorizando su uso, según corresponda.
  • Mensajería ligera centrada en la aplicación dentro de sus entornos de aplicaciones, con capacidades centradas en Internet, como la escalabilidad elástica, latencia baja, alta capacidad del suscriptor, pero también de forma crítica con la habilidad de conectar con el entorno de mensajería empresarial.
  • Integración del PaaS para la productividad de los equipos digitales. Idealmente, esos equipos quieren eliminar la tarea de construir una plataforma. Prefieren utilizar desde el principio una plataforma ya existente y enfocarse en las funciones de sus aplicaciones y APIs.

Buscar consistencia con flexibilidad

Una arquitectura de integración híbrida debe permitir una integración sin fricciones por toda la empresa, con las siguientes cualidades:

  • Consistente y simple. Integración dentro de los límites de la aplicación de maneras consistentes, qué sólo utilizan los elementos de la integración que necesitan en cada contexto
  • Consciencia híbrida. Capacidades de integración donde se encuentran las aplicaciones, ya sea dentro de las instalaciones, en una infraestructura basada en la nube o dentro de una plataforma
  • Escalabilidad ágil. Agilidad y productividad, con la flexibilidad de aumentar la cobertura a nivel empresarial y la escala en Internet

Conceptualmente, todos deberían sentir la integración de igual manera, incluso aunque las sus necesidades específicas puedan variar. Para conseguir estas demandas que compiten, debe buscar maneras de simplificar el problema.

Como ejemplo, una manera común de lograr la consistencia en la arquitectura es buscar patrones repetitivos y utilizarlos para simplificar la arquitectura. En la arquitectura que se presenta en este artículo, hay un patrón repetitivo que es claramente visible a lo largo del espacio de integración híbrida y consiste de los elementos principales:

  • Exposición, que se representa por un gateway que expone las APIs
  • Implementación, que se representa por un tiempo de ejecución en el que se pueden crear interacciones a bajo nivel

Estos dos elementos se repiten por todo el entorno de la integración en diversos grados, aunque la profundidad y la sofisticación que se requieren para cada uno de estos dos elementos varían según el escenario.

Por ejemplo, en las capas inferiores que se muestran en el siguiente diagrama, cuando se conecta a profundidad a los sistemas de registro existentes, posiblemente necesitará la caja de herramientas de capacidades completa. Ahora, compare esta disposición con las capas superiores del diagrama. Aquí, los equipos digitales que exponen las APIs nuevas basadas en la composición de APIs linternas ya existentes y en bastones externos, podría necesitar sólo el gateway y algunas de las capacidades de composición más ligeras. Para exponer sus APIs y acceder a las APIs internas ya expuestas, los equipos que crean aplicaciones nuevas pueden necesitar poco más que un gateway.

Repeating exposure and implementation across the hybrid                     landscape
Repeating exposure and implementation across the hybrid landscape

Esta visión de la arquitectura brinda una mirada hacia un conjunto de oportunidades para la simplificación mucho más amplio. Al poner como objetivo los elementos de la consistencia, como los mostrados aquí, para realizar la integración fomentamos un patrón común, pero flexible. Simplificamos y racionalizamos la arquitectura sin sacrificar la capacidad. Nuestro objetivo para futuros artículos de developerWorks es explorar aún más esas áreas de consistencia con flexibilidad.

Conclusión

Este artículo ha explorado la evolución de la integración híbrida. Ha explicado cómo la integración híbrida ha extendido los límites de la propiedad de una empresa. Ha definido las principales capacidades de la integración híbrida y el rol y los requisitos de las líneas de negocios. Después, ha demostrado cómo el equipo de TI central conecta la división bimodal, dando autoridad al equipo digital. Ha diferenciado las APIs públicas de las internas. Finalmente, este artículo ha demostrado la importancia de satisfacer las necesidades del equipo digital y garantizar la consistencia con flexibilidad en el entorno híbrido.

En este artículo, hemos evitado deliberadamente hacer referencias a productos de IBM, pero como puede imaginar, tenemos una gran opinión de ellos. Durante lo que resta del 2016, esté atento a las publicaciones del blog de IBM Integration Developer Center que enlazan la arquitectura de referencia a las ofertas de IBM. Estas publicaciones le explicarán cómo nuestros clientes están abordando los desafíos de la integración del mundo real siguiendo esta arquitectura de integración amplia.

Agradecimientos

Gracias a las siguientes personas por su colaboración y por revisar el material de este artículo: Andy Garratt, Peter Broadhurst, Carsten Bornert, Guy Hochstetler y Carlo Marcoli.


Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere, Cloud computing
ArticleID=1035995
ArticleTitle=La envolvente arquitectura de referencias de integración híbrida
publish-date=08162016