Integre aplicaciones en un dispositivo nube: 18 prácticas

Mejores prácticas para ayudarle a instalar una aplicación adecuadamente configurada en un dispositivo cloud

Más propietarios de aplicaciones desean que sus aplicaciones sean hospedadas en un entorno de nube, lo cual puede ser un reto si la aplicación es compleja o si tiene una dependencia fuerte con el entorno de ejecución. Un escenario común de implementación de aplicación en la nube es aquel donde usted tiene software que no es para la nube y que usted desea integrar con software que ya se está ejecutando en la nube — para hacer esto existen bastantes elementos que necesitan planificación (si usted todavía está experimentando con la aplicación en cuestión), o ser integrados (si la aplicación ya existe). En este artículo los autores proporciona 18 mejores prácticas para garantizar que su aplicación pueda integrarse con facilidad con otro producto nube, que pueda integrarse con otro dispositivo de nube, o que pueda hospedarse como un dispositivo independiente en la nube.

Sheetal Jharia, Ingeniero de software, IBM

Sheetal Jharia es ingeniero del equipo de software (e IBM Cloud OS Development Lead) en IBM-ISL y actualmente trabaja en IBM Systems Director VMControl Development, un producto crítico del portafolio de nube IBM. Ella cuenta con ocho años de experiencia en las TI y tiene un pregrado y una maestría en Ingeniería Eléctrica y de Sistemas de Comunicación del IIT de Madras, India.



Ashish Billore, Gerente de desarrollo, IBM

Ashish Billore es Gerente de desarrollo de IBM Cloud OS en los laboratorios de IBM India. Él administra el equipo de desarrollo IBM Systems Director VMControl y es responsable del desarrollo de componentes reutilizables para desarrollar infraestructuras de nube. Diseña y desarrolla aplicaciones usando tecnologías como Java, Eclipse, OSGi y servicios web. Ha contribuido para varios parches para la plataforma de fuente abierta Eclipse y ha presentado artículo en conferencias de tecnología IBM y QSE. Posee un grado en Ingeniería Electrónica y de Comunicaciones y un posgrado en Tecnologías de la Información.



15-10-2012

Este artículo proporciona algunas mejores prácticas para el diseño y el empaquetamiento de una aplicación para su consumo en la nube, de manera que pueda:

  • Integrarse con otro producto de nube para que el otro producto pueda aprovechar sus capacidades.
  • Integrarse con un dispositivo que ya esté hospedado en la nube.
  • Hospedarse como un dispositivo independiente en la nube.

Si alguno de estos escenarios es de su interés, lea algunas experiencias que hemos destilado en mejores prácticas para lograr alguna de estas metas.

Primero, hablemos un poco más sobre estos escenarios.

Tres escenarios

De nuevo, los escenarios que proponemos incluyen integrar una aplicación con un producto nube existente, implementar una aplicación como parte de un paquete de dispositivo general en la nube, o integrar la aplicación con un dispositivo de nube existente.

Integre su aplicación con otro producto de nube

La necesidad es mejorar la aplicación nube existente con las capacidades de su aplicación. La meta es hacerlo sin inconvenientes.

Cuando existe la necesidad de introducir nuevos recursos a un producto existente, es común que esto incluya el diseño y desarrollo de la nueva funcionalidad desde cero; la alternativa es tomar un producto disponible (en este caso, no habilitado para la nube) e integrar sus capacidades con el producto nube. En este escenario, usted debe asegurarse de que su aplicación pueda "conectarse" apropiadamente con el producto nube existente.

Añada su aplicación a otro dispositivo que ya esté hospedado en la nube

Un dispositivo de nube consiste en software y aplicaciones preinstalados y preconfigurados; también puede utilizarse algunas veces como un servidor auto-contenido. Cuando planee añadir una aplicación adicional a un paquete de dispositivo de nube existente para mejorar su funcionalidad, asegúrese de que su aplicación interactúe correctamente tanto con las demás aplicaciones del paquete, como con los archivos de configuración y las dependencias de recursos del dispositivo.

Hospede su aplicación como un dispositivo de nube independiente

Una forma de llevar su aplicación a la nube es dentro de su propio dispositivo de nube, especialmente si usted no necesita integrarla con otras aplicaciones de nube.

Antes de continuar, es útil entender a qué nos referimos con dispositivo, aplicación y máquina virtual:

  • Dispositivo virtual: Es una solución de software pre-elaborada y compuesta por una o más máquinas virtuales, la cual es empaquetada, mantenida, actualizada y administrada como una unidad. Los desarrolladores crean dispositivos virtuales desarrollando apilamientos de aplicación auto-contenidos y optimizados, que son personalizados para su carga de trabajo y que se incorporan a un sistema operativo seleccionado; los dispositivos pueden ser más seguros y confiables que el software tradicional; una aplicación se puede poner a disposición mediante la simple copia de un conjunto de archivos y la inicialización del dispositivo virtual.
  • Aplicación: Una aplicación habilitada para la nube. Es un componente de la pila de aplicaciones dentro del dispositivo.
  • Máquina virtual: Es un contenedor de software herméticamente aislado, creado para ejecutar plataformas virtualizadas. Contiene cuatro recursos virtualizados clave: CPU, RAM, almacenamiento y redes.

En este artículo, la palabra "producto" se utiliza para hacer referencia a la "aplicación" o "dispositivo", dependiendo del contexto.

Ahora observemos algunas mejores prácticas para ayudar a hacer realidad estos escenarios.


Práctica 1: Soporte de instalación silenciosa

La instalación que no presenta en pantalla mensajes ni ventanas durante su ejecución es llamada instalación silenciosa. Una instalación silenciosa no es una instalación no atendida. Una instalación no atendida es aquella que no requiere interacción del usuario; una instalación silenciosa (o callada) es la que no muestra ninguna señal de su progreso.

Usted debe soportar instalación silenciosa en su producto junto con la instalación interactiva/GUI, para que el usuario pueda elegir cualquiera de los dos métodos para instalar el producto. Para la instalación silenciosa, lo que se requiere que el usuario ingrese debe suministrarse en un archivo de respuesta que necesita ser editado una sola vez al comienzo, al inicio de la instalación. Una vez que la instalación comienza, no se deben requerir datos del usuario y no se debe mostrar al usuario el progreso ni otras ventanas.

Cuando una aplicación se integra a otra aplicación o a un dispositivo, esta se torna parte de un mismo producto y es preferible crear un solo instalador. Si su producto no puede instalarse de forma silenciosa, la información requerida es solicitada al usuario durante la instalación única, momento en el cual es posible que el equipo del dispositivo no desee mostrar ventanas/hacer preguntas a sus usuarios. Este es un inconveniente para el usuario y realmente no es necesario que ellos conozcan estos detalles de producto subyacentes. Si no hay disponibilidad de instalación silenciosa usted pierde la efectividad que ha logrado para el usuario, porque es como tener que instalar dos productos diferentes.


Práctica 2: Control del uso del espacio en disco

Los recursos de su sistema deben regularse automáticamente para ayudar a controlar el uso de espacio en disco. Si las funciones y procesos de su producto escriben registros y rastrean datos en un archivo de salida (¡y cuántos de estos no lo hacen!), debe haber un proceso operando encargado de restringir este flujo de datos para evitar una situación de agotamiento de memoria en el servidor de dispositivos.

Cree un archivo apropiado que defina el tamaño y el número de los archivos de resultado a generar. Estos valores deben poder ser editados por el administrador de sistema. Cree un proceso para supervisar estos archivos.

Si el tamaño del archivo de resultado o su número excede el límite mencionado en el archivo de propiedades, se puede seguir alguno de los pasos a continuación:

  • Los archivos antiguos pueden eliminarse y ser reemplazados por unos nuevos.
  • Se puede administrar al sysadmin sobre la situación.
  • Es posible dejar de escribir datos nuevos en el archivo de registro.

Usted también puede proporcionar una opción configurable y programática (al vuelo) para hacer lo siguiente:

  • Redirigir los registros hacia cualquier ubicación deseada: En un entorno de dispositivo, es posible que el sysadmin quiera tener todos los registros en un mismo lugar para facilitar su supervisión y recopilación. Tenga en su producto una opción para elegir la ubicación en la cual se almacenan los registros.
  • Asigne y reasigne nombre a los registros: Junto con la ubicación en la cual deberán ir, el usuario debe especificar el nombre de los mismos, de acuerdo a su propio estándar y conveniencia. Para proporcionar más flexibilidad, también se debe soportar la posibilidad de cambiar el nombre de los archivos de registro, teniendo en cuenta que en el futuro su producto puede ser parte de dispositivos grandes y avanzados.
  • Incorpore los registros en otros registros brindando la opción de registrar secuencias de registros: Este recurso avanzado significa tener la flexibilidad para incorporar sus registros en otro registro, siempre y cuando el entorno de dispositivo permita la secuencia de resultado apropiada.

Práctica 3: Las configuraciones deben poder ser cambiadas mediante API o CLI

Usted debe poder acceder y cambiar todos los parámetros de configuración mediante API o interfaz de línea de comandos. Gracias al acople suelto, el peso ligero y la interoperabilidad que ofrecen los servicios web REST, estos son bastante populares y probablemente son los más comunes que usted encontrará. Si cualquier proceso requiere cambiar manualmente algún archivo de propiedades o cualquier otro archivo, este se debe adaptar para que estos cambios se puedan hacer mediante CLI o API.

Si se necesita que algún parámetro o configuración particular se complete durante la instalación de la aplicación o como parte del funcionamiento de la aplicación en general, use estos CLI o API para hacerlo. El diseño debe ser de una forma tal que el dispositivo no necesite entender el diseño interno de su aplicación para hacer los cambios a las configuraciones— usted debe poder hacerlo usando únicamente la CLI.

Y, donde sea que tales parámetros o configuraciones sean cambiados(as), lo ideal es que surtan efecto inmediatamente y sin necesidad de reiniciar la aplicación; de esta forma ello no perturbará el funcionamiento de toda la aplicación.


Práctica 4: La información de seguimiento y registro debe poderse recopilar vía API/CLI

Cuando se reporta un problema con el producto es importante que se recopilen registros del mismo para poder diagnosticarlo completamente. Tenga mecanismos de línea de comandos (o de cualquier otro tipo) disponibles para efectuar operaciones de diagnóstico selectivas y aisladas, operaciones que no afecten el dispositivo en su conjunto. Esto incluye la capacidad para recopilar información de registro/seguimiento que puede ser usada directamente por el sysadmin.


Práctica 5: Soportar la alta disponibilidad es realmente una gran ventaja

La mayoría de los dispositivos de IBM intentan soportar la alta disponibilidad; los clientes exigen esto. Si su producto no soporta alta disponibilidad, entonces las capacidades generales de alta disponibilidad del dispositivo se tornan menos efectivas. Una buena idea es crear un diseño de soporte de alta disponibilidad para su producto al comienzo del desarrollo, o dejar el espacio para realizar tal desarrollo en el futuro.


Práctica 6: Proporcione capacidades de ciclo de vida

Cualquier proceso, hebra, o daemon que se esté ejecutando como parte de su aplicación debe tener su propia capacidad de ciclo de vida. Este debe servir estados comunes como iniciar, suspendido y detener, y debe haber una provisión para que el producto mismo controle estos estados usando las CLI o API.


Práctica 7: Todas las configuraciones deben ser reconfigurables

Cualquier configuración asumida durante la pre-carga debe tener la opción de poderse restablecer durante la creación del dispositivo. También debe poderse reconfigurar a solicitud del cliente.

Su producto debe funcionar bajo ciertas configuraciones como si fuera individual — por ejemplo, dirección IP, configuraciones de puerto, o configuraciones de red — pero cuando se integra con otro producto, esos parámetros pueden requerir cambios a causa del entorno de trabajo del cliente o a los requerimientos generales del producto. Cualquiera de esas configuraciones deberá poder ser restablecida o cambiada al momento de la integración del producto, la creación de dispositivos o la implementación del cliente.


Práctica 8: Capacidad para activar o desactivar la aplicación en el dispositivo

Este es un recurso opcional, pero también importante. Una fuerte ventaja es si su aplicación es de aquellas que puede ser activada o desactivada usando una línea de comandos, API o GUI, de manera que los archivos relacionados con el producto todavía residan en el disco pero sin consumir recursos de memoria del sistema en el que están hospedados. De esta forma, es posible incorporar si producto en otro y usarlo cuando sea necesario, activándolo o desactivándolo. En la nube, una aplicación puede desactivar ciertos servicios que proporciona al desactivar el recurso correspondiente incluso mientras continúa hospedando el producto inicial.


Práctica 9: Capacidad para aplicar parches al dispositivo

Si hay alguna actualización o parche disponible para su producto, usted debe ser capaz de aplicarlo en el entorno integrado de la aplicación. Cuando su producto esté integrado con otro, su equipo no tendrá que dejar de trabajar en su mejora: Usted simplemente necesita definir una ruta de actualización para su producto en la fase de diseño.

Como su aplicación puede estar integrada con otros dispositivos nube en el futuro, debe soportar la aplicación de parches dentro de un entorno integrado.

Además, su aplicación debe tener actualizaciones, reparaciones y parches empaquetados, de manera que puedan ser incluidos o empaquetados con otras actualizaciones de la aplicación. Y debe estar en capacidad de pasar por el proceso de parche/actualización sin tener que reiniciar la aplicación.

Incluir una provisión que le permita a usted deshacer la actualización o el parche aplicados también es algo bueno en caso de que el cambio sea incompatible con el resto de la aplicación.


Práctica 10: Comandos que deben funcionar en cualquier shell

Intente asegurarse de que ningún comando esté restringido a ningún shell en particular. Los comandos CLI relacionados con su aplicación (al menos los más importantes) no deben restringirse de manera que solo funcionen en cierto(s) shell. El dispositivo en el cual su producto está integrado puede ejecutarse en un shell diferente al que usted haya seleccionado; en ese caso usted no podrá ejecutar los comandos CLI simplemente porque el shell es diferente.


Práctica 11: Las funciones de clave de licencia deben activarse cuando se instale la clave

Las funciones que son soportadas por una clave de licencia deben estar conectadas a la GUI o CLI común del dispositivo y activarse cuando se instala la clave de licencia. Si alguna de las funciones de su aplicación también soporta clave de licencia, entonces este recurso debe diseñarse adecuadamente e integrarse en la GUI común del dispositivo, desde el comienzo, de manera que si se aplica la licencia para cualquier componente de su aplicación, esta también sea detectada por la GUI común informando al usuario que utiliza el dispositivo. Esto da al cliente una idea clara de cuáles licencias ya está usando y cuáles necesita aplicar o comprar. Esto también ayuda al administrador de nube a mantener las diversas licencias de forma efectiva. La aplicación debe proporcionar una API para solicitar información de licencia y para aplicarla o actualizarla sin necesidad de reinicio.


Práctica 12: El desarrollo de marca debe estar activado

Este es un requisito importante. Debe haber una provisión en su aplicación para cambiar la marca (con nombre de producto y número de versión) cuando se incluya en otro producto o dispositivo.

El propietario de un dispositivo puede querer cambiar la marca de las funciones proporcionadas por su aplicación, de manera que sean descritas con un nombre que se ajuste mejor con el objetivo común del dispositivo.

El número de versión también debe poder ser sobrescrito por el dispositivo. Esto se logra de diferentes formas, una es tener un archivo que describa el nombre del producto y su número de versión como una variable constante que pueda ser cambiada por el admin de la aplicación (con los permisos apropiados, desde luego).


Práctica 13: Tenga una API que pueda terminar el programa de forma limpia

Haga las provisiones para una parada fuerte y limpia de la aplicación mediante API. Cuando es necesario salir abruptamente de cualquier programa de su aplicación (como un apagado crítico o cuando no está respondiendo), debe haber API establecidas que puedan terminar limpiamente los procesos e hilos al interior de su producto, sin corromper los datos ni afectar negativamente la aplicación.


Práctica 14: Ponga a disposición elementos de copia de seguridad y restauración de datos

Cree capacidades de copia de seguridad y restauración de datos mediante API en múltiples formatos como archivos planos, volcados de base de datos, etc. Desarrolle una capacidad de línea de comandos (no es necesaria una GUI) que pueda hacer copia de seguridad de todos los datos críticos relacionados con su aplicación y que pueda restaurarlos cuando se necesite.

Esto es útil cada vez que se realice una re-instalación de su producto en el dispositivo y se requieran los datos más antiguos para que su producto pueda realizar los mismos procesos y funciones que antes. También es útil para mejorar la tolerancia a fallas o la alta disponibilidad de la aplicación.


Práctica 15: La aplicación debe ser auto-contenida y autosuficiente

Este es un requisito importante para que su aplicación pueda se incluida, excluida o actualizada de forma independiente en un dispositivo. Cuando intente incluir, excluir o actualizar su aplicación, el sysadmin no debe estar luchando con las dependencias que la aplicación pueda tener con datos, configuraciones o entornos externos(as).


Práctica 16: La API debe estar en capacidad de importar o exportar datos a la aplicación

Una buena idea es tener API listas que puedan consultar datos desde dentro de su aplicación, o escribir datos desde la aplicación hacia cualquier ubicación. La misma API se puede usar también para administrar los permisos del usuario que está consultando o escribiendo los datos. Esto facilita el proceso de editar cualquier recurso de su aplicación por parte del equipo del dispositivo y les proporciona mayor modularidad.


Práctica 17: Tenga una manera programática de administrar usuarios

Tenga una forma programática para crear, eliminar o modificar usuarios y roles, y para restringir diversas opciones o funcionalidades. Para tener acceso seguro a los recursos de su aplicación (y también para asegurar funciones de dispositivo), debe haber una manera programática para restringir y administrar diferentes usuarios y sus roles. Una GUI podría ser una interfaz inactiva para crear usuarios y roles y para administrar sus permisos respectivos.


Práctica 18: Mantenga las dependencias externas fuertes al mínimo

Sólo deben existir acoplamientos ligeros respecto a cualquier versión o proveedor específico. Intente eliminar cualquier dependencia fuerte frente a herramientas externas a ser utilizadas en su aplicación.


En conclusión

Estas 18 prácticas básicas deben ayudarle a pensar en alteraciones aplicables a cualquier aplicación que planee ejecutar en la nube, especialmente si usted planea añadirla a un dispositivo nube, ya sea que se esté ejecutando en la nube o no.

El siguiente paso es profundizar en cada una de estas prácticas para ver algunas de sus implementaciones en el mundo real y para entender las implicaciones que tiene cada una en la creación de una aplicación de nube efectiva, una que pueda integrarse fácilmente en el entorno de nube.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing
ArticleID=839603
ArticleTitle=Integre aplicaciones en un dispositivo nube: 18 prácticas
publish-date=10152012