Llegamos a ustedes gracias a:



Columnas de opinión

El Futuro de las Arquitecturas de Aplicaciones TI

Por: Bernard Golden, CEO de la firma de consultoría HyperStratus

[22/01/2010] En repetidas ocasiones he comentado sobre el impacto que el cómputo en la nube tendrá sobre las operaciones de TI. La creciente escala de datos dramáticamente cambia las expectativas de cómo son operados los data centers. En esta ocasión quiero volver a cómo el cómputo en la nube afecta las arquitecturas de aplicaciones TI, específicamente examinando uno de los elementos que fomentan el crecimiento de datos: la carga de aplicaciones. Puesto de manera sucinta, las presunciones que tradicionalmente hemos utilizado para diseñar arquitecturas de aplicaciones con cada vez más anticuadas debido a la naturaleza cambiante de las aplicaciones. Las arquitecturas de aplicaciones van a cambiar -tanto como las operaciones TI- en los siguientes cinco años debido a la naturaleza de las aplicaciones de cómputo en la nube.

¿Cuáles son las razones por las cuales las aplicaciones van a cambiar tanto? Todos esos grandes datos van a significar que las aplicaciones de software van a necesitar cambiar para manejarlos.
Las proyecciones de IDC indican que la compañía promedio experimentará un incremento de siete veces en datos no estructurados (piense en captura de clicstream -el registro de todo aquello a lo que el usuario de una computadora le da clic mientras navega por la web o utiliza aplicaciones de software- y almacenamiento de video, etc., etc.), acompañados por la duplicación de datos estructurados (piense en la información en filas y columnas de una base de datos). Realmente pienso que las proyecciones de IDC están minimizadas en el lado de los datos estructurados, debido a las presunciones limitadas que (muy razonablemente) trajeron a su análisis. La notable disminución en el costo de TI suscitado por el cómputo en la nube llevará -sin ninguna sorpresa para los especialistas en economía por doquier- a cantidades mucho más grandes de cómputo siendo realizado, lo cual, a su vez, llevará a arquitecturas de aplicaciones y topologías más grandes.
El uso de negocios de TI está cambiando
En el pasado, las TI eran usadas para automatizar procesos de negocios repetitivos -tomando algo que ya existía y computarizándolo. El arquetipo para esta clase de transformación es ERP- la automatización de las órdenes, los cobros y el rastreo de inventario. Ese enfoque de "pavimentar el camino de las vacas" a la computación está cambiando. Hoy, los negocios están entregando nuevos servicios infundidos y hechos posibles por las TI -en otras palabras, creando nuevas ofertas que no existirían sin las capacidades de TI-. Un ejemplo dramático de esto es la forma en que se han desarrollado los servicios de música. Pandora aprovecha el conocimiento de expertos para entregar flujos de canciones personalizadas a sus clientes; Pandora rastrea las preferencias y la retroalimentación de cada uno de sus escuchas para asegurar que cada uno recibe una oferta personalizada. El servicio de Pandora no podría existir sin el soporte de cantidades masivas de poder de cómputo, lo cual forma el núcleo del negocio. Menos dramático, pero no menos dependiente de la infusión de las TI, es el servicio personalizado ofrecido por las mejores cadenas hoteleras.
La atención personal que los empleados le ofrecen a los huéspedes -yendo mucho más allá del "prefiere un cuarto de no fumar" de antaño hasta, digamos, "le gusta ver teatro avant-garde y nuevas exhibiciones de museos"- permite una interacción altamente específica con los clientes. Y, adivine qué: todo está dirigido por nuevas aplicaciones.
La naturaleza de las aplicaciones está cambiando
Hasta ahora, la mayoría del cómputo ha sido dirigido por acciones humanas -alguien haciendo una compra, solicitando una página web, etcétera. En el futuro, un creciente porcentaje del cómputo será dirigido por actividades no humanas de dispositivos como sensores. Como ejemplo, se ha hablado mucho de la mudanza a medidores eléctricos inteligentes -en lugar de que su medidor sea leído por un humano que camina por su vecindario, el medidor en sí se conectará al data center de la compañía eléctrica y subirá su información de cobranza. Sin embargo, una de las otras características muy publicitadas de estos medidores inteligentes es su habilidad de dar lecturas de carga en tiempo real a los usuarios. Estos datos sobre el uso eléctrico -los metadatos, si quiere- serán invaluables para las compañías eléctricas, para ayudarles a comprender cómo cambia el uso con una retroalimentación inmediata en el precio. Esto resultará en aún más datos que solo una lectura mensual que se envía a sus data centers. Y –espere- esos datos serán transmitidos en patrones irregulares, llevando a cargas altamente variables, que afectan así la naturaleza de las arquitecturas de aplicaciones.
Dado cómo el número, tipo y naturaleza de las aplicaciones está cambiando, ¿qué implica esto para el futuro de las aplicaciones y, para hablar sobre el tema específico de este artículo, para la arquitectura futura de las aplicaciones? Las implicaciones están cuadruplicadas:
La variabilidad de la carga de aplicaciones se incrementará: El conductor para los vastos cambios en variabilidad de carga de recursos es la variabilidad de carga de aplicaciones. Para hoteles, los tiempos ocupados tradicionales son temprano en la mañana (checkout) y al final de la tarde y principios de la noche (checkin). En el futuro, la atención personalizada significará una alta carga de aplicaciones en otros momentos. En esencia, la carga de aplicaciones variará a lo largo de todo el día -todas sus 24 horas- en lugar de estar enfocada durante las horas de negocios. Las aplicaciones necesitarán ser mucho más capaces de escalar de manera dinámica.
Las interfases de las aplicaciones cambiarán: En lugar de estar enfocados en los humanos (y por lo tanto la pantalla), los datos se verterán en las aplicaciones desde otras aplicaciones, sensores, subida de archivos e, indudablemente, cosas que incluso no hemos pensado aún. Así que las interfases de servicio y las interfases de subir archivos se unirán a las interfases de terminales. Las aplicaciones necesitarán ser capaces de añadir nuevos flujos de datos con gracia y de manera dinámica.
Las características de las aplicaciones cambiarán: La importancia cada vez mayor de la geolocalización en las aplicaciones, demandará la habilidad rápida de cambiar de contexto y de conjuntos de datos. Si estoy manejando en un taxi, los servicios "cercanos" cambian rápidamente a medida que el auto se mueve por el camino. Ser capaz de redirigir datos dentro y fuera de grupos en funcionamiento rápidamente (sin mencionar ser capaz de mezclar contextos, ya que las aplicaciones soportan a mucha gente compartiendo un contexto "cercano") se volverá vital. Naturalmente, esto requiere un alto desempeño.
La topología de las aplicaciones se volverá más compleja: A medida que aumenten la escala y la variabilidad, los diseños de arquitectura deben cambiar. Yo hice sugerencias sobre esto cuando mencioné el uso de memcached (sistema de caching de objetos en memoria distribuida) como mecanismo de data caching utilizado para aumentar el volumen de trabajo. Las aplicaciones complejas generalmente incorporan procesamiento asincrónico para tareas de cómputo intensivo; las filas de mensajes generalmente son usadas como parte de este enfoque. Por lo tanto, las arquitecturas de aplicaciones necesitan cambiar para incorporar nuevos componentes de software y diseño de aplicaciones.
Pasos prácticos
¿Cuáles son algunos pasos prácticos que uno puede tomar para asegurar que su aplicación dirigida hacia la nube pueda soportar estos nuevos requerimientos de aplicaciones? Aquí hay algunas sugerencias:
1. Revise los componentes de software que planea usar en la aplicación. Muchos componentes de software fueron diseñados para ser usados en un ambiente estático, con una configuración manual y actualizaciones ocasionales. Un patrón de diseño común para estos componentes es el uso de un archivo "conf", el cual es editado a mano para configurar el contexto de componentes. Una vez que el archivo conf está completo, el componente es iniciado (o reiniciado), lee la información de configuración en la memoria, y se pone en operación. En un mundo de nube, en el cual el contexto cambia constantemente a medida que nuevas conexiones y puntos de integración se unen y se dan de baja, el modelo de "editar y reiniciar" es insostenible. Busque componentes que tengan interfases en línea para actualizar el contexto, y para añadir o borrar conexiones de manera dinámica. Nada es peor que desplegar una aplicación y luego darse cuenta de que alguna parte de ella no puede soportar realmente los cambios de la topología dinámica.
2. Planee el balance de carga a lo largo de la aplicación. Muchas aplicaciones soportan el balance de carga en la capa del servidor web, pero asumen números constantes (y direcciones IP) para los componentes de aplicaciones en otras capas. Con una muy grande variabilidad de carga, otras capas necesitan ser escalables y necesitan soportar el balance de carga para asegurar un volumen de trabajo consistente.
No diseñe una aplicación con la expectativa de que solo dos componentes de aplicaciones residirán en ciertas capas. Planee para dinamismo y balance de carga en todas las capas.
3. Planee la escalabilidad de las aplicaciones. Quizás esto es martillear el tema demasiadas veces, pero duplique o triple su planeación de capacidad y presuposiciones de arquitectura de aplicaciones -incluso quizás en una posibilidad de crecimiento de 10x. Cuando planifica para escalas mucho más grandes, le presta atención a los cuellos de botella y planea cómo aliviarlos de manera dinámica. Si no espera escalabilidad, no examinará sus presuposiciones de arquitectura de manera crítica. Así que revise su arquitectura buscando cuellos de botella de escalabilidad.
4. Planee actualizaciones dinámicas de aplicaciones. Hace cuarenta años, los fabricantes de autos tomaban dos semanas para cambiar sus fábricas y así prepararse para la fabricación de nuevos modelos. Toyota averiguó cómo hacerlo en dos horas. Eso significó que tuvieron que diseñar para actualizaciones dinámicas de la fábrica. El cómputo en la nube, con sus ciclos de uso de 24 horas, significa que no hay tiempo caído para las actualizaciones de las aplicaciones. Diseñar aplicaciones de modo que las topologías puedan ser cambiadas mientras los usuarios continúan accediendo a los servidores individuales requiere una planeación como la de Toyota. Igualmente, actualizar esquemas de bases de datos (y conjuntos de datos) para soportar nuevas versiones de aplicaciones necesita enfoques como los de Toyota.
Bernard Golden, CIO.com
Bernard Golden es CEO de la firma de consultoría HyperStratus, la cual se especializa en virtualización, cómputo de nube y temas relacionados. Él también es el autor de "Virtualización para Dummies", el libro más vendido sobre virtualización a la fecha.