Contenido


Recetas de aplicación de nube

Una receta por capas de 3 pasos

Comments

El valor de los patrones en el desarrollo de software, arquitectura y operaciones ha sido ampliamente registrado a lo largo de los años. Los ejemplos incluyen la discusión de Patrones de arquitectura de The Open Group en TOGAF y la discusión de Kyle Brown de Patrones a todos los niveles bajo el contexto de patrones de tiempo de ejecución.

En este artículo, aprenderá más acerca de un nuevo tipo de patrones denominado recetas. Usted puede utilizar recetas para evaluar las solicitudes de candidatos para la migración o implementación en la nube. Estas aplicaciones pueden ejecutarse exclusivamente en la nube o en un modelo híbrido, donde algunos de los componentes se ejecutan en otras plataformas de nube o en entornos tradicionales.

Las recetas simplificar el tiempo y el esfuerzo necesarios para analizar sus aplicaciones y determinar la mejor forma de implementar la aplicación en sus plataformas de nube IaaS o PaaS. Al utilizar los tres bloques de construcción básicos descritos a continuación, usted puede evaluar cada aplicación para definir lo que se requiere y la mejor manera de alinear su aplicación a los sistemas y servicios de nube. Además puede extender los patrones básicos con dos capas adicionales de servicios; servicios de ecosistema específicos de receta y servicios de ecosistema generales

Receta

El patrón central o receta, proporciona información sobre cómo construir su aplicación o componente a partir de un conjunto de tiempos de ejecución y servicios. No son fórmulas estándar (que implica una combinación específica de servicios específicos), sino un conjunto de instrucciones sobre cómo combinar tipos de servicio general. Una fórmula estándar es más parecida a una pizza congelada o a un paquete de taza de fideos Ramen que a una receta.

En general, existen tres tipos de recetas analizadas en este artículo, cada una de las cuales tiene subtipos específicos. Usted conocerá los diferentes tipos de recetas y los tipos de servicio de dan soporte a cada tipo de receta. Primero usted necesita conocer tres conceptos que se relacionan con el tipo de sistemas que se pueden construir en la nube. Usted verá por qué esto es importante cuando se define la primera receta. Los tipos de sistema son:

  • Sistemas de registro – Un sistema de registro es uno en el que se registra la información sobre objetos o eventos del mundo real. Si en su aplicación tiene datos complejos sobre personas, eventos y cosas en un almacenamiento persistente, entonces usted probablemente construya un sistema de registro.
  • Sistemas de compromiso – Un sistema de compromiso es uno donde usted interactúa principalmente con personas, en lugar de con otros sistemas. Si su aplicación está diseñada para acceder a los datos existentes, o como mucho de permitir cambios sencillos a datos existentes, probablemente usted está construyendo un sistema de compromiso.
  • Sistemas de conocimiento – Un sistema de conocimiento es quizás el tipo de sistema más difícil de entender. Si su sistema existe para responder a preguntas sobre el pasado, o para intentar predecir el futuro de alguna manera, entonces lo más probable es que construya un sistema de conocimiento.

Esto es importante porque cada uno de estos tres tipos de sistema corresponde a una combinación específica de tiempos de ejecución y servicios que son únicos para ese tipo. En otras palabras, estas son nuestras primeras recetas. Pero, una receta consta de un conjunto básico de ingredientes. Por ejemplo, un sistema de registro normalmente requiere una base de datos para satisfacer sus propios requisitos funcionales y no funcionales. Lo que puede variar son los ingredientes adicionales que usted ajuste al problema particular a mano; como si se tratara de una receta de cocina que le indica "la temporada para probar"

De hecho, la receta más sencilla es la de un sistema de registro. Después de revisar decenas de ejemplos de sistemas de registro que han sido documentados en developerWorks o que hemos construido a través de IBM® Bluemix Garage, descubrimos que la receta es:

Sistema de Registro = Tiempo de Ejecución + Fuente de Datos (Opcional) Gateway

Figura 1. Ejemplo de fuentes de datos
Example data sources
Example data sources

¿Qué significa todo esto?

Un tiempo de ejecución es la primera pieza en IBM® Bluemix, que podría significar un Cloud Foundry Instant Runtime (como Liberty Buildpack), o un Docker Container, o una VM que pueda hospedar su código de aplicación.

Una fuente de datos es el siguiente componente. Podría ser cualquiera de las opciones de SQL en Bluemix (como DB2 como un Servicio o PostgreSQL por Composer Service) o cualquiera de las alternativas NoSQL como IBM® Cloudant® o Redis by Compose.

El gateway es la parte que puede ser más difícil de entender. Algunos (pero no todos) de los sistemas de registro dependen de múltiples tipos de fuentes de datos, algunas de las cuales podrían estar detrás de los firewalls corporativos. Así que una gateway podría incluir un servicio como Gestión de API o incluso la gateway asegurada para acceder a esas fuentes de datos. Asimismo los sistemas de registro también pueden tener gateways front-end. Si su tiempo de ejecución está construido como un servicio asíncrono, necesitará una gateway como Message Hub o el servicio IBM® MQLight para permitir que otros sistemas se comuniquen con él.

Un sistema de conocimiento comparte algo con un sistema de registro, una fuente de datos. La fuente de datos es a menudo el único factor común. Aquí está la receta para un sistema de conocimiento:

Sistema de Conocimiento = Fuente de Datos + Visualización (Opcional) + Herramienta Analítica (Opcional) + Movimiento de Datos (Opcional)

Vale la pena examinar los dos nuevos tipos de servicios introducidos. Una herramienta de análisis es un servicio que le ayuda a realizar análisis especializado de sus datos. Los ejemplos de herramientas analíticas incluyen IBM® BigInsights® para Apache Hadoop, Apache Spark, o incluso IBM® DashDB™. Una visualización es un tipo de servicio que permite al usuario ver los resultados de su análisis. Podría ser en forma textual, como un informe de Embeddable Reports. O podría ser una herramienta visual como IOT Real-Time Insights. Por último, usted puede necesitar mover datos dentro y fuera de diferentes fuentes de datos en un sistema de conocimiento - ese es el trabajo de una herramienta de movimiento de datos como IBM® DataWorks.

Con un sistema de compromiso, siempre tendrá un tiempo de ejecución y, a menudo una gateway, pero usted puede tener o no una fuente de datos. Si su sistema de compromiso está almacenando datos en caché localmente, usted puede tener una fuente de datos para que actúe como una memoria caché, pero usted no debe almacenar los datos permanentemente en un sistema de compromiso, ese es el trabajo de un sistema de registro. Así que la receta más sencilla para el sistema de compromiso es:

Sistema de Compromiso = Tiempo de Ejecución + [Fuente de Datos como Caché] + [Gateway]

¡En este ejemplo parece como si todo fuera opcional! Eso no es de mucha ayuda. La verdadera diferenciación entra en la siguiente capa - cuando usted considera las recetas más específicas que utilizan los servicios del ecosistema específico de la receta.

Figura 2. Tipos lógicos de receta
Logical recipe types
Logical recipe types

Ecosistema específico de receta

La siguiente capa consiste en servicios en el ecosistema específico de receta que incluye los sistemas o servicios utilizados por una o más recetas específicas con el fin de funcionar plenamente dentro de un entorno de producción o de prueba, además de la receta básica.

Las recetas vienen a menudo en subtipos específicos que le ayudarán a decidir qué servicios básicos y qué servicios de los ecosistemas específicos de receta necesita:

Los sistemas de interacción están divididos en sistemas web de interacción y sistemas móviles de interacción:

  • Un sistema Web de interacción posiblemente podría utilizar los servicios de los ecosistemas específicos de receta como almacenamiento de sesión en memoria caché e inicio de sesión único
  • Un sistema móvil de interacción podría utilizar servicios específicos de receta como notificación de inserción, de aseguramiento de calidad móvil y seguridad

También comúnmente observamos sistemas de registro de Internet de las Cosas que envían y reciben mensajes a través de la gateway IOT. A menudo eso se combina con un sistema de compromiso que permite a los usuarios interactuar con la información que está almacenada en el almacén de datos mediante ese sistema de registro.

Finalmente, los sistemas de conocimiento pueden dividirse en sistemas históricos de conocimiento y sistemas de conocimiento en tiempo real

  • Los sistemas históricos de conocimiento utilizan técnicas como articulación de tablas que está disponible en sistemas DashDB.
  • Los sistemas de conocimiento en tiempo real pueden utilizar técnicas como análisis de secuencias o Apache Spark

Los sistemas o servicios en esta capa pueden dividirse en dos grupos. Estos incluyen sistemas o servicios para:

  • Permitir el éxito operativo. Esto incluye servicios tales como monitoreo, balanceo de carga y almacenamiento en caché. Por ejemplo, cuando seleccione los servicios en la nube para una receta de sistema Web de interacción (SOI) puede depararse con que usted necesita almacenamiento en memoria caché de sesiones, balanceo de carga o escalamiento automático.
  • Interactúe con la aplicación para brindar soporte a requisitos funcionales. operaciones. Las interacciones pueden emplear múltiples protocolos (SOAP, REST, JDBC, etc). La disponibilidad de estos sistemas o servicios varían según el entorno (Dev, QA, Prod) y, en algunos casos están representados por APIs publicadas o servicios virtuales.

Ecosistema general

El tipo final de servicios son los servicios de ecosistema general que rindan soporte al desarrollo, entrega y ciclo de vida de release de software. Para las organizaciones que despliegan hacia entornos híbridos, tradicionales o de sistema principal, este ecosistema proporciona los sistemas y servicios para múltiples entornos en los ciclos de vida de la entrega de aplicación. Por ejemplo, si despliega su aplicación Web en público Bluemix entonces seleccionaría BlazeMeter o LoadImpact para probar el rendimiento de la aplicación. Y si está desarrollando una aplicación nativa de nube para implementación en Bluemix pública, opte por utilizar los servicios de DevOps Services Delivery Pipeline para construir e implementar su aplicación en diferentes etapas. Por el contrario, si desarrolla aplicaciones con flujos de trabajo híbridos que se implementan hacia entornos tradicionales en las instalaciones y a hasta una o más plataformas de nubes (IaaS, PaaS), entonces utilice UrbanCode Deploy para implementaciones de aplicaciones y suministro de la pila completa en las plataformas de nube.

Comprenda las posibilidades disponibles

Cuando emplee este abordaje, es posible que desee calificar su aplicación y patrón determinando si su aplicación está lista para la nube. un buen marco a seguir en esta evaluación es "Las principales 9 reglas para las aplicaciones de nube" (developerWorks, abril de 2014).

Usted también debe tener un entendimiento de su proveedor de nube o de las posibilidades tradicionales de nube, especialmente de los servicios proporcionados que usted espera aprovechar. Muchos proveedores tiene sitios Web, como los servicios de nube de IBM.

Comprenda la capacidad que tiene para integrar sus plataformas si desea operar algunas de sus aplicaciones entre plataformas en un modelo híbrido. Un buen ejemplo es la integración de APIs y nube híbrida.

Evalúe los sistemas o servicios ofrecidos por un proveedor de computación en nube, entre proveedores o alojados en las instalaciones. Por ejemplo, el blog "UrbanCode con Bluemix para Implementación de Nube Híbrida" demuestra una capacidad común a lo largo de canales de entrega para plataformas híbridas y tradicionales.

Construcción de una Receta

Es mejor aplicar la receta para cada aplicación y, a continuación, buscar ecosistemas repetibles para categorizar sus aplicaciones en patrones comunes. Esto debería realizarse de forma iterativa y sólo introducir nuevos requisitos o servicios cuando sea necesario.

  • Paso 1: Construya su propia receta. Experimente y determine qué tiempos de ejecución servicios son los adecuados para su receta básica.
  • Paso 2: ¿Su aplicación necesita servicios de ecosistema de receta para implementar funcionalidad específica de receta o satisfacer la NFR de tu receta básica? Si es así, añada servicios de ecosistema específicos de la receta.
  • Paso 3: ¿Su aplicación necesita los servicios de ecosistema para cumplir con el NFR de su solución en las áreas de mantenimiento, rendimiento, confiabilidad o seguridad? Si es así, añada en general servicios de ecosistema, tales como uno o más de los Servicios de DevOps o los Servicios de Seguridad.

La siguiente figura muestra un ejemplo de receta de Bluemix. Incluye una receta básica de tiempo de ejecución de Java, Cloudant DB, Secure Gateway y CUPS para conectividad a fuentes de datos adicionales en las instalaciones. También incluye ecosistemas de receta específica y generales bajo la forma de cadena de herramienta abierta DevOps, análisis de auto-escala y hub de mensajes.

Figura 3. Ejemplo de receta de Bluemix
Example of a Bluemix recipe shows the flow of traffic using different types of dashed lines and colors.
Example of a Bluemix recipe shows the flow of traffic using different types of dashed lines and colors.

Conclusión

En este artículo, usted aprendió acerca de patrones de arquitectura que puede utilizar para planificar la migración de sus aplicaciones hacia las plataformas de nube PaaS o IaaS. Las tres etapas del abordaje por capas proporcionan un medio para definir sus patrones central y de ecosistemaque le permitirán definir las topologías de tiempo de ejecución de los servicios de nube necesarios para sus aplicaciones. Al emplear este método, usted reducirá su tiempo y esfuerzo para planificar su migración y reducirá la complejidad al mover múltiples aplicaciones con patrones de receta similares.


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=Cloud computing
ArticleID=1043685
ArticleTitle=Recetas de aplicación de nube
publish-date=12282016