Llegamos a ustedes gracias a:



Columnas de opinión

CIO Cloud: Tres escenarios de uso de una cloud privada

Por: Bernard Golden es CEO de la firma consultora HyperStratus

[07/04/2011] Ya es común que la mayoría de las organizaciones de TI estén planeando una estrategia de infraestructura de TI que incluye la computación en la nube, y donde una nube interna (también conocida como nube o cloud privada) es una parte fundamental.

Al tratar de evitar ser absorbido por la vorágine que representa definir el cloud computing, creo que es seguro decir que un entorno de computación en la nube incluye la capacidad de los consumidores de recursos de TI -como los desarrolladores de aplicaciones- de solicitar recursos bajo demanda, junto con el aprovisionamiento automatizado (también conocido como orquestación) de los recursos informáticos como servidores virtuales, conectividad de red y almacenamiento. El mero despliegue de la virtualización que permite el soporte de varios servidores virtuales en un único servidor físico, aunque admirable y útil en sí mismo, no es cloud computing.
Al hablar con un número de personas informadas, está claro que las implementaciones de nubes privadas están avanzando en muchas organizaciones, con las solicitudes de propuestas a los vendedores con el objetivo de adjudicarse un contrato en el 2011 e implementarlo en el 2012.
La pregunta es, ¿cómo va a ser utilizada esa nube privada, y cuáles son los efectos posteriores de pasarse a una nube privada? En nuestro trabajo nos encontramos con una serie de escenarios, algunos de los cuales tienen sentido, algunos de los cuales no tienen sentido, y algunos de los cuales son incomprensibles. Pensé que podría ser útil compartir lo que vemos y lo que predecimos sobre algunas de las formas en que las nubes privadas serán utilizadas por las organizaciones que las implementen.
Una hipótesis que llevamos a la mesa es que ninguna organización va a insertar una infraestructura cloud total en su entorno de aplicaciones de producción existentes. Las razones de esta hipótesis son las siguientes:
1. Un principio clave para los CIO de todo el mundo es no modificar algo que ya funciona bien. El cambio introduce la posibilidad de una interrupción o del fracaso de un proyecto. Entonces, ¿para qué insertar toda una infraestructura nueva en una en la que las aplicaciones están funcionando sin problemas? Nota: Esto no implica que los ambientes existentes no adoptarán la virtualización. Uno de los aspectos más feliz de la virtualización es que proporciona grandes beneficios -reducción de costos mediante la consolidación de servidores- sin introducir grandes cambios en el nivel de aplicación.
2. La mayoría de las aplicaciones existentes no se beneficiarán al ser colocadas en un entorno de cloud computing. La mayoría de las aplicaciones de producción están escritas con topología estática y se administran manualmente, por lo que no pueden tomar ventaja de un auto-servicio y de la elasticidad automatizada. Por lo tanto, la inserción de una infraestructura de cloud computing en el entorno de producción va a proporcionar poca mejora para estas aplicaciones. En cualquier caso, el despliegue pausado de la virtualización en entornos de producción debe poner en tela de juicio la creencia de que las organizaciones de TI van a, de la noche a la mañana, brindar a toda la organización capacidades de computación en la nube a través de su infraestructura de producción.
3. La computación en nube es cara y poco ágil para las organizaciones de TI. Constantemente vemos organizaciones que subestiman el costo y el cambio hacia el cloud computing. Solo el hecho de que un nuevo término -devops-necesitaba ser creado para describir cómo es que TI tiene que funcionar en un entorno cloud, debe proporcionar una pista acerca de esto.
Por lo tanto, para resumir: poner el cloud computing en un entorno de producción existente es perjudicial y costoso, y no proporciona muchos beneficios. Se debe explicar nuestra hipótesis de que la mayoría de las organizaciones de TI no adaptarán el cloud computing en sus entornos de producción informática.
Ante esto, muchas organizaciones de TI están dirigiendo sus primeras iniciativas de nube privada para que sirvan a los desarrolladores, lo que tiene mucho sentido. Los desarrolladores suelen ser desatendidos por los procesos existentes, y al ofrecerles una opción de auto-servicio ayuda a la productividad y, sobre todo, evita muchos problemas asociados con nubes privadas de producción, como la forma de integrar los pesados procesos existentes de ITIL con recursos ágiles de autoservicio. Por otra parte, los desarrolladores son empleados bastante caros, y evitar largas esperas por los recursos reduce los costos.
La pregunta es, si la incursión inicial de una organización en una nube privada está dirigida a desarrolladores, ¿cuáles son los escenarios de uso posterior? En otras palabras, una vez que los desarrolladores comienzan a utilizar la nube privada para el desarrollo de los propósitos (y, por supuesto, las pruebas), ¿qué pasa? Éstos son escenarios comunes de uso y sus implicancias:
Escenario uno: Desarrollo ágil, operaciones estáticas
En este escenario, se les da a los ingenieros de software y control de calidad una nube privada con fines de desarrollo, pero cuando llega el momento de implementar la producción, la aplicación funciona de acuerdo con los procesos existentes (que se recuerde, creados para gestionar la topología estática, aplicaciones inelásticas en un proceso pesado como ITIL).
Creemos que el nivel de satisfacción con esta estrategia depende de qué proporción de las aplicaciones nuevas asume y utiliza la automatización elástica asociada con la computación en la nube. La selección de este enfoque podría depender de las proyecciones específicas de la organización sobre los requisitos de las futuras aplicaciones elásticas. Si la proporción de las aplicaciones que requieren elasticidad es bastante baja, este escenario podría ser perfectamente aceptable. Para la mayoría de aplicaciones nuevas, las técnicas de operaciones estáticas podrían ser apropiadas. Para la minoría de las aplicaciones que requieren elasticidad, sería pertinente hacer una excepción para proveerles de un ambiente de operaciones más ágiles.
El reto con este escenario es que está en conflicto con lo que vemos que es la naturaleza, cada vez más común, de las aplicaciones futuras, es decir, la naturaleza de las aplicaciones está cambiando, con cargas de trabajo altamente variables, mucho mayor escala, y topologías de implementación más complejas que son más difíciles de manejar en forma manual. En una frase, hay una falta de concordancia entre el futuro de las aplicaciones y los supuestos operativos de este escenario.
Escenario Dos: Desarrollo ágil, operaciones semi ágiles
En este escenario, las nuevas aplicaciones se colocan a producir en una infraestructura de operaciones que puede soportar elasticidad, topologías complejas, y la administración automatizada; mientras que las aplicaciones existentes continúan operando en el viejo medio ambiente de operaciones estáticas. Uno podría pensar en esto como la construcción de un add-on para el medio ambiente existente del centro de datos, que opera con nuevas reglas.
En cierto modo, este escenario es consistente con la historia de la informática. Las nuevas plataformas de computación no desplazan a las que ya existen; las plataformas se unen con las existentes. Lo que comúnmente sucede es que las aplicaciones más nuevas se implementan en la nueva plataforma, mientras que las plataformas existentes se limitan a las actualizaciones de menor importancia sobre las aplicaciones existentes. Y, por supuesto, con el tiempo la nueva plataforma representa la vasta preponderancia del número total de aplicaciones.
Este es un escenario atractivo, ya que reduce las interrupciones y proporciona una buena opción para las aplicaciones implementadas y desarrolladas en la nube. Evita los problemas relacionados con la falta de concordancia del escenario anterior.
Dos puntos a tener en cuenta en este escenario:
En primer lugar, la manera desconcertante en que las aplicaciones van del "desarrollo" a la "producción", sin un reconocimiento oficial o conocimiento. Las operaciones de TI pueden sentirse responsables de las aplicaciones que no tenían ni idea de que se iban a mover hacia la producción, lo que requieren infraestructura ágil y elástica. Es decir, las operaciones de TI pueden encontrarse con el reto de proporcionar un entorno de producción cloud mucho antes de que tengan la intención de hacerlo. Esta "prematura" de producción inevitablemente causará problemas y acelerará la adopción.
En segundo lugar, es fácil subestimar los cambios necesarios para operar una infraestructura ágil. La automatización end to end tiene implicaciones mucho más allá de la instalación de un software cloud y de declararse "abierto a los negocios cloud". Así como es tradicional que las nuevas plataformas se empalmen con las antiguas, también es tradicional que las organizaciones de TI hagan mucho énfasis sobre la tecnología y subestimen a las personas y el proceso. El resultado de esta situación es que la aplicación cloud sufrirá muchos problemas cuando se ponga en la producción mientras el grupo de operaciones aprende, sobre la marcha, la forma de administrar una aplicación automatizada y elástica.
Escenario Tres: Desarrollo ágil, operaciones anuladas
Este escenario representa un desafío existencial a las operaciones de la infraestructura principal de la organización e, indirectamente, una amenaza para los fundamentos financieros de toda la organización de TI. En este escenario, los desarrolladores intentan utilizar la nube privada pero, por diversas razones, encuentran insatisfactorio algún elemento del medio ambiente y optan por desarrollarlo o implementarlo en un entorno cloud público.
Un ejemplo de por qué puede suceder esto se puede ilustrar con un ejemplo que encontré hace poco. Al hablar de la computación en nube con el administrador de infraestructuras, describimos la necesidad de un autoservicio de recursos para el usuario. El gerente estaba contento con mayor agilidad, que él se permitía, pero la solicitud de recursos tuvo que ser remitida a un administrador de operaciones que evaluará la solicitud y, en caso de ser apropiada, se proveerá de recursos a sí mismo, y posteriormente enviará la información al desarrollador para empezar a utilizar el recurso. Realmente no entendía la diferencia entre el verdadero self-service y la solicitud de recursos vía e-mail. No me importaría escuchar su respuesta a la necesidad de auto-aprovisionamiento de aplicaciones elásticas, aprovisionando recursos directamente en respuesta a la carga del sistema.
Esta respuesta es típica de organizaciones que responden a los desarrollos innovadores. Cuando se enfrentan a una innovación disruptiva, las organizaciones comúnmente intentan encajar a la fuerza en los procesos y supuestos existentes -por lo general sin éxito.
En este escenario, los desarrolladores comienzan felizmente a utilizar la nube privada, pero, cuando se enfrentan a la falta de voluntad por parte de operaciones para soportar el auto-servicio, la elasticidad de demanda, etc, se muestran insatisfechos con la oferta y optan por: (1) implementar la aplicación fuera de los centros de datos internos, o (2) más preocupante, le dan la espalda a la nube privada y optan por desarrollar e implementar en un entorno de nube pública.
Este tipo de situación puede ser directa o sutil, pero, al final, está a la altura de lo que los desarrolladores quieren. Uno de los principales puntos que enfatizamos con nuestros clientes es que la computación en la nube reduce la fricción en la obtención y uso de recursos informáticos -descartando las solicitudes interminables, reuniones, llamadas telefónicas, correos electrónicos, escaladas, por no mencionar el racionamiento de recursos que los desarrolladores esperan para justificar por qué quieren un servidor (o almacenamiento o lo que sea).
Poner una infraestructura de producción que no responde, detrás de un entorno de desarrollo ágil, puede terminar invirtiendo en una nube de desarrollo que termina sin utilizarse. Peor aún, este escenario puede tener el potencial de estancar la inversión, mientras que los ambientes caros de producción caen a medida que las aplicaciones son implementadas en nubes públicas que soportan una baja interacción de fricción.
En general, las organizaciones que buscan implementar nubes privadas deben comprender a fondo lo que están firmando. Una nube de desarrollo es un comienzo apropiado, pero no es suficiente para un plan a largo plazo. Es inevitable que una nube de desarrollo sea el primer paso hacia la implementación de un entorno de producción más grande capaz de soportar autoservicio, aprovisionamiento elástico, y operaciones ágiles plenamente comprometidas con las características de la computación en la nube. Con algo menos, al final, se quedará corto.
Bernard Golden es CEO de la firma consultora HyperStratus, especializada en la virtualización, el cloud computing y cuestiones conexas. También es el autor de "La virtualización para tontos", el libro más vendido sobre virtualización a la fecha.