Cambio de comportamiento de las aplicaciones: Del interior de la empresa hacia la nube

Llevando una aplicación de centro de datos hacia la nube: Sea proactivo, no reactivo

Con frecuencia, las empresas y las agencias del gobierno necesitan que sus aplicaciones de cliente o de cliente-servidor tradicionales, que se ejecutan perfectamente bien dentro de sus instalaciones, se comporten igual de bien en un entorno en nube. Para hacerlo, necesitan hacer cambios proactivos en la aplicación antes de migrarla hacia la nube. En este artículo, la autora primero habla sobre la pesadilla de ser reactivo, da ejemplos de cambios de conducta proactivos de la aplicación, y luego sugiere cómo puede usted seguir siendo proactivo(a) cuando migra la aplicación.

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson es arquitecta e ingeniera de sistemas. Sus áreas de interés incluyen los sistemas en toda la amplitud de la empresa, tecnologías de middleware, tecnologías de bases de datos, computación en la nube, políticas de umbrales, industrias, administración de red, seguridad, tecnologías de RFID, administración de presentaciones y administración de proyectos.



16-01-2012

En una aplicación bien diseñada, un estado de función de aplicación se moverá sin problemas y rápidamente hacia el estado de otra función. La aplicación siempre está disponible sin interrupciones (o como máximo, son imperceptibles), excepto por los periodos de inactividad programados para mantenimiento.

De forma inevitable el desarrollador decide migrar la aplicación hacia un entorno de nube. En este escenario, el desarrollador no es proactivo. Para prepararse para la migración él realiza algunos cambios a la aplicación, como añadir un recuadro de inicio de sesión para permitir que los usuarios con credenciales apropiadas usen la aplicación; las credenciales incluyen qué tanto control tiene el usuario sobre la aplicación dependiendo del tipo de servicio en nube que alquile.

Si el desarrollador migra la aplicación como Software como un Servicio (SaaS), el único control que el usuario tiene es el acceso a la aplicación desde un escritorio o dispositivo móvil para procesar tareas de negocios como recibos o facturación; bajo este esquema el usuario no tiene permitido controlar el sistema operativo, ni el hardware, ni la infraestructura de red sobre la que se ejecuta la aplicación SaaS. Solo el desarrollador puede crear, implementar, ejecutar y administrar actualizaciones y parches para todas las funcionalidades de la aplicación.

Si el desarrollador migra la aplicación como parte de una Plataforma como un Servicio (PaaS), el usuario puede controlar la aplicación dentro de todo el ciclo de vida de negocios de la plataforma, manipulando cosas como hojas de cálculo y procesamiento de nómina. El usuario determina qué cambios hacer a la aplicación, como añadir una opción para una lista desplegable proporcionada por el desarrollador. Todavía el usuario no tiene permitido controlar el sistema operativo, ni el hardware, ni la infraestructura de red.

Poco después de que el desarrollador complete el proceso de migración, encuentra problemas de interoperabilidad y desempeño. La disponibilidad en pleno funcionamiento comienza a decrecer con respecto al nivel garantizado en un acuerdo de nivel de servicio (SLA). Los usuarios se quejan porque la respuesta de la aplicación a las solicitudes de datos que necesitan para tomar decisiones críticas de negocios, es más lenta de lo usual: los usuarios han perdido nuevas oportunidades de negocios.

Desesperado por soluciones de negocios, el desarrollador puede tornarse reactivo.

La pesadilla de tornarse reactivo

Desesperado por soluciones de negocios, el desarrollador se torna reactivo. Primero detiene la producción en la nube mientras pretende estar en un mantenimiento programado. Pone una notificación en los navegadores de los usuarios que dice: "Temporalmente fuera de servicio. Por favor espere." Luego comienza a trabajar en la aplicación dentro de sus instalaciones.

Rápidamente el desarrollador nota que es difícil localizar el código para expandir para incluir una lista desplegable de tareas de negocios (como las de facturación). El desarrollador descubre demasiado tarde que la aplicación que se ejecuta perfectamente bien dentro de sus instalaciones fue escrita por un desarrollador anterior como una sola unidad extensa, en lugar de, digamos, 500 partes modulares.

Desesperadamente, pone un parche a la aplicación con una parte modular en la lista desplegable y luego la prueba en la nube para determinar qué tan bien las instancias de recursos son asignadas equitativamente para ejecutar la aplicación. Descubre demasiado tarde que el balanceo de carga ha fallado; una instancia de recursos que ha alcanzado su capacidad máxima ha fallado. Otras instancias de recursos que han alcanzado el 75% de su capacidad máxima no pueden tomar el control de las transacciones de negocios de la instancia de recursos que falló.

Antes de la migración, el desarrollador no se aseguró si cada instancia de recursos se utilizaría al 50% de su capacidad, para que si alguna instancia de recursos fallaba las instancias de recursos en buen estado tomaran el control.

Mientras tanto, los usuarios se quejan por el prolongado trabajo de mantenimiento cuando comienzan a sospechar que el desarrollador ha estado teniendo problemas con la aplicación. Los usuarios exigen créditos, reembolsos y meses de servicio gratis como compensación a la falta de servicio según lo especificado en el SLA. Exigen que se les permita terminar el servicio si continúa el servicio insatisfactorio.

En este punto, el desarrollador gruñe y se queja por no haber hecho dos cosas antes de migrar la aplicación:

  • No dividió la aplicación en partes modulares.
  • No incluyó una ventana de umbral de recursos en la aplicación para supervisar las instancias de recursos que se están utilizando.

El desarrollador se lamenta por la pérdida del servicio, los usuarios y la reputación, por no haber incluido cambios de comportamiento proactivos en primera instancia. Habría sido una historia totalmente diferente si hubiera sido proactivo.


Cambios de comportamiento proactivos

Si un desarrollador considera cambios de comportamiento proactivos, puede mantener satisfechos a sus usuarios existentes, no arruinará su reputación y logrará nuevos suscriptores.

Primero, consigue un equipo que le ayude a dividir la aplicación en módulos, cada uno enfocándose en un cambio de comportamiento. Su equipo prueba los módulos dentro de las instalaciones y hace verificaciones con los usuarios para garantizar que los módulos satisfacen sus expectativas. En cuanto esto se ha realizado, migra la aplicación hacia un servicio tipo nube.

A continuación hay dos ejemplos de módulos que el equipo puede incluir en la aplicación:

  • Controles desplegables
  • Ventanas miniatura de umbrales

Módulo de controles desplegables

Este módulo de controles de lista desplegable permite a los usuarios hacer una selección entre una lista de valores mutuamente excluyentes de la lista. Con un clic del mouse un usuario puede seleccionar una y solo una opción. Mientras mantiene presionada la tecla CTRL, el usuario puede seleccionar múltiples opciones de la lista. Con una lista desplegable estándar, el usuario está limitado a las opciones que hay en la lista, pero con un cuadro combinado, el usuario puede ingresar un valor que no esté en la lista.

Un ejemplo es una lista desplegable de tareas de negocios que necesitan ser activadas:

  • Procesamiento de nómina
  • Hoja de cálculo
  • Facturación
  • Recibos

Si selecciona la opción de procesamiento de nómina, conseguirá que la aplicación se conecte en segundo plano con otra aplicación para iniciar el procesamiento de nómina. Si selecciona la opción de hoja de cálculo, aparecerá una lista de hojas de cálculo. Luego usted selecciona una hoja de cálculo para verla y editarla o puede añadir una nueva hoja de cálculo.

Si selecciona la opción de facturación, aparecerá una lista de facturas. Luego usted selecciona una factura para ver e imprimir. Usted puede abrir un formulario para nueva factura para llenarlo y luego enviarlo al destinatario vía email. Si selecciona la opción de recibos, usted selecciona una cuanta para verla y para enviar el pago.

Si algún valor no aparece en la lista de opciones y el usuario sabe que una nueva tarea de negocios ha sido añadida a la aplicación, él puede ingresar, digamosinvoicing2 en el cuadro combinado.

Aquí hay otra lista desplegable que muestra cuatro opciones de umbral:

  • Recursos
  • Usuario
  • Solicitud de datos
  • Panel de instrumentos

Si usted solo selecciona una opción con un clic del mouse, un módulo de ventana en miniatura de umbral (en la siguiente sección) abrirá una ventana para mostrar qué tan bien se está desempeñando la aplicación en cuanto a esa opción.

Por ejemplo, si usted solo selecciona la opción recursos, en la pantalla aparecerá una ventana miniatura sobre el uso de recursos. Si usted luego solo selecciona la opción usuario, aparecerá una ventana miniatura sobre el estado de usuario. Si usted selecciona las dos primeras opciones, use la tecla CTRL con el mouse para obtener una ventana miniatura para que cada opción aparezca lado a lado. Seleccione la opción panel de instrumentos para mostrar las tres primeras opciones en la ventana, cada una mostrando un nivel de umbral diferente.

Módulo de Ventana Miniatura de Umbral

El módulo hace aparecer una ventana miniatura activada por su selección de una opción en la lista desplegable de umbral. La ventana muestra qué tan bien se está desempeñando la aplicación en tiempo real con respecto al nivel de umbral establecido por el proveedor en una política de umbral que debe ser parte del SLA.

Si el módulo detecta que una aplicación se está desempeñando en o por debajo del nivel de umbral aceptable, la aplicación se ejecuta como estaba planeado, garantizando la continuidad operacional. Si está por encima del nivel de umbral mientras todavía está por debajo del nivel máximo, es una señal de que las operaciones de la aplicación pueden ser interrumpidas debido a algo como recursos insuficientes para completar una tarea, a usuarios que no cierran sesión cuando terminan el servicio, o a un número excesivo de solicitudes de datos que permanecen en fila.

Si la interrupción dura por algunos milisegundos, normalmente esto no es notorio para el ojo humano, asegurando continuidad operacional.

Si usted considera que el nivel de umbral está configurado muy alto, es posible que necesite contactar al proveedor para bajar el nivel a uno más aceptable.

La siguiente pregunta a responder es "¿cómo continúo siendo proactivo?".


Cómo puede usted continuar siendo proactivo

Después de cambios exitosos en la aplicación vinculada a un entorno de nube, asegúrese de permanecer proactivo. Pregúntese acerca de:

  • Políticas de umbrales.
  • Limitaciones inherentes a los navegadores.
  • Nivel de estado de una aplicación.
  • Tipos de mecanismos de migración tras error.
  • Problemas de seguridad.

Políticas de umbral

Considere tres tipos de políticas de umbral —recursos, usuario y solicitudes de datos. Para cada tipo de política, las pruebas de aplicaciones pueden tener un nivel de umbral diferente al de producción. Realice planificación de capacidad para preparar su sistema para la implementación de políticas de umbral.

La política de umbral de recursos asegura que el consumo de recursos se balancee dinámicamente para aplicaciones en la nube. El umbral de nivel se establece por debajo del número máximo de instancias de recursos adicionales que se pueden consumir. Cuando el consumo de recursos excede el nivel de umbral durante un pico en la demanda de carga de trabajo, se asignan instancias de recursos adicionales. Cuando la demanda retorna al nivel del umbral o por debajo, las instancias de recursos que se han creado se liberan y se asignan a otros usos.

La política de umbral de usuarios garantiza que los usuarios puedan tener acceso concurrentemente a la aplicación, hasta el límite especificado en la licencia de usuario del proveedor. Por ejemplo, una licencia que tenga un límite de 3.000 usuarios pero solo permite un máximo de 2.500 usuarios concurrentemente y su nivel de umbral está configurado en 2.000 usuarios concurrentes. Si el número de usuarios concurrentes está en o por debajo del umbral, la aplicación estará disponible de forma continua asumiendo que el consumo de recursos y las solicitudes de datos están por debajo de su respectivo nivel de umbral.

La política de umbral de solicitud de datos garantiza que las solicitudes de datos de la aplicación puedan procesarse inmediatamente. El umbral de nivel se establece por debajo del número máximo de solicitudes de datos y del tamaño máximo de solicitudes de datos que los usuarios pueden enviar concurrentemente. Si el número de solicitudes de datos excede el nivel de umbral, deberá aparecer un mensaje para mostrando cuántas solicitudes de datos están en fila esperando a ser procesadas.

Limitaciones inherentes a los navegadores

Si usted está utilizando Mozilla Firefox e Internet Explorer, ¿sabía que Firefox carga las páginas más rápido y que utiliza menos memoria que Internet Explorer? La principal limitación de Firefox es que se puede cerrar o resultar en una respuesta lenta debido a la indisponibilidad:

  • Los recursos adicionales después del consumo de recursos alcanzan la máxima capacidad de instancias de recursos.
  • Una ventana miniatura de umbral para alertarle cuando el consumo de recursos exceda el nivel de umbral.

Para arreglar el problema, asegúrese de que el consumo de recursos permanezca en o por debajo del nivel de umbral y de que la migración tras error de la redundancia de recursos de instancia esté funcionando.

Si la ventana e miniatura muestra que el consumo de recursos ha excedido el nivel de umbral, este deberá:

  • Mostrar un mensaje emergente sobre el exceso de consumo.
  • Solicitarle que cierre el navegador o hacer que el sistema efectúe una eliminación automática de procesos firefox.exe y reinicie el navegador.

Nivel de estado de funciones de aplicación

¿Sabe usted qué tan bien se está ejecutando el nivel de estado de las funciones de aplicaciones? El nivel de estado se refiere a qué tan bien se está comportando el estado de una función de aplicación cuando pasa a estados subsiguientes de otras funciones en la nube.

En este ejemplo bastante simplificado, mientras está en la nube el estado de la función de validación de información de tarjeta de crédito a ser utilizado para comprar un artículo al por menor para uso de negocios, va directamente al estado de función que envía la información a una cuenta de banco y luego va rápidamente al estado de la función que notifica al cliente que el artículo ha sido enviado a su dirección de negocios.

Si pasar de un estado a otro hace que la aplicación se ejecute más lento en la nube que en las instalaciones, considere las posibles causas:

  • Fallas en la lógica de aplicación que maneja las transacciones de negocios.
  • Nivel de umbral del recurso, usuario y/o solicitudes de datos configurado demasiado alto.
  • Instancias de recursos ineficientes que dan como resultado un nivel de estado a destiempo.
  • Usuarios o solicitudes de datos compitiendo por las mismas instancias de recursos.

Mecanismos de migración tras error

Los mecanismos de migración tras error aseguran la continuidad operacional durante eventos como impedir fallas de hardware, agotamiento de recursos o demoras de latencia prolongadas. Las excepciones incluyen actos de Dios, los periodos de indisponibilidad por mantenimiento programado del proveedor, o el corte accidental de líneas de fibra óptica.

Estos son algunos ejemplos de mecanismos de migración tras error a considerar:

  • Intercambio de carga redundante: Dos o más sistemas cargados con no más del 50% de la carga total. Cuando un dispositivo falla, otros dispositivos toman la carga con poca o ninguna interrupción o cambios en los niveles de umbral.
  • Redundancia de instancia de recursos: Dos o más instancias de recursos cargadas con no más del 50% de la carga total. Cuando un dispositivo falla, otros dispositivos toman la carga con pocos o ningún cambio en los niveles de umbral.
  • Redundancia de fila de solicitud de datos: Dos o más filas de solicitudes de datos cargados con no más del 50% de la fila. Cuando una fila falla, otras filas toman la carga con poca o ninguna interrupción o cambios.
  • Reintento de conexión alternativo: Si una interrupción de red dura más de dos minutos, se reconecta a otro servidor o máquina virtual a través de conexiones de red alternativas.

Problemas de seguridad

Si su compañía reporta ingresos superiores a US$ 1 mil millones al año, las nubes privadas pueden tener mejor relación costo-beneficio que las nubes públicas. Una nube interna privada tiene muchas de las mismas características de negocios que una nube pública pero con niveles mucho más altos de control en cuanto a seguridad, disponibilidad y mecanismos de migración tras error que los negocios pequeños con ingresos menores a US$ 1 millón.

Una nube privada interna le permite almacenar y obtener datos desde ubicaciones conocidas en una jurisdicción específica (como los Estados Unidos o Canadá). Es adecuada para almacenar sus datos sensibles, de cumplimiento, de privacidad y de prueba.

En contraste, los datos en una nube pública puede almacenarse en ubicaciones desconocidas y pueden no ser fáciles de recuperar. Las ubicaciones desconocidas no son adecuadas para almacenar datos de cumplimiento, privacidad, sensibles y de prueba.

Un problema de seguridad es si el administrador del proveedor puede acceder sin su permiso a sus datos sensibles, de cumplimientos, de privacidad y de prueba almacenados en ubicaciones conocidas. Otro problema es que los datos almacenados pueden estar en áreas geográficas donde las regulaciones de privacidad y cumplimiento difieran de aquellas de los países con las que usted esté familiarizado(a). Las leyes pueden variar de un país a otro con respecto a los controles de exportación de datos.

Antes de conceder permisos, las responsabilidades del administrador deben describirse en un contrato que establezca lo que puede y lo que no puede hacer en cuanto a acceso a sus datos, cuáles leyes sobre exportación de datos debe cumplir y cuáles políticas debe implementar para mitigar los riesgos de piratas informáticos estableciendo centros de Comando y Control (CnC) en la nube.

Los piratas informáticos tienen herramientas para detectar los datos que viajan desde su escritorio hacia ubicaciones desconocidas y viceversa. Las plataformas PaaS han sido usadas como centros (CnC) para dirigir operaciones de un botnet para uso en el rechazo distribuido de ataques de servicios (DDoS) y para instalar aplicaciones de malware en la nube. Los piratas informáticos pueden crear y desplegar aplicaciones maliciosas para:

  • Asignar instancias de recursos maliciosas.
  • Reconfigurar niveles de umbral en niveles absurdamente altos.
  • Cambiar el estado de una función aplicación hacia estados subsiguientes de funciones maliciosas.

En conclusión

Cambiar el comportamiento de una aplicación de estar dentro de las instalaciones a estar en la nube requiere de planificación, para resolver los problemas de permanecer proactivo en cuanto a hacer cambios de comportamiento después de que las aplicaciones se migren. Los equipos de desarrolladores, usuarios y analistas de negocios necesitan trabajar conjuntamente para el establecimiento de políticas de umbral, para superar las limitaciones inherentes a los navegadores, personalizar mecanismos de migración tras error, y considerar problemas de seguridad en la nube. El equipo El equipo notará que resolver los problemas facilita mucho más la tarea de ser proactivos mientras se efectúan cambios de comportamiento.

Recursos

Aprender

Obtener los productos y tecnologías

  • Consulte las imágenes de producto disponible en el IBM Smart Business Development y haga Pruebas en la Nube IBM.

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=784555
ArticleTitle=Cambio de comportamiento de las aplicaciones: Del interior de la empresa hacia la nube
publish-date=01162012