Llegamos a ustedes gracias a:



Columnas de opinión

Definiendo Nubes Privadas, Parte II

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

[29/06/2009] Como se anotó en el artículo pasado, las nubes privadas son un tema de moda en estos días, pero no todo el mundo concuerda en una definición o los beneficios potenciales. Según mi punto de vista, construir una nube privada ofrece:

1. Un rol para la infraestructura existente: En lugar de tratar los data centers llenos de equipo como basura obsoleta, una nube privada puede incorporar infraestructura existente en una nube nueva localizada internamente.

2. Agilidad y escalada de las aplicaciones: Uno de los retos clave para los data centers internos -manejados tradicionalmente- es la incapacidad de las aplicaciones individuales de crecer rápidamente cuando son confrontadas con enormes aumentos en tráfico. Igualmente, las aplicaciones ofrecen un pobre desempeño económico cuando los recursos son puestos en lugar para responder a las demandas pico y se mantienen dedicadas a una aplicación, incluso cuando esto ya no es necesario. En esencia, en las prácticas tradicionales los recursos son pegajosos -difíciles de hacer que se muevan y difíciles de eliminar-. Poniendo una nube privada en su lugar, las aplicaciones que necesitan espacio adicional no se golpearán más con el techo de un equipo, ni sufrirán de pobre desempeño.
3. Riesgos menores de seguridad y privacidad: Muchas organizaciones TI están renuentes a mover muchos de sus datos a nubes públicas compartidas debido a una preocupación de que puede haber riesgos que no existirían, si los datos fueran mantenidos dentro del data center corporativo. Al implementar una nube privada, estas preocupaciones son zanjadas.
Desde un nivel de 30 mil pies, ¿qué podría no gustarte sobre esta visión? Todos los beneficios del cómputo en la nube, con ninguna de las desventajas de los servicios de la nube pública.
Sin embargo, pocos detalles están disponibles desde el nivel de 30 mil pies, y cuando los detalles son examinados desde una posición cercana de ventaja, muchas de las características clave necesarias para implementar una nube privada, pasan a ser el centro de atención.
Este artículo examina los requerimientos que acompañan a una nube privada, de modo que las organizaciones TI tengan un mejor entendimiento de qué acciones necesitan tomar para conseguir su visión de cómputo en la nube.
El hecho fundamental que entra en juego es que la funcionalidad de las nubes privadas impone una línea divisoria entre el aprovisionamiento de inventario TI y el consumo de recursos TI. En términos de los grupos asociados con estas dos actividades, pueden ser identificados como grupos de operaciones de data center y grupos de aplicaciones de negocios. La visión del cómputo en la nube es que alguien en el último grupo, que quiere crear o correr una aplicación que requiere recursos TI, puede empujar botones (en un mouse, claro) y tenerlos provistos -todo sin interacción humana-. Las responsabilidades del grupo de operaciones del data center residen en asegurar que suficientes recursos están en su lugar y disponibles para poder ser utilizados en un aviso del momento.
La semana pasada, discutí las responsabilidades y las capacidades de servicio clave necesarias por las operaciones de data center (u operaciones de infraestructura TI, para darle una descripción más formal) para implementar el cómputo en la nube. Esta semana, examino la funcionalidad de la nube privada desde la perspectiva de los grupos de aplicaciones de negocios; en otras palabras, qué servicios necesitan estar instalados para estos grupos. Puede referirse al cuadro que acompañó el artículo de la semana pasada para seguir con la discusión que viene.
La forma correcta de leer el cuadro es desde el centro hacia afuera. Los recursos de hardware y software que entrelazan ambos grupos están localizados en el centro del cuadro. Esto refleja el hecho de que los recursos de TI son la base del cómputo en la nube, y que ambos grupos están involucrados con ellos -pero con perspectivas muy diferentes sobre ellos, y formas muy diferentes de interactuar con ellos. Sin embargo, los recursos de hardware y software están en el centro del cómputo en la nube, porque es, finalmente, sobre una forma diferente de organizar y desplegar recursos TI. La perspectiva diferente y los diferentes mecanismos de interacción están indicados por la oscura línea rota que corre a lo largo de la tabla horizontalmente: debajo de la línea rota, los servicios son aquellos pertinentes a las operaciones de infraestructura TI, los cuales deben poner las funciones en su lugar para soportar el cómputo en la nube; sobre la línea rota, los servicios son aquellos necesarios para los grupos de aplicaciones para usar el cómputo en la nube como parte de sus actividades de aplicación.
El siguiente nivel fuera (encima) de los recursos centrales representa cuatro funciones clave (o servicios) que deben estar instalados para que los grupos de aplicación de negocios aprovechen el cómputo en la nube. Estos cuatro servicios son:
Aprovisionamiento ágil: El aprovisionamiento ágil es lo que mucha gente considera la totalidad del cómputo en la nube. El aprovisionamiento ágil significa que los recursos TI pueden ser solicitados sobre una base dinámica, a través de algún tipo de sistema automatizado. El principal ejemplo es Amazon Web Services: obtener una máquina virtual que trabaje y funcione puede ser logrado en menos de 10 minutos. Lo que esto implica para una nube interna es la habilidad para un usuario de recursos TI de producir recursos de cómputo tan rápido como él o ella puedan desde Amazon. En esencia, la demanda por aprovisionamiento ágil al estilo Amazon es análogo a la presión que los grupos TI sintieron cuando los usuarios finales siguieron molestándolos sobre por qué las aplicaciones internas de la compañía no eran tan sencillas de usar, como las aplicaciones basadas en web o productos como iTunes. En este caso, Amazon Web Services ha establecido una nueva expectativa sobre qué tan rápido pueden estar listos los recursos TI.
La visión de aprovisionamiento ágil es que un usuario de recursos debería ser capaz de acceder a una página web y configurar al vuelo una nueva infraestructura de aplicación -una cierta cantidad de recursos de cómputo, memoria, almacenamiento y ancho de banda de red (de hecho, la última es probablemente no configurable, ya que la mayoría de data centers tienen capacidad de ancho de banda consistente, lo que hoy significa 1GB o 10GB)-. En la práctica, es poco probable que haya flexibilidad ilimitada de recursos; más probable es algo como Amazon, donde puedes elegir desde tres o cuatro diferentes configuraciones de capacidad, un tipo de arreglo pequeño, mediano y grande.
Clave para este aprovisionamiento ágil es el concepto de orquestación, donde una simple solicitud puede coordinar un número de diferentes acciones, todas coordinadas para crear el resultado deseado. Uno puede pensar en esto como un proceso coordinado de negocios; esta orquestación alcanza al almacenamiento virtual, red y máquinas inventariadas por las operaciones de infraestructura TI para crear una completa instancia de cómputo para el solicitante. No puede ser suficientemente enfatizado cuán crítico es esto para el concepto de una nube privada; sin aprovisionamiento ágil, las nubes privadas recaen a nada más que operaciones de TI más eficientes, en lugar de hacer las TI más receptivas a las iniciativas de negocios. Espere mucho más énfasis en este tema cuando el concepto de nubes privadas obtenga mayor concientización.
Administración de aplicaciones: Ya que mucho del ímpetu por las nubes privadas (y nubes públicas, en cualquier caso) es mover el control de la computación más cerca de los usuarios, una función clave que debe estar disponible para los grupos de aplicaciones de negocios es ser capaz de monitorear y administrar sus aplicaciones. En algún sentido, el rol de las operaciones se está bifurcando, con las operaciones de infraestructura permaneciendo con el grupo de operaciones del data center, y la administración de los componentes de software que conforman una aplicación residiendo con los grupos de aplicaciones.
Uno puede esperar que esto sea una transición complicada, ya que las operaciones hoy se extienden a las aplicaciones, las estructuras de base y los componentes (como las bases de datos), y el hardware. Haciendo eco de Amazon, donde Amazon mantiene responsabilidad por la infraestructura de cómputo mientras que los desarrolladores de aplicaciones son responsables por los componentes de las aplicaciones, busque que la administración de las aplicaciones haga la transición por encima de la línea. Nuevamente, este es un servicio disponible para el grupo de aplicaciones, el cual estará disponible para controlar de manera más directa los componentes de software que se han desplegado para satisfacer las metas de negocios.
Escalabilidad: Los usuarios de la nube esperan que la topología de las aplicaciones se expanda o contraiga según sea necesario para corresponder con las necesidades de la aplicación y contar así con disponibilidad de recursos. Puesto de otro modo, debe ser fácil hacer que la cantidad de recursos de cómputo consagrados a una aplicación sea congruente con la carga de cómputo. Como se ha practicado tradicionalmente, este es uno de los aspectos menos flexibles de las operaciones del data center. Ya que los recursos de cómputo tienden a ser pegajosos, las aplicaciones generalmente tienen insuficientes recursos disponibles cuando son necesarios, con poca habilidad de modificar la disponibilidad de recursos en lapsos de tiempo aceptables.
En el mundo de las nubes privadas, los grupos de aplicación esperan que sea fácil añadir o sustraer recursos según sea apropiado. De hecho, los grupos de aplicación esperan que el sistema de administración de aplicaciones monitoree el desempeño del sistema y el uso de recursos, y automáticamente ajuste los recursos disponibles a un nivel apropiado.
Cobro retroactivo: La habilidad de cobrar de acuerdo con los recursos consumidos en lugar de por una cantidad fija de capacidad asignada. El hecho de que el concepto de cobro retroactivo sea una parte integral de las nubes privadas es controvertido. Algunos sostienen que se debe poner un precio muy granular al cómputo en la nube para operar efectivamente; otros mantienen que el modo de pago es incidental a la escalabilidad y la flexibilidad del compromiso que son las verdaderas características distintivas del cómputo en la nube. La práctica típica instalada para las TI internas hoy en día es aquella en que sobre el pedido de recursos de cómputo (por ejemplo, una máquina de cuatro procesadores con 16GB de memoria, 50GB de almacenamiento y 8 NIC) se carga un cobro de capital, lo que significa que el costo general de la adquisición del sistema (tal vez ocho mil dólares en este caso) es transferido del grupo solicitante a la organización de TI; además, los costos operativos para el grupo TI (personal, complejos, etc., etc. hasta las donas que se comen cada viernes) son aplicados mediante prorrateo a las organizaciones consumidoras de TI.
La visión común para el cobro retroactivo de una nube privada es que se cobra un costo estándar para recursos TI altamente granulares (por ejemplo, horas de cómputo de una configuración mediana) a la aplicación consumidora, el cual es pagado por el grupo de negocios responsable por la aplicación. Fuera de esta visión está cómo los gastos generales deberían ser manejados en una nube privada.
Algunos sienten que los gastos generales deberían ser considerados como factores en el precio granular; otros sienten que la disposición actual de los costos generales debería continuarse, mientras que los recursos granulares deberían ser cobrados con base en el uso.
Mi visión es que el cobro retroactivo es muy importante, no porque sea más justo, sino porque el precio es un importante mecanismo de racionamiento -y racionar los recursos de cómputo será más importante en un ambiente donde obtener los recursos es tan fácil como llenar una forma web, con lo cual los recursos son automáticamente aprovisionados a través del mecanismo de orquestación instalado-. Esto nos lleva al siguiente nivel del cuadro.
El siguiente nivel no son componentes de software que soportan una visión de usuario de las nubes privadas; en lugar de eso, estos elementos son artefactos organizacionales o procesos que necesitan ser instalados para soportar el cómputo de la nube privada. Para reiterar algo que he dicho en este artículo y el previo, el cómputo en la nube requiere que la intervención manual y la interacción humana sean removidas de la solicitud, asignación y consumo de los recursos de cómputo.
Con la eliminación de la tradicional reunión de solicitud de recursos y aprobación que lleva a alguien en el grupo de operaciones asignando recursos, se necesita implementar procesos organizacionales de manera que permitan que aquellas clases de revisiones y balances sean realizados fuera del sistema de automatización -eso actúa como una entrada para el sistema de información y puede ser revisado dinámicamente para su aprobación por los sistemas en ejecución-. El nivel al que nos estamos refiriendo refleja esos procesos.
El punto central en este nivel se basa en el término dirección, lo cual cubre los procesos institucionales en los cuales son definidos importantes procesos de aprobación junto con requerimientos de aprobación mínimos, al igual que cualquier grupo organizacional que esté involucrado en el proceso de aprobación. Así que, por ejemplo, las organizaciones TI generalmente tienen una Junta de Revisión de Fuente Abierta a quienes se remite las solicitudes de usar componentes de software de fuente abierta; la junta revisa las solicitudes bajo la luz de la Política de Fuente Abierta establecida para determinar si aprobar o no la solicitud. La combinación de política, procesos y organización constituyen la dirección de fuente abierta.
Con respecto al cómputo en la nube, la dirección aborda cómo la organización decide quién puede solicitar recursos de cómputo, cómo se aprueba la solicitud, y así. Todo esto toma lugar antes del acto físico de llenar la forma de solicitud basada en web. Las reglas que gobiernan la solicitud de recursos necesitan ser capturadas en reglas (por ejemplo, en un motor de políticas) que están integradas con un sistema de administración de identidad para implementar solicitudes de recursos que se alinean con la política de nube aprobada. En resumen, la dirección establece los límites dentro de los cuales se permiten las solicitudes de recursos de la nube, lo cual facilita los procesos automatizados de asignación de recursos. Una forma de pensar en esto es que toma los procesos organizacionales existentes, relativamente desorganizados, para asignar los recursos y los estructura en un formato que puede ser capturado en reglas automatizadas, mientras pone en funcionamiento un cuerpo de gobierno que monitorea el sistema en general.
Un registro clave para esto son las restricciones legales y regulatorias en la organización relativas al cómputo, y particularmente al manejo y almacenamiento de datos. Este proceso organizacional es representado a la izquierda de Dirección en el cuadro. Para tener una sensación de los temas involucrados con esto, lea el reciente reporte de la Alianza para la Seguridad en la Nube. Sin embargo, para que las nubes privadas den fruto (o, para el caso, para que las nubes públicas hagan lo mismo), las restricciones de privacidad relacionadas con el almacenamiento de datos deben ser codificadas y capturadas en una forma dócil para la automatización. Otra vez, si se debe convocar una reunión para discutir dónde deben ser colocados los datos a la mitad del proceso de aprovisionamiento, hay un hueco en la estructura de la nube. Las restricciones legales y regulatorias bajo las cuales opera la organización deben ser definidas y puestas en forma de reglas, las cuales pueden ser ejecutadas durante el proceso de aprovisionamiento. Sé que parece que le estoy dando y dando sobre esta cosa de la automatización, pero esta es un área donde los defensores de las nubes privadas y los expertos en seguridad aún no han meditado sobre las implicaciones de sus recomendaciones. Créanme, a menos que la privacidad (y el proceso general de aprobación que está contenido dentro de la Dirección) sea automatizada, no tendrá cómputo en la nube.
Igualmente, en esta capa de nubes privadas está la función SLA; esto está representado a la derecha de Dirección en el cuadro. Un SLA es, dicho de manera simple, un acuerdo de negocios sobre el nivel de rendimiento de cómputo esperando por la organización usuaria y entregada por la organización de operaciones. Esto no es nuevo. SLA son un elemento básico de los acuerdos de outsourcing y son generalmente instalados también para TI internas. La única diferencia en una nube privada es el impacto potencial de una estructura automatizada y las aplicaciones diseñadas para la nube que residen dentro de esa estructura. Podría ser muy bien el caso que las SLA necesitaran ser ajustadas para tomar en cuenta el ambiente de cómputo en la nube en el cual operan las aplicaciones. Sorprendentemente, el ajuste podría muy bien estar operando, ya que las aplicaciones estructuradas para la nube son generalmente menos vulnerables a las fallas de hardware debido al diseño de escalabilidad construido dentro de la aplicación. En cualquier caso, hay que encargarse de las SLA porque las expectativas de disponibilidad están siempre presentes y por tanto necesitan ser delineadas.
Esto completa la revisión de la nube privada, vista desde la perspectiva del grupo de aplicaciones de negocios. Para resumir nuestro viaje hasta ahora:
Moverse al cómputo en la nube dentro de un data center interno ofrece la oportunidad de ganar muchos de los beneficios de la nube, evitando algunas de las desventajas como problemas de privacidad de datos y la dependencia en proveedores externos no probados. Moverse a una nube privada interna requiere que los procesos manuales informales sean definidos y capturados en reglas para soportar un proceso de aprovisionamiento automatizado. La necesidad de automatización impone una división entre las operaciones de data center (el proveedor de la nube) y los grupos de aplicaciones de negocios (los usuarios de la nube), quienes deben ser capaces de coordinar a través de límites de servicio bien definidos que son operados por automatización. Muchas de las políticas basadas en papel o implementadas por reuniones o discusiones verbales, necesitan ser codificadas y capturadas en software para asegurarse de que los servicios puedan operar y de que la estructura de la nube está intacta.
CIO.com
Bernard Golden es CEO de la firma de consultoría HyperStratus, especializada en virtualización, cómputo de nube y temas relacionados. También es el autor de "Virtualización para Dummies", el libro más vendido sobre virtualización a la fecha.