Contenido


Gestión de Requisitos No Funcionales para Aplicaciones en la Nube

Patrones de diseño de software para entornos de PaaS

Comments

Incluso las aplicaciones innovadoras y eficaces pueden sufrir interrupciones o fallar en el mercado porque no cumplen NFR como rendimiento, tiempo de respuesta y confiabilidad general. Tradicionalmente, los arquitectos responden a los NFR modificando la forma o el tamaño de la infraestructura. El número de usuarios simultáneos se maneja al dividir las sesiones de usuario en múltiples sistemas que se ejecutan en paralelo; los tiempos de respuesta se mejoran al eliminar los cuellos de botella de rendimiento (a menudo, en el uso de la base de datos o almacenamiento); los requisitos de servicio se satisfacen al añadir nuevos dispositivos capaces de realizar un registro cronológico rápido y de gran volumen, etc. Pero en entornos en la nube, el número de opciones disponibles para que el arquitecto gestione los NFR es más limitado.

Las plataformas en la nube de Infraestructura como servicio (IaaS) hacen que las modificaciones a la infraestructura sean económicas y fáciles— lo que explica la popularidad de los entornos de IaaS para cargas de trabajo con cambios y aumentos rápidos— y las opciones del arquitecto se reducen en consecuencia. Los entornos en la nube de Plataforma como servicio (PaaS) llevan este paradigma un paso más allá al eliminar la escala horizontal, la colocación de componentes, el registro cronológico y la gestión del sistema del alcance del arquitecto. Estas operaciones ocurren, pero el arquitecto de TI no tiene ningún control (o casi ningún control) sobre ellas.

Sin embargo, la gestión de los NFR por parte del arquitecto no desaparece en los entornos en la nube. Al contrario, se transfiere a los mecanismos internos de las aplicaciones y se traduce en un número de patrones de diseño de aplicación. La implementación de esos patrones garantiza que las aplicaciones en la nube sean "buenas ciudadanas" del entorno operativo en la nube (CloudOE)— que no interfieran con el mecanismo del CloudOE y estén alineadas a la forma de trabajar del CloudOE. Este artículo describe los patrones y los tipos de NFR abordados en entornos de PaaS. Además, le presentamos a IBM® IBM Cloud™, un entorno operativo en la nube de PaaS con estándares abiertos en donde puede poner a funcionar los patrones de diseño.

NFR y casos de tensión

Los requisitos funcionales y no funcionales no son distintos conceptualmente. Ambos expresan motivaciones de los participantes, o personas influyentes, del sistema bajo definición. Con la evolución de la tecnología y roles de TI, los sistemas de software continuamente aumentan el número de participantes y la complejidad de sus solicitudes. Además de los usuarios del sistema, los participantes y sus respectivos requisitos incluyen:

  • Desarrolladores: estructura y claridad del código
  • Mantenedores: Herramientas de documentación y depuración
  • Evaluadores: Herramientas proporcionadas de rastreo y determinación de otros problemas
  • Proveedores: Facilidad de abordar la aplicación
  • Operadores: Nivel de información proporcionado
  • Gerentes de operaciones: Escalabilidad de la solución
  • Especialistas de gestión de la configuración: Embalaje y el nivel de middleware soportado
  • Administradores de base de datos: uso del recurso de base de datos y optimización
  • Gerentes de servicios: Capacidad y esfuerzo necesarios para monitorear las operaciones
  • Especialistas de gestión de sistema y red: herramientas soportadas
  • Arquitectos empresariales: Conformidad con las arquitecturas estándar de la compañía
  • Responsable de seguridad: El tipo de seguridad implementado
  • Adquirentes: Escalabilidad y adaptabilidad de la solución
  • Asesores: Herramientas de auditoría
  • Miembros del equipo de soporte: Complejidad de las operaciones del usuario
  • Comunicadores: Claridad de las interfaces

Esta situación representa sistemas complejos con requisitos funcionales difíciles y NFR exigentes, como alta disponibilidad, rendimiento rápido y requisitos de seguridad desafiantes. La computación en nube añade la necesidad de flexibilidad extrema y dispersión geográfica — disponibilidad en cualquier momento y en cualquier lugar.

¿Cómo el arquitecto de TI garantiza que la arquitectura del sistema abarca de manera satisfactoria todos estos requisitos? El peligro reside en que los requisitos se abordan de manera aislada, sin pensar en cómo resolver un requisito podría afectar a los demás.

Para empezar a pensar acerca de los requisitos de una manera integral, puede imaginarlos como "fuerzas" opuestas, como muestra la Figura 1. La solución de TI puede ser una forma de resolver esas fuerzas de una manera óptima.

Figura 1. Requisitos como fuerzas opuestas

En la Figura 1, las fuerzas son:

  • Los requisitos funcionales
  • Las cualidades y restricciones (los NFR) que le imponemos al sistema de TI:
    • Cualidades de tiempo de ejecución
    • Cualidades sin tiempo de ejecución
    • Restricciones empresariales
    • Restricciones de tecnología

Las combinaciones de fuerzas opuestas que pueden operar juntas en cualquier momento son especialmente significativas. Además, algunas de estas fuerzas simultáneas también se refuerzan mutuamente. Eso quiere decir que sus efectos aumentan la tensión en partes específicas del sistema. Por ejemplo, un alto número de usuarios simultáneos combinado con un tiempo corto de recuperación luego de un error puede estresar el subsistema de identificación de usuarios después de una falla del sistema, al punto de poder desbordarse y bloquear las operaciones. De manera similar, un tiempo de respuesta ambicioso y una base de datos con recursos limitados podrían, juntos, hacer una combinación de solicitudes que no se pueden completar, a menos que la aplicación esté diseñada específicamente para manejarlas (al utilizar un mecanismo de memoria caché, por ejemplo). Como en la ingeniería civil, utilizamos el término casos de tensión para identificar estos conjuntos de fuerzas simultáneas que se refuerzan mutuamente.

Los acuerdos de nivel de servicio (SLA) del proveedor de la nube están entre los requisitos (restricciones) de la solución y pueden contribuir con los casos de tensión. Por ejemplo, si el contrato de IaaS especifica redes virtuales de cierta capacidad, esta posible restricción del rendimiento interno de la aplicación hospedada podría exigir mecanismos específicos para alcanzar objetivos externos de rendimiento.

A veces, un caso de tensión puede hacer imposible satisfacer todos los requisitos de manera simultánea. En esas situaciones, podría ser necesario conformarse con un conjunto de requisitos más limitado para mantener un nivel de servicio razonable para el usuario. Nos referimos a tales casos como operaciones degradadas. Las operaciones degradadas podrían ser inevitables en una aplicación en nube, así que es importante diseñarlas cuidadosamente y comunicarse con los usuarios cuando estas ocurran.

Un ejemplo sencillo y extendido de una operación degradada se refiere al mecanismo de consistencia eventual de bases de datos fragmentadas.Estas bases de datos ofrecen múltiples instancias de lectura en la nube para rendimiento y confiabilidad, aunque — para mantener la consistencia de escritura — la escritura de un elemento de datos en particular siempre se realiza en la misma instancia. Como la réplica de los nuevos datos tarda un tiempo finito, la información en una determinada instancia de base de datos podría no ser consistente cuando se lee; solo eseventualmente consistente. Una aplicación que utiliza datos eventualmente consistentes debe ser capaz de soportar operaciones degradadas— al minimizar las inconsistencias percibidas por el usuario (por ejemplo, al mostrar actualizaciones que todavía están en el almacenamiento intermedio y no están confirmadas) o (si no hay datos en curso disponibles) alertándole al usuario cuando se actualizó la base de datos por última vez.

Un ejemplo

Para ayudar a explicar cómo manejar los NFR en un entorno CloudOE de PaaS, desarrollaremos un ejemplo en función de la empresa de nube ficticia AMGRO, un minorista que vende sus productos a través de una red de vendedores independientes de medio tiempo que reciben comisiones.

AMGRO decidió impulsar el mercado de ventas online al brindar una aplicación de compras por catálogo. Para acelerar el despliegue, AMGRO planea desarrollar la aplicación en el entorno de PaaS de un proveedor de nube (que proporcionará la IU de la web, servicios de seguridad y control de acceso) y vincularla a los servicios online de los líderes del mercado en servicios de entrega y servicios de pago. La nueva aplicación también debe integrarse a la plataforma existente de planificación de recursos empresariales (ERP) de AMGRO, para la gestión de contabilidad y almacenes.

Los NFR de AMGRO para esta nueva aplicación son:

  • Se espera que el número de usuarios simultáneos sea de aproximadamente 10.000.
  • Se espera que todas las visualizaciones de catálogo tarden menos de un segundo en una línea regular de ADSL o en una red de celular de alta velocidad.
  • Se espera que el entorno en nube de AMGRO y los servicios de pago funcionen las 24 horas del día, los 7 días de la semana.
  • AMGRO y el proveedor de entrega están conectados en Internet regular.

La respuesta a una solicitud al servicio de entrega tiene un SLA confirmado de dos horas. Además, el servicio de entrega tiene un objetivo de disponibilidad que varía en la noche, cuando realiza el mantenimiento del sistema. Por razones contractuales, este SLA no debe cambiar.

Como la nueva aplicación de PaaS interactuará con el sistema ERP de AMGRO, esta interfaz es altamente sensible y se debe proteger de manera adecuada.

La Figura 2 muestra el ejemplo de AMGRO. (Esta y la mayoría de las próximas figuras de este artículo están en notación TOGAF ArchiMate ).

Figura 2. El ejemplo de AMGRO

En el sistema de AMGRO, las siguientes combinaciones de NFR están vinculadas para ser casos de tensión:

Caso 1: Tiempo de respuesta en menos de un segundo, pero el sistema cargado:

  • 10.000 usuarios simultáneos
  • Tiempo de respuesta en menos de un segundo

Caso 2: Tiempo de respuesta en menos de un segundo, pero sistemas externos lentos o no confiables:

  • Tiempo de respuesta en menos de un segundo
  • Conexión a entrega y pago a través de Internet regular

Caso 3: La aplicación debe estar disponible pero los sistemas externos son asíncronos o no coinciden con el SLA:

  • Disponibilidad 24 horas por día, 7 días de la semana
  • Conexión a Internet
  • Falta de coincidencia con la disponibilidad del SLA
  • Proceso fuera de línea

Caso 4: Nube híbrida:

  • Conexión segura

Aplicaciones de PaaS, NFR y el rol del arquitecto

Una solución de PaaS basada en un entorno operativo en la nube aprovecha el modelo de programación CloudOE para gestionar NFR, lo que libera la aplicación de algunas tareas:

  • Gestión de cargas del usuario a través de la escalabilidad horizontal: CloudOE escala al añadir y retirar instancias de componentes en máquinas virtuales en función de la carga de trabajo. El arquitecto de la aplicación ya no debe lidiar con la escalabilidad pero, ahora, debe entender qué componentes deben escalarse de manera sincronizada y cómo gestionar distintos niveles de escala entre los componentes que se comunican.
  • Aprovechar la tecnología más reciente para la ruta crítica: En una solución interna, el arquitecto aprovecha la tecnología más reciente en las partes críticas del sistema (la base de datos, el eje central de mensajería, etc.). En la computación en nube, usted utiliza tecnología estándar y posee un número limitado de opciones básicas. Se eliminan las discrepancias por la tecnología de hardware o software, pero la ruta crítica se debe manejar con un patrón de diseño.
  • Eliminación de cuellos de botella de rendimiento por ubicación conjunta : Colocar artefactos con alto grado de interacción uno al lado del otro es una práctica común para mejorar el rendimiento. También puede hacerlo para partes de aplicación en un CloudOE (asumiendo que esta unión no interfiere en la escalabilidad horizontal), pero tal vez no pueda controlar la ubicación conjunta de aplicaciones y servicios técnicos que poseen varias copias distribuidas (MongoDB, por ejemplo).
  • Controlar los SLA : En un CloudOE, ninguna aplicación es una isla. Los componentes involucrados pueden estar en cualquier lugar con el objetivo de mejorar la confiabilidad general del sistema. Por otra parte, los SLA confirmados por el proveedor de nube local (a la aplicación) podrían no ser los mismos que los confirmados por otro componente conectado en una plataforma en nube distinta. El arquitecto de la aplicación no puede suponer que los SLA son uniformes y debe considerar la posibilidad de respuestas faltantes o retrasadas.

Patrones de gestión de NFR en PaaS

Si dibujáramos el diagrama de contexto operativo de una aplicación de PaaS, podríamos identificar cuatro tipos de actores externos:

  • Usuarios de la misma aplicación (consumidores de los servicios de la aplicación): Estos actores generalmente tienen requisitos relacionados al tiempo de respuesta y disponibilidad de la aplicación. Además, una aplicación en nube típica a menudo tiene cargas impredecibles debido al número variable de usuarios simultáneos.
  • Sistemas externos: Son sistemas físicos externos a la nube que no están bajo el control del arquitecto de la aplicación.
  • Servicios impulsados por eventos: Algunos servicios podrían implementar procesos prolongados o una interfaz asíncrona.
  • Sistemas internos (servicios híbridos): Tanto componentes de la nube como componentes internos de un sistema interno están bajo el control del arquitecto de la aplicación, quien, por lo tanto, puede ajustarlos según los NFR.

Con relación a los cuatro actores de PaaS, hemos identificado cuatro patrones de diseño relacionados a los NFR:

  • Un patrón de aplicación sin estado para gestionar la escalabilidad del número de usuarios, la alta disponibilidad y el soporte para tiempos de respuesta cortos incluso cuando el sistema está cargado.
  • Un patrón de aplicación asíncrona para gestionar el tiempo de respuesta y la disponibilidad continua cuando se necesitan servicios prolongados para participar en el proceso de aplicaciones.
  • Un patrón de API externa para gestionar la alta disponibilidad y la escalabilidad cuando el flujo del proceso involucra sistemas externos.
  • Un patrón de VPN segura para integrar de manera segura sistemas internos.

La Figura 3 muestra los cuatro patrones y su relación con los cuatro actores.

Figura 3. Patrones de PaaS

Patrón de aplicación sin estado

El objetivo del patrón de aplicación sin estado es garantizar que el sistema pueda, de manera simultánea, escalar para atender a un gran número de solicitudes y mantener la mínima longitud de ruta de ejecución. La Figura 4 ilustra el patrón de aplicación sin estado.

Figura 4. Patrón de aplicación sin estado

El mecanismo básico utilizado es la capacidad de escalabilidad horizontal de CloudOE. La escalabilidad horizontal es proporcionada por el cierre y apertura dinámico de las instancias del entorno de ejecución y por un componente de enrutador/equilibrio a nivel del sistema.

Para utilizar la escalabilidad dinámica de manera eficaz, los componentes de la aplicación deben estar completamente sin estado. Generalmente, en una aplicación web tradicional, todas las solicitudes realizadas por un determinado usuario se enrutan a la misma instancia del servidor de aplicaciones, que mantiene los datos de la sesión y el estatus de la conversación en la memoria. Un cookie de sesión se utiliza como una clave para recuperar datos de sesión de la memoria y manejar la solicitud. En la computación en nube, la mayoría de las implementaciones de nube del host no garantizan que la misma instancia de aplicación atenderá la sesión. El enrutador dirigido a Internet podría enrutar las solicitudes de sesión a distintas instancias de aplicación. Por lo tanto, en este patrón, para mantener las instancias de ejecución completamente sin estado, el almacenamiento de memoria utilizado es externo y compartido como un servicio entre todas las instancias proporcionadas por la nube que funge como host. (De lo contrario, no sería posible reducir la escala hasta que todas las sesiones de una determinada instancia estén cerradas).

Patrón de aplicación asíncrona

El patrón de aplicación asíncrona se utiliza para la parte impulsada por eventos de la solución y, en general, cuando no es posible ni prevista una respuesta síncrona. La Figura 5 muestra el patrón.

Figura 5. El patrón de aplicación asíncrona

El patrón consta de una agrupación de servicios empresariales asíncronos sin estado (también conocidos comotrabajadores) que llevan los trabajos de una fila, los ejecutan y guardan los resultados en una base de datos (SQL o NoSQL) para que sean consumidos por uno de los demás patrones (por ejemplo, el patrón de aplicación sin estado). Un trabajo es un conjunto de comandos y contexto autocontenido con el cual otro patrón se comunica con el trabajador. Una aplicación frontal normalmente coloca los trabajos en filas. Los resultados de los procesos se almacenan en una base de datos para que la aplicación frontal evite escanear filas o esperar el ID de correlación de la fila.

Pueden existir múltiples tipos de trabajadores, múltiples tipos de trabajos y múltiples filas, cada uno con una determinada especialización. Por ello, con distintas filas, se puede utilizar el patrón para hacer cumplir la secuencia correcta de un conjunto de actividades. La base de datos preferida es una base de datos eventualmente consistente que pueda tener una réplica local, al menos para operaciones de lectura. Las bases de datos de SQL con una única instancia se utilizan solo cuando la característica de ACID (atomicidad, consistencia, aislamiento, durabilidad) es importante — por ejemplo, para operaciones de transferencia de información como operaciones de débito-crédito en cuentas bancarias.

Patrón de API externa

El patrón de API externa es útil cuando debe integrar un sistema externo (fuera del CloudOE)— por ejemplo, una aplicación basada en IaaS— en su solución de PaaS. En ese caso, puede suponer que el sistema externo tiene un SLA publicado en el cual, generalmente, puede confiar— "generalmente", porque el objetivo exacto del patrón es proteger su aplicación de cualquier "falla de ejecución" que pueda tener la aplicación externa. La Figura 6 muestra este patrón.

Figura 6. Patrón de API externa

El patrón es soportado por la memoria caché de los datos en curso entre las instancias de la API que atiende a sus (y de los demás) aplicaciones. Para tomar un ejemplo del escenario de AMGRO, los intentos de pago y confirmaciones recibidas del servicio de pago externo en las últimas 24 horas se pueden enviar a la memoria caché, así que no hay necesidad de acceder al servicio externo si el usuario de la nube AMGRO solicita una lista de los últimos pagos realizados.

Las API de servicios públicos generalmente ayudan a los clientes con la implementación de mecanismos de memoria caché al completar encabezados de respuesta de HTTP estándar: Cache-Control, Expiresy ETag. Por ejemplo, con este encabezado, no se recibirá contenido renovado hasta el jueves 30 de agosto de 2014 a las 14:56:34 GMT:

 Cache-Control: public Expires: Thu, 30 Aug 2014 14:56:34 GMT

Con este encabezado, el contenido recibido se envía a la memoria caché durante 868 segundos antes de que se realice otra solicitud de API:

Cache-Control: max-age=868

Patrón de VPN segura

El patrón de VPN segura, mostrado en la Figura 7, es una variación del patrón de API externa. El patrón de VPN segura tiene el objetivo de cubrir la necesidad, generalmente de aplicaciones de nube híbridas, de integrarse en la nube con componentes internos (por ejemplo, un sistema de registros existente, como se describe en "Diseño de un ecosistema SoE para soportar experiencias de usuario ricas").

Figura 7. Patrón de VPN segura

La suposición por detrás de este patrón es que usted puede controlar ambos entornos y, por lo tanto, regir los SLA acumulativos mejor que en el patrón de API externa.

La parte interna del sistema dependerá de patrones de arquitectura tradicional, como agrupación en clúster, para garantizar la escalabilidad y la disponibilidad (esto es verdadero para soluciones de metal expuesto e IaaS). El único complemento notable del lado de la nube es la introducción de los datos en curso en la memoria caché (para reducir el flujo de comunicaciones a través de un canal de VPN de alta sobrecarga).

El canal de VPN es el corazón del patrón, ya que establece una comunicación confiable entre las dos partes de la aplicación. Por este motivo, además del firewall de CloudOE estándar, la aplicación de PaaS utiliza un recurso de VPN de software, proporcionado como un servicio por el CloudOE, y lo corresponde a un recurso similar (hardware o software) del lado interno.

Patrón de base de datos con consistencia eventual y ACID

El hecho de que el CloudOE ofrezca tanto servicios de base de datos SQL ACID como servicios de base de datos con consistencia eventual distinta a SQL no es, hablando de manera estricta, un patrón de diseño. Pero lo incluimos aquí porque esta flexibilidad es importante para el arquitecto de PaaS. La Figura 8 muestra este recurso de PaaS.

Figura 8. Bases de datos con consistencia eventual y ACID

Las bases de datos SQL garantizan que las operaciones se realicen en un orden secuencial, independientemente de cuántos usuarios estén utilizando el servicio. Esto se hace cumplir a través del bloqueo de recursos, para que no puedan ocurrir actualizaciones conflictivas. Una lectura devuelve el último valor de un campo o el penúltimo (y, generalmente, el usuario puede personalizar el comportamiento deseado). En el lado negativo, el mecanismo de bloqueo limita el número de instancias activas (ya que múltiples réplicas de cualquiera a cualquiera se vuelven inmanejables rápidamente) o exige una base de datos con una única tabla de bloqueo central— un único punto de falla para todo el sistema.

Una base de datos distinta a SQL, como MongoDB, posee las mismas reglas para escrituras locales pero, luego, replica esas escritas en múltiples copias distribuidas. Si una copia falla, las otras se encargan de sus clientes. La réplica no puede ser inmediata, así que una operación de lectura en una de las copias podría devolver un valor n antes del último. Las copias serán consistentes eventualmente, pero no sabemos exactamente cuándo. La consistencia eventual es un mecanismo poderoso de escalabilidad para datos con baja volatilidad, porque las lecturas locales son mucho más rápidas que las remotas. Por ejemplo, los resultados de los trabajadores (que generalmente se escriben una vez y nunca se actualizan) son buenos candidatos para ingresar a una base de datos eventualmente consistente. En cambio, algunos (si no la mayoría) de los datos con alta volatilidad exigen las propiedades ACID de una base de datos SQL.

IBM Cloud: Un CloudOE de PaaS

Una medida del éxito de CloudOE es su habilidad de ayudar a los desarrolladores de primera línea a escribir rápidamente aplicaciones ágiles que tienen el objetivo de validar ideas empresariales. Le daremos un vistazo al CloudOE de IBM (IBM Cloud) como ejemplo y exploraremos las características de IBM Cloud que facilitan el desarrollo de aplicacionescon capacidad de respuesta, escalables, con alta disponibilidad, altamente confiablesy seguras .

IBM Cloud está construido basado en la tecnología Cloud Foundry PaaS de fuente abierta, de la cual heredó conceptos clave comoaplicación, servicio, organización, espacioy buildpack. No se preocupe si no tiene familiaridad con estos conceptos. Llegaremos a ese punto con la ayuda del diseño macro de una aplicación típica centrada en la nube, que se muestra en la Figura 9.

Figura 9. Una aplicación de PaaS

Utilizamos el término aplicación centrada en la nube para referirnos a un sistema planeado y diseñado para ejecutarse en un CloudOE. Tal sistema les ofrece valor a los usuarios a través de un GUI que se puede acceder por la web (aplicación web de presentación en la Figura 2). También puede proporcionar servicio a los otros sistemas, en ese caso usted podría considerar útil diseñar otra aplicación web (Aplicación web de servicios de aplicación en la Figura 2) con una interfaz de Transferencia de estado de representación (REST)/Notación de objetos de JavaScript (JSON) — REST/JSON son más adecuadas que páginas HTML para la integración del sistema. Un tercer elemento que deseará ofrecer en su sistema es una aplicación trabajadora que se encarga de desvincular de manera asíncrona las aplicaciones frontales de los procesos de backend que, de otra manera, degradarían la experiencia del usuario.

La aplicación de presentación, la aplicación de servicios de aplicación y la aplicación trabajadora son aplicaciones de IBM Cloud: aplicaciones web que se pueden acceder a través del protocolo HTTP y que se escriben en cualquier lenguaje e infraestructuras de desarrollo web soportados por IBM Cloud (que incluyen Java/Liberty, Node.js/Express y Ruby/Sinatra).

Si una aplicación trabajadora— como la de la Figura 2— no ofrece servicios web, usted sencillamente no asocie una ruta HTTP a ella, para que no se pueda acceder desde la red. Sin embargo, si utiliza una API trabajadora para consultar y controlar la aplicación trabajadora, en ese caso, no eliminaría la ruta HTTP que IBM Cloud configura de manera automática al desplegar la trabajadora en la nube.

Las aplicaciones implementan la lógica de su sistema. Su equipo de desarrollo escribe el código. Y usted no se debe preocupar por desplegar y configurar el tiempo de ejecución (Liberty, Node Express); IBM Cloud lo hace por usted. El único punto que nunca debe olvidar al diseñar su sistema es que las aplicaciones deben seguir lametodología de doce factores para que sean sin estado.

¿Por qué sin estado?

La falta de estado es esencial para una aplicación centrada en nube debido a un par de comportamientos que exhibe IBM Cloud: este reinicia automáticamente los nodos de la aplicación (las instancias de la aplicación) si se cuelgan. Y puede ejecutar más instancias de la misma aplicación de manera simultánea, cada una en su propio contenedor, colocándolas detrás de un enrutador orientado a Internet que equilibra el tráfico. Esos comportamientos hacen que sus aplicaciones sean confiables, con alta disponibilidady escalables.

Las aplicaciones de IBM Cloud funcionan bien si su código no mantiene localmente ningún dato de configuración o datos empresariales. El sistema local de archivos es efímero; no sobrevive al reinicio de una instancia de la aplicación. Entonces, ¿dónde debe mantener sus datos? Las palabras mágicas son servicio y entorno: Los datos de configuración de origen del entorno de la aplicación, proporcionados por IBM Cloud al inicio de cada instancia de aplicación, aprovechan los servicios administrados de IBM Cloud para almacenar los datos empresariales.

Los servicios son recursos de middleware que la aplicación consume en la red: por ejemplo, almacenes de datos (como un servicio de base de datos SQL [SQLDB] o MongoDB), sistemas de mensajería/filas (como IBM Elastic MQ (ElasticMQ) o RabbitMQ) y sistemas de memoria caché (como IBM DataCache o memcached). IBM Cloud gestiona totalmente los servicios que brinda, así que no tiene que suministrar ni gestionar (monitorear y respaldar) su almacén de datos. Y IBM Cloud le proporciona las herramientas (línea de comando, IU de la web, plug-ins IDE) para solicitar una instancia del servicio; además de una API cliente para utilizar la instancia en sus aplicaciones.

Servicios de datos, mensajería/filas y memoria caché distribuida

Ahora que ya entiende el rol de los servicios en CloudOE, volvamos a los tres servicios base en laFigura 9 que necesita para construir una aplicación centrada en la nube: mensajería/filas, almacén de datos y memoria caché distribuida.

Podría necesitar un servicio de memoria caché distribuida para mejorar el tiempo de respuesta de la aplicación de presentación al enviar a la memoria caché solicitudes frecuentes de los usuarios. La memoria caché distribuida también tiene la ventaja de descargar las capas de servicios de aplicación y servicio de datos. Otro caso de uso de la aplicación de presentación que usa el servicio de memoria caché distribuida es almacenar los datos de sesión HTTP del usuario que se deben compartir entre las instancias de la aplicación. Entonces, el servicio de memoria caché distribuida ayuda a los desarrolladores a construir sistemas con capacidad de respuesta.

El servicio de cola de mensajes ayuda a mejorar el rendimiento de aplicaciones centradas en la nube. Este servicio se utiliza en el patrón deaplicación asíncrona para prevenir que las capas de servicios de la aplicación y de la presentación realicen tareas potencialmente lentas que impactarían de manera negativa en la experiencia del usuario. Siempre que tenga que realizar tal tarea en la capa de servicios de la aplicación o de la presentación, utilice el servicio de cola de mensajes para delegarle la tarea a la aplicación trabajadora. La aplicación trabajadora captura la tarea y la ejecuta a su propio ritmo. Se le notifica al usuario de manera asíncrona acerca del resultado de la operación.

Generalmente, la elaboración de una tarea implica la actualización de una base de datos empresarial. CloudOE proporciona servicios de datos para este propósito. La Figura 9 muestra un servicio de datos (SQL) relacional, pero usted también puede utilizar servicios de datos basados en documentos o clave/valor (distinto a SQL) proporcionados por CloudOE.

Uso de los servicios en IBM Cloud

Usar los servicios en IBM Cloud es bastante sencillo. Usted suministra una instancia (operación crear ), la asocia a la aplicación que la necesita (operación vincular ) y empieza el código. El almacén de IBM Cloud lista los servicios disponibles; cada servicio proporciona documentación y código de muestra que puede utilizar para empezar el código. Se puede acceder a todos los servicios a través de la red con la API de REST. Los URL de punto final de la API y las credenciales para utilizar el servicio se ponen a disposición para vincular las aplicaciones a la variable de entornoVCAP_SERVICES .

Veamos el servicio IBM Cloud DataCache como ejemplo. IBM realiza la tecnología subyacente en el appliance IBM WebSphere® DataPower® XC10 disponible como un servicio de IBM Cloud para enviar a la memoria caché pares de datos clave/valor. Al crear un servicio DataCache y vincularlo a una aplicación, IBM Cloud suministra una cuadrícula y un conjunto de credenciales que usted utiliza para enviar a la memoria caché y recuperar datos. La definición de VCAP_SERVICES es similar al Listado 1.

Listado 1. VCAP_SERVICES definición.
 VCAP_SERVICES= { "DataCache-0.1":[ { "name":"DataCache-8acb7", "label":"DataCache-0.1", "tags":[], "plan":"free", "credentials":{ "catalogEndPoint":"75.126.158.85:2809", "restResource":"http://75.126.158.85/resources/datacaches/S5D22GP5TOisTeszePBbpAWU", "restResourceSecure":"https://75.126.158.85/resources/datacaches/S5D22GP5TOisTeszePBbpAWU", "gridName":"S5D22GP5TOisTeszePBbpAWU", "username":"MKzIkp36RpKBWZP9FmXZHgFJ", "password":"lyk7FzsNR66pBm7kWlTAvwHP" } } ] }

Supongamos que está escribiendo una aplicación de Node.js. Para enviar a la memoria caché un par clave/valor utilizando la API de REST, debe seguir tres pasos:

  1. Inicializar algunas variables ayudantes:
     var vcap_services = JSON.parse(process.env.VCAP_SERVICES); var credentials = vcap_services['DataCache-0.1'][0]['credentials']; var auth = 'Basic ' + new Buffer(credentials.username + ':' + credentials.password).toString('base64'); var parsedUrl = url.parse(credentials.restResource);
  2. Preparar la solicitud de PUBLICACIÓN de HTTP para enviar a la memoria caché el par clave/valor, como muestra el Listado 2.
    Listado 2. Preparación de la solicitud de PUBLICACIÓN para enviar a la memoria caché
     var post_options = { hostname: parsedUrl.hostname, path: parsedUrl.pathname + '/'+ credentials.gridName + '/' + encodeURIComponent(key), method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': auth } }; var post_req = http.request(post_options, function(res) { // Handle response callback res.setEncoding('utf8'); var msg = ''; // Store text message sent by the server res.on('data', function (chunk) { msg += chunk; }); res.on('end',function() { if ( res.statusCode != 200 ) { console.log('Error while caching key. Status: %d. Message: %s', res.statusCode, msg); // Add error handling code here } else { // OK, key/value cached! } }); });
  3. Escriba el valor y envíe la solicitud:
     post_req.write(JSON.stringify(value)); post_req.end();

Capas en una aplicación de PaaS

En una aplicación web común, es probable que encuentre una jerarquía de componentes de la aplicación, organizados en capas:

  • Componentes de presentación que gestionan la interacción con los usuarios de la aplicación
  • Componentes de gestor de proceso que gestionan los flujos de trabajo de actividades que cumplen los casos de uso de la aplicación
  • Componentes de servicio de la aplicación que manejan las entidades de información y los servicios en el núcleo de la aplicación
  • Componentes técnicos que ocultan la tecnología fundamental de las capas superiores
  • Componentes de middleware externos a la aplicación

Como muestra la Figura 10, esta estructura aún es válida en gran medida para una aplicación de PaaS. La aplicación web de presentación de la aplicación de PaaS funde los roles de la presentación tradicional y los roles de gestor de proceso en un único componente a fin de maximizar la experiencia del usuario para los dispositivos e interacciones del usuario relevantes.

Figura 10. Capas en una aplicación de PaaS en comparación con una aplicación web tradicional

Los servicios de aplicación y componentes trabajadores de CloudOE que identificamos en la sección IBM Cloud: Un CloudOE de PaaS se pueden clasificar como servicios de aplicación, con la aplicación trabajadora especializada para servicios asíncronos. Para abordar los NFR estrictos de una aplicación en nube, podría valer la pena identificar todos los casos de uso que se pueden resolver con una interacción asíncrona; utilícelos para identificar los componentes trabajadores y mantener la ruta de ejecución de la lógica de la aplicación lo más corta posible.

Cada uno de los servicios de middleware ofrecidos por el CloudOE comprende al menos un componente técnico. En general, las aplicaciones en la nube utilizan capas no estrictas, para que tanto la aplicación de presentación como los servicios de aplicación puedan utilizar componentes técnicos.

Conclusión

Tradicionalmente, los arquitectos han abordado las condiciones de tensión impuestas por los requisitos no funcionales en un nuevo sistema adaptando la infraestructura del sistema y la arquitectura técnica. La nube libera a los arquitectos de esta tarea, pero les exige que garanticen que las aplicaciones se comporten como "buenas ciudadanas" del entorno operativo de la nube. Los patrones presentados en este artículo aprovechan las funciones de un CloudOE como IBM Cloud. Al utilizar estos patrones, usted puede estructurar sus aplicaciones de PaaS para que sean buenas ciudadanas de la nube confiables, con alta disponibilidad y escalables.

Agradecimientos

Le agradecemos a Pete Cripps y Philippe Spaas por el tiempo invertido en discutir los conceptos de este artículo; y a Donald Cronin y Michael Behrendt por su revisión.


Recursos para Descargar


Temas relacionados

  • IBM Cloud: IBM Cloud ofrece un único entorno de solución con los recursos e infraestructura instantáneos que necesita para desarrollar y desplegar aplicaciones en múltiples dominios.
  • Comunidad de desarrolladores de IBM Cloud: Toda la información y recursos que usted necesita; además de muchas aplicaciones de muestra para empezar a utilizar IBM Cloud hoy mismo.
  • Patrones de Arquitectura en la Nube (Bill Wilder, O'Reilly Media, 2012): Este libro presenta patrones arquitectónicos que aprovechan los servicios de plataforma en la nube.
  • Programación para la PaaS (Lucas Carlson, O'Reilly Media, 2013): Este libro muestra cómo la PaaS puede ayudar a las personas a enfocarse en aplicaciones innovadoras en lugar de perder tiempo con operaciones técnicas.
  • TOGAF 9.1: Obtenga más información acerca de la metodología e infraestructura de arquitectura empresarial TOGAF, un estándar de grupo abierto.
  • Especificación de ArchiMate 2.0: Aprenda más acerca de ArchiMate, un lenguaje de modelación de arquitectura empresarial estándar de grupo abierto que permite una representación uniforme en diagramas que describe arquitecturas empresariales.
  • Cloud Foundry por Pivotal: Visite el sitio web de Cloud Foundry.
  • "Diseño de un ecosistema SoE para soportar experiencias de usuario ricas" (Fabio Castiglioni y Michele Crudele, developerWorks, octubre de 2013): Lea acerca de un enfoque para diseñar un sistema de vinculación basado en CloudOE.
  • "El Diagrama de Contexto Operativo " (Vito Lassaco y Fabio Castiglioni, developerWorks, febrero de 2009): Aprenda acerca de una técnica para complementar los diagramas de contexto de un sistema con un diagrama de contexto operativo orientado y no funcional.

Comentarios

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing
ArticleID=1019967
ArticleTitle=Gestión de Requisitos No Funcionales para Aplicaciones en la Nube
publish-date=02262018