Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Cree un modelo de nube teniendo en cuenta la gobernanza y la arquitectura de servicios

Moverse hacia aplicaciones y gobernanza centradas en la nube debe empezar pensando sobre la arquitectura de nube.

Incluso para los pensadores de la nube con los pies más puestos sobre la tierra, se está volviendo obvio que hay más para hacer con esta tecnología que solo infraestructura como servicio. Gigantes como Amazon están creando servicios de plataforma para aumentar el hosting básico, prometiendo construir hacia arriba una arquitectura de aplicaciones completamente centrada en la nube. La pregunta es: ¿Cómo será presentado este nuevo mundo a los usuarios y cómo harán que cumpla con los estándares corporativos y de la industria? La respuesta es: Dándose cuenta de que la nube es su propio ambiente de aplicaciones, no solo un lugar para hospedar una más antigua.

Planificar el movimiento hacia aplicaciones y gobernanza centradas en la nube debería empezar con pensar sobre la arquitectura de nube, no la arquitectura de aplicaciones. Este consejo ofrece apuntes sobre decisiones de arquitectura de nube, la necesidad de repensar qué significa estar orientado a servicios, y el orquestar el cumplimiento en tiempo real.

Las arquitecturas de aplicaciones típicamente se construyen sobre un conjunto estático de herramientas básicas (sistemas de gestión de base de datos o big data, por ejemplo) y componentes enlatados aumentados con componentes autodesarrollados. En la nube, como aún está en desarrollo, este modelo no funciona porque los servicios de plataforma están evolucionando rápidamente, y los proveedores de software tradicional aún están poniéndose de acuerdo con los cambios en el mercado.

Respondiendo a los cambios en el mercado de nube

Todas las aplicaciones deben ser consideradas desde arriba hacia abajo, por supuesto, pero con el nuevo modelo de nube esto es crítico. El objetivo es crear un modelo de experiencia de usuario en la nube que haga lo siguiente:

  • Que empiece con el usuario.
  •  Enlace hacia políticas de presentación que gobiernen cómo es transmitida la información.
  • Se mueva hacia las políticas y funciones específicas para el negocio.
  • Termine con servicios centrales de tecnología genérica o genéricos para la industria.

Este proceso reducirá su riesgo de tener un nuevo servicio de plataforma que sea difícil de integrar con su aplicación en la nube porque el servicio no corresponde con la estructura de componentes del software. Los servicios de nube siempre son consumidos de manera jerárquica, con las especificaciones de usuarios primero y las cosas genéricas al final. De esta forma, los cambios en un extremo no impulsarán adaptaciones complejas en el otro.

Este proceso demanda repensar lo que significa ser orientado a servicios. La mayoría de las composiciones SOA trata los componentes como co iguales porque la mayoría de las aplicaciones SOA consumen herramientas como DBMS como interfaces del programa de aplicaciones (API) dentro de los componentes, en lugar de como los propios componentes. En la nube, es más probable que una API apunte a un componente discreto y remoto o a un servicio de plataforma. El middleware para las aplicaciones de nube también son servicios, y es crítico que sean tratados como tales.

Parte de esta extensión de la noción de arquitecturas orientadas a servicios es considerar a todas las herramientas de las aplicaciones como servicios, lo que significa una revaluación total de lo que es un componente de software y de lo que el flujo de trabajo podrás significar. A medida que las APIs se vuelven enlaces de servicio en la nube, los costos generales de las aplicaciones se incrementa y también hay un emparejamiento dinámico de información a un nivel más profundo del que consideran las prácticas de cumplimiento y gobernanza.

Nadie piensa en hacer una API middleware gobernable: el objetivo es hacer que los componentes y los servicios de la aplicación cumplan las normativas. Eso no es suficiente en la nube porque los flujos de trabajo están expuestos en muchos más niveles.

Una de las consecuencias prácticas de los dos pasos anteriores es la creación de un emparejamiento de elementos de aplicaciones mucho más suelto, y una oportunidad de utilizar esto es personalizar las interacciones de los trabajadores. Las arquitecturas de nube pueden ser más personalizadas, pero esto usualmente demanda un emparejamiento más dinámico de los componentes.

Orquestación por el camino de los metadatos

Las empresas reportan que los diseños de aplicaciones de nube están cambiando drásticamente hacia principios RESTful, y alejándose de los flujos de trabajo o la integración del bus de servicio. Esto significa que las interacciones de los trabajadores con los componentes están probablemente orquestadas a través de metadatos que enlazan los procesos en una secuencia que cada trabajador encuentra óptima. Todos estos metadatos deben ser revisados para el cumplimiento.

La nube es su propio ambiente de aplicaciones, no solo un lugar para hospedar una antigua.

Esto podría no ser tan difícil como parece si se toma un verdadero enfoque de arquitectura de nube. Si todas las interacciones de trabajadores están modelados por metadatos y orquestados, los procesos de cumplimiento solo necesitan estos modelos para revisar cómo se está utilizando y distribuyendo la información.

Para estar seguros, hay muchos más puntos de orquestación de lo que habían buses de servicio en los flujos de trabajo SOA tradicionales. Sin embargo, estos flujos de trabajo tradicionales están típicamente descritos por el Lenguaje de Ejecución de Procesos de Negocio (BPEL) que tiene que ser descodificado y evaluado por cumplimiento y gobernanza. Se emparejan al final, y el modelo de nube es más personalizable, haciendo de él una mejor opción para optimizar la productividad del trabajador.

Otro interesante punto sobre la orquestación vía metadatos es que las descripciones de metadatos de las relaciones de servicio específicas de los trabajadores en una aplicación pueden ser fácilmente expandidas para incluir enlaces de cumplimiento y gobernanza. Cosas como persistencia de los datos pueden ser incluidos en la orquestación de metadatos, de modo que se puede imponer una auditoría de ruta de cambios y actividades sobre un proceso. Esto es facilitado por el hecho de que la arquitectura de nube promueve una más profunda componentización y hace visibles a las aplicaciones de gobernanza incluso los servicios middleware.

Detalles de las aplicaciones de nube

En las aplicaciones específicas para la nube del futuro, es casi seguro que la gobernanza basada en BPEL u otros marcos SOA podría ser menos efectiva o incluso inefectiva. La orquestación de servicios basada en metadatos demandará nuevas prácticas y quizás incluso nuevas herramientas. Cada vez que las aplicaciones son estructuradas en componentes, es necesario co orquestar datos y elementos de procesos.

La dependencia de la nube en los metadatos para describir flujos de trabajo significa que esta orquestación deberá ser increíblemente efectiva. Los usuarios de nube tendrán que explorar la orquestación de servicios, la organización de datos y los mapeos de datos a servicios para seguridad que el cumplimiento y el desempeño de las aplicaciones no varía de manera inaceptable, dependiendo de dónde residen los componentes en la nube.

Finalmente, los contratos de nube necesitan ser revisados a medida que se produce la transición de arquitecturas de aplicaciones hacia arquitecturas de nube. Cada servicio de plataforma consumido y cada API que se vuelve un flujo de trabajo debe ser asegurado y auditado apropiadamente, pasos estos que nunca se toman para elementos de middleware.

Estos servicios y flujos son internos al proveedor de nube, así que la información necesaria sobre esto y el acceso a estos elementos por temas de cumplimiento y seguridad deberán ser garantizados por el contrato de servicio en la nube. Si falla en hacer esto será mucho más difícil sacar todo el provecho del movimiento hacia la nube.

Acerca del autor: Tom Nolle es presidente de CIMI Corp., una firma de consultoría estratégica especializada en telecomunicaciones y comunicaciones de datos desde 1982.

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

Profundice más

PRO+

Contenido

Encuentre más contenido PRO+ y otras ofertas exclusivas para miembros, aquí.

Inicie la conversación

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

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close