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.

Volver arriba

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?".

Volver arriba

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.

Volver arriba

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

• La autora trata políticas de umbral en los artículos "Balance workload in a cloud environment: Use threshold policies to dynamically balance workload demands" y "Cloud computing versus grid computing: Service types, similarities and differences, and things to consider."
  
  
• En los recursos para desarrollador de nube de developerWorks, descubra y comparta conocimiento y experiencia de desarrolladores de aplicaciones y servicios que están creando sus proyectos para implementación en la nube.
  
  
• Otros recursos developerWorks que coinciden con este artículo se pueden encontrar en SOA and web services at developerWorks y en industries at developerWorks.
  
  
• Siguientes pasos: Encuentre cómo acceder a Desarrollo IBM Smart Business y Pruebas en la Nube IBM.
  
  

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

• Únase al grupo de computación en nube de developerWorks.
  
  
• Lea todos los excelentes blogs sobre la nube en developerWorks.
  
  
• Únase al comunidad developerWorks, una red profesional y un conjunto unificado de herramientas comunitarias para conectarse, compartir y colaborar.
  
  

Sobre el autor

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• La pesadilla de tornarse reactivo
• Cambios de comportamiento proactivos
• Cómo puede usted continuar siendo proactivo
• En conclusión
• Recursos
• Sobre el autor
• Comentarios