Este artículo expone los cambios que éstos y otros roles tendrán durante la adopción de esta inevitable tendencia además de exponer las nuevas habilidades y estándares que exige el cómputo en la nube.

José Luis Rodríguez Gómez, Software IT Architect , IBM

author's photoJosé Luis Rodriguez Gómez es Maestro en Ciencias por la Universidad de Essex. Cuenta con 10 años de experiencia en el diseño, desarrollo y arquitectura de aplicaciones empresariales Java para el sector público y financiero. Ha sido responsable de práctica para las disciplinas de Diseño, Implementación y Arquitectura de software en Softtek. Desde 2009 forma parte de IBM Software Group como Arquitecto de Software para los Software Solution Labs Latinoamérica y es responsable de la habilitación del Cloud Center de Software Group en IBM México. Ver Perfil en My developerWorks



28-12-2010

Introducción

Cloud Computing se ha convertido en el siguiente gran tema de moda en el ámbito de las TIs y que resonará con mayor fuerza en el futuro próximo. Pero este tema de moda no es sólo ruido mercadológico o una burbuja tecnológica, Cloud Computing trae beneficios reales y a corto plazo para los ejecutivos y departamentos de empresas tanto chicas como grandes. Evidentemente los roles directamente beneficiados son el CFO, CIO y CTO ya que reciben directamente las ventajas de la agilidad, maximización de recursos de cómputo y reducción de costos. Sin embargo poco se habla del beneficio y de los cambios que la nube trae para los roles más técnicos como el Arquitecto de Software, el programador de Software, el DBA, el líder de QA, diseño y construcción. Este artículo expone los cambios que éstos y otros roles tendrán durante la adopción de esta inevitable tendencia además de exponer las nuevas habilidades y estándares que exige el cómputo en la nube.


Si soy Arquitecto de Software ¿por qué debo interesarme en la cloud?

El arquitecto de software tiene la mayor responsabilidad ante los cambios que trae la cloud. El arquitecto de aplicaciones trabajará con ambientes virtualizados tal y como lo ha estado haciendo, sin embargo el arquitecto de soluciones de software deberá considerar ahora nuevos beneficios y nuevos retos arquitectónicos. Los más notables dentro de la arquitectura será con dos grandes beneficios: Estandarización y automatización.


Estandarización mediante patrones

Para el caso de clouds privadas, el arquitecto ahora tiene la opción de definir plantillas de componentes o topologías de software (por ejemplo máquinas virtuales, middleware, capas aplicativas o políticas) que serán replicadas en ambientes de desarrollo, QA o producción en el modelo cloud. Por ejemplo, puede definir en el catálogo de servicios del cloud privado, un patrón con un servidor de aplicaciones en cluster y un componente de autenticación federada que luego será aprovisionado automáticamente mediante un portal de autoservicio para un equipo de pruebas en una línea de negocio a la que antes no tenía acceso.

Este paradigma ayuda a propagar estándares arquitectónicos y políticas a lo largo de la empresa sin que sea difícil su adopción.

El arquitecto será responsable de seleccionar primero si la carga que el tipo de carga que va a enviar a la nube, ya sea privada, híbrida o pública, además tendrá que decidir sobre los estilos de cloud que va a consumir. Sobre todo tendrá que definir los estilos


Externalización de Requerimientos no funcionales

El arquitecto ahora debe extender su criterio sobre los requerimientos no funcionales aplicados en un sistema ya que ahora tiene la opción de tercerizar ciertos criterios en clouds públicas como la calidad en el servicio (QoS), disponibilidad y mantenibilidad. Esta externalización trae consigo ahorros y tal y como en un esquema sin cloud, esto trae riesgos que se pueden mitigar mediante acuerdos de niveles de servicio entre el proveedor y el consumidor.


Decisiones de diseño para la cloud

No todos los tipos de cargas de trabajo están hechas para la cloud así que antes de considerar su uso es importante hacerse las siguientes preguntas:

  • ¿Cuál es la carga transaccional y/o ancho de banda necesaria para la solución? Escenarios altamente transaccionales o de uso alto de red en una cloud pública no son viables si la latencia de red es crítica en la solución o si el costo de ancho de banda vuelve inviable a la misma. Se prefiere una cloud privada para estos casos.
  • ¿El proveedor (cloud pública) o mi cloud privada tiene contemplado niveles de servicio que se acomoda a mi necesidad? Al delegar los requerimientos no funcionales a un tercero es indispensable verificar el grado de disponibilidad del proveedor para acomodarlo a la solución. Existen niveles de disponibilidad de 95% al 99.999% que se adaptan a cualquier bolsillo.
  • ¿Qué nivel de aislamiento de recursos se requiere? El aislamiento en las soluciones de Cloud Computing puede aplicar a varios niveles y capas: red, aplicación, middleware, administración, seguridad. Por ejemplo un cliente no debe ser capaz de alcanzar la red de otro cliente en una cloud pública o bien en un esquema de SaaS (Software as a Service) el middleware o bases de datos no deben ser accesibles entre diferentes clientes. Aun así, para abaratar un servicio de SaaS por ejemplo podría ser viable compartir recursos entre clientes aislando el acceso a éstos mediante capas de acceso bien definidas.

Seguridad

La seguridad ha sido uno de los tópicos que más ha preocupado a los adoptadores de cloud sobre todo en el cloud público, donde se delega el control y propiedad de la infraestructura a terceros. Este problema no se resuelve de una sola manera ya que depende de los riesgos y necesidades de cada sistema a definir. El arquitecto debe ahora considerar y repensar el requerimiento no funcional de seguridad cuando usa la cloud. Podemos resumir las preocupaciones aclarando las siguientes preguntas:

  • ¿Qué políticas o legislaciones debe que cumplir?
  • ¿Qué información dejará en la cloud y que se queda en nuestras instalaciones?
  • ¿Qué nivel de aislamiento (datos, red, aplicación) necesitas?
  • ¿Qué actividad necesita a monitorear?
  • ¿Dónde están mis agresores potenciales?
  • ¿Cómo voy a autorizar el acceso a los recursos en la cloud?
  • ¿Qué políticas de confidencialidad de datos necesita cubrir entre clouds
  • ¿Qué planes de respaldo se requieren?

Para el caso de las clouds públicas multicliente (multitenancy) cobra mayor relevancia el manejo de la infraestructura de red y el aislamiento. Algunos proveedores de SaaS pueden ofrecer una aplicación a varios clientes usando la misma base de datos. Si se elige un servicio SaaS es necesario asegurarse de que la aplicación y sus medios de acceso alternos (generalmente mediante APIs) sólo sean accesibles para un cliente. Lo mismo ocurre si se es un proveedor de SaaS, es necesario establecer los mecanismos de seguridad para acceder a los datos de la aplicación. Para proveedores de IaaS (Infrastructure as a Service) es importante remarcar establecer esquemas de monitoreo desatendido del uso de la infraestructura para evitar que la cloud se convierta en una cloud de hacking respetando la privacidad de nuestros clientes.
IBM cuenta con un marco de trabajo (IBM Security Framework) que permite mitigar éstos y otros riesgos.


Escalabilidad dinámica

El arquitecto puede también explotar el uso de la cloud para ofrecer soluciones creativas a requerimientos de escalabilidad. Por ejemplo, puede disponer de recursos dinámicos para incrementar la capacidad de un cache distribuido o bien puede delegarle a una capa de monitoreo-automatización el incremento o reclamo de nodos de un cluster dependiendo de la demanda. Si bien estos conceptos han estado presentes desde hace algún tiempo, el hecho de tomar recursos de un pool y regresarlos para que sean reutilizados por otros procesos facilita su aplicabilidad e incrementan a su vez el retorno de inversión de estas soluciones, además este tipo de patrones de uso de la cloud explotan su naturaleza de automatización.

Figura 1. Escenario de escalabilidad dinámica con una Cloud Computing.

En un ejemplo de escalabilidad dinámica (Figura 1) con una cloud privada por ejemplo, los clientes de cierto cache pueden hacer uso indiscriminado uno o varios nodos del caché (1) cuando el monitor de recursos de la cloud observa en cierto nodo un uso de memoria o procesador que excede cierto límite (2) dispara un evento que invoca un servicio del catálogo de servicios ofrecido por la cloud (3). Si hay recursos disponibles en el pool, el motor de automatización se comunica con el hipervisor para aprovisionar un nodo más al caché (4). También informa al administrador de caché que se ha agregado un nuevo nodo para que otros clientes sean informados (6) y lo utilicen (7).


Si soy desarrollador o fábrica de software ¿por qué debo interesarme?

El modelo de cloud computing para desarrollar es muy interesante tanto para programadores de garage cómo para fábricas de software multinacionales. Para los primeros, este nuevo modelo de consumo en efecto reduce la brecha tecnológica acercando las herramientas de desarrollo y las plataformas de ejecución que antes eran difíciles de adquirir por las masas. Por ejemplo, ahora un desarrollador con una tarjeta de crédito puede tener acceso a un ambiente de pruebas de Power 7 con una familia de productos de desarrollo profesional de Rational. O bien puede ser contratado por un fábrica de software off-shore y su entorno de desarrollo colaborativo será aprovisionado en la cloud pública para él y todos los miembros del equipo.
Para empresas pequeñas a grandes, ya sean fábricas de software o empresas con equipos de desarrollo y pruebas, pueden agilizar sus ciclos de entrega mediante una cloud privada proporcionando a los equipos mencionados medios para que generen plantillas y automaticen los ambientes de desarrollo o procesos de integración continua. Esto se suma al beneficio en costos que trae la maximización de utilización de su capacidad de cómputo-almacenamiento y a la agilidad de la disposición y reclamo de la misma.
Los desarrolladores verán con mayor frecuencia el uso de ambientes virtualizados para ejercer su día a día y los líderes del grupo tendrán asignados permisos y topes de memoria y storage en el portal de autoservicio para asignar máquinas virtuales a los miembros de sus equipos, no es necesario más involucrar al departamento de IT para habilitar una desktop de desarrollo o pruebas.
Ahora ya existen ambientes de desarrollo con alto grado de integración que permiten un despliegue de una aplicación web, creación de servidores de integración continua, seguimiento a defectos y tareas directamente en la cloud pública liberando de recursos a la máquina del desarrollador, ofreciendo más opciones para el despliegue y sobre todo acelerando el tiempo de entrega.


Si soy Líder de QA o Tester ¿por qué debe interesarme?

Se estima que hasta el 30% de los defectos generados en una aplicación se provocan por los ambientes en los que se ejecuta, además se estima que el 30% al 50% de los servidores que una empresa adquiere están dedicados a la ejecución de pruebas. Esto nos indica la relevancia de Cloud Computing en la disciplina de pruebas y el tipo de beneficios directos que trae. El líder de pruebas siempre debe exigir ambientes predecibles en los que su equipo pueda trabajar y éstos deben ser dispuestos en el menor tiempo posible de lo contrario contará con defectos no asociados a la aplicación y tiempos muertos. Las características de repetibilidad y automatización de cloud le permiten asegurarlo.

One Click Deployment

Los equipos de testing deben exigir el estilo One-click-deployment para preparar sus ambientes e instalar la versión de prueba de la aplicación de forma ágil, de otra forma estarían desaprovechando las ventajas del Cloud Computing, aun en clouds privadas. Si su cloud no tiene esta capacidad evalúen otras que sí lo hagan.


Si soy Administrador de TI ¿Por qué debe interesarme?

Tarifas y métricas de uso

Además de los beneficios de agilidad y optimización de recursos conocidos, los administradores de TI tienen un incremento de visibilidad en el consumo de los recursos de cada área o proyecto. Ahora pueden cobrar detalladamente a las áreas de negocio o al proyecto el uso de los recursos virtualizados que utilicen (almacenamiento, máquinas virtuales por ejemplo) ya que el modelo de cloud aporta métricas de uso, aun en cloud privadas.


Si soy Arquitecto de Datos ¿por qué debe interesarme?

Nuevas tendencias de alta escalabilidad y MapReduce

La facilidad de acceso a la escalabilidad horizontal a la que se puede llegar con cloud computing puede acelerar la adopción de algoritmos de escala como MapReduce.
MapReduce es un framework promovido por Google™ que permite distribuir la ejecución de una función (por ejemplo una búsqueda textual, un cálculo o una transformación) de forma paralelizada. Un nodo maestro en el paso "map" del algoritmo subdivide los datos y distribuye la ejecución de una función a nodos hijos, estos podrían subdividir el trabajo aún más hacia otros. Los nodos maestros agrupan y propagan estas respuestas hacia arriba en la jerarquía. Este método es altamente escalable y cloud computing facilita la implementación de este Framework agregando elásticamente tantos nodos como sean necesarios para cierta búsqueda y reclamarlos de regreso al pool. IBM utiliza este patrón por ejemplo en el campo analítico de datos no estructurados con BigSheets

Si bien estas tendencias tomarán mayor relevancia en la próxima década no son la solución a todos los problemas pero los arquitectos de datos pueden agregar esta tecnología a los estándares empresariales como una forma innovadora de cumplir ciertos requerimientos de datos de una empresa. La segmentación o particionamiento de datos puede tomar otra dimensión con cloud computing.

Compartir o no compartir. Multitenancy.

Cuando se provee una aplicación como SaaS es parte del proceso de diseño de la solución elegir la ubicación y accesibilidad de los datos. Por ejemplo para ahorrar costos de licenciamiento o procesamiento es posible diseñar una aplicación y proveerla como SaaS que comparta una sola base de datos para varios clientes. Esto será válido siempre y cuando las políticas de nuestros clientes potenciales lo permitan y la aplicación y sus puntos de acceso esté diseñada teniendo en cuenta la seguridad de datos.

En otros casos esto no será posible, el cliente puede requerir por ejemplo una instancia de base de datos exclusiva y puntos de acceso para explotar su información. Este es el típico escenario multitenancy (o multicliente) que el arquitecto de datos debe considerar al modelar los datos una aplicación para la cloud.


Si soy Build Meister ¿por qué debe interesarme?

Integración continua para la cloud

La integración continua es una práctica que ha cobrado mucha relevancia y con el tiempo se ha vuelto más sofisticada. Ahora es posible agregar a nuestro sistema de integración continua etapas para aprovisionar uno o más servidores con la configuración deseada (parches, sistema operativo, middleware) e instalar la versión de la aplicación para ejecutar luego por ejemplo pruebas automatizadas o de carga. Al finalizar el ciclo de pruebas los recursos de cómputo no utilizados como procesamiento, almacenamiento y memoria pueden ser reutilizados por otras fases o ramas de esfuerzo en el proyecto.
La eliminación del factor humano en la Integración continua ya reducía los tiempos de ciclo en la operación, pero ahora con los errores que se pueden ahorrar por una configuración del ambiente repetible, cloud computing se vuelve un multiplicador del beneficio en esta disciplina.


Nuevos roles y nuevos estándares

Especialista en automatización

Con la explosión de recursos solicitados (pensemos en miles de VMs) es imposible tener a administradores de TI que aprovisionen y administren esos recursos. El autoservicio o la reducción de la intervención humana es parte fundamental del paradigma de cloud computing; de hecho la automatización es lo que le da la agilidad a cloud computing.
Esta capacidad permite que se ejecuten actividades desatendidas como la instalación de software, la creación y configuración de componentes de red virtuales (switches, VPN, firewalls), aprovisionamiento de máquinas virtuales, montaje de discos, entre otros.
Esta característica es alcanzable mediante motores de automatización flexibles que ejecutan scripts parametrizados y que pueden interactuar con prácticamente todas las capas que habilitan a la cloud (Figura 2)

Figura 2 – Capas que habilitan a la cloud y área de acción de la automatización

Para visualizar la importancia de la automatización desde otro ángulo, si imaginamos un catálogo de servicio de donde podemos elegir el aprovisionamiento de por ejemplo una máquina virtual con un conjunto de software instalado, es preferible generar una máquina virtual y elegir las opciones de software a instalar (mediante scripts de instalación) y no generar varias VMs con el software preinstalado ya que complicaría el mantenimiento por las combinaciones de software que nuestros clientes puedan elegir.


Estándares de virtualización para la agilización de la automatización

Actualmente el colectivo Distributed Standard Management Task Force, donde IBM forma parte, ha definido el estándar OVF y OVA (Open Virtual Format y Open Virtual Archive). Esta definición no se enfoca en un formato de archivo binario o de un ambiente de ejecución para crear máquinas virtuales si no en la especificación de los metadatos que acompañan a una máquina virtual para ser instalada o configurada en algún ambiente virtualizado.
Por ejemplo es posible establecer en un OVA (un tarball con un OVF y con un conjunto de archivos utilitarios), el usuario o contraseña de root de la vm, la dirección IP, referencias a licencias o a certificados digitales. Estos parámetros serán procesados por los motores de automatización para configurar y poner a punto cierta máquina virtual.
Estos estándares cobrarán más relevancia con Cloud Computing y tendrá que ser parte de los estándares en el día a día del especialista de automatización.

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=605327
ArticleTitle=¿Por qué debe interesarme cloud computing?
publish-date=12282010