Si le pone nervioso la idea de poner sus aplicaciones de negocios en una nube pública, los expertos aconsejan que, antes de sacar conclusiones, se dé una vuelta por una nube privada.
Construir y administrar una nube dentro de nuestro centro de datos no es un proyecto de infraestructura cualquiera, afirma Joe Tobolski, director de Cloud Computing de Accenture.
“Ciertas empresas de tecnología están presentando esto como algo que uno puede ir y comprar sin más: esparza algunos polvos nubelizadores en el centro de datos y, ¡listo!, ya tendrá su nube interna”, señala. “Nada puede estar más lejos de la realidad.”
La nube interna (on-premise) es algo en lo que las principales organizaciones de TI han estado trabajando durante años. Se empieza con la consolidación del centro de datos, la racionalización del sistema operativo, las plataformas de hardware y software y, precisa Tobolski, la virtualización integral del arreglo dinámico, incluyendo servidores, almacenamiento y red.
También agrega que la elasticidad y la tarifa flexible son los principios guías que implican estandarización, automatización y comoditización de las TI.
Tobolski afirma que un proyecto así va más allá de la infraestructura o el suministro de recursos: “También tiene que ver con todo el conjunto de aplicaciones y la experiencia del usuario con las TI”.
Pese a toda la alharaca que se ha generado, lo cierto es que en lo que respecta a nubes internas apenas estamos en pañales. Según Forrester Research, sólo 5% de las empresas grades son siquiera capaces de correr una nube interna. Quizá la mitad de ellas ya cuentan con una, asevera James Staten, analista principal de la firma.
Sin embargo, quienes de todas maneras estén interesados en explotar la nube privada encontrarán a continuación todo lo que necesitan saber.
Primeros pasos: estandarización, automatización, recursos compartidos
Los tres consejos de Forrester para construir una nube interna son similares a los preceptos de Accenture para la próxima generación de TI.
Los tres consejos de Forrester para construir una nube interna son similares a los preceptos de Accenture para la próxima generación de TI.
Staten sostiene que para construir una nube on-premise, hay que tener procedimientos estandarizados -y documentados- para operar, implementar y darle mantenimiento a ese entorno de nube.
Aunque la mayoría de empresas todavía no están lo suficientemente estandarizadas, agrega Staten, las compañías que están adoptando la alternativa ITIL (IT Information Library) para la administración de servicios de TI son las que más se acercan a este objetivo.
Los procedimientos operativos estandarizados que favorecen la eficiencia y la consistencia son cruciales para el siguiente nivel de los cimientos, es decir la automatización. “Hay que confiar en la tecnología de automatización y conocerla a profundidad”, afirma Staten. “Ese suele ser un gran obstáculo para la mayoría de compañías”.
La implementación de la automatización es quizá el mejor punto de partida, puesto que habilita capacidades de autoservicio. Y en una nube privada, esto no implica imitar el estilo de Amazon, donde cualquier desarrollador puede desplegar máquinas virtuales (VM) a voluntad. “Eso generaría el caos en la organización, y es totalmente imposible”, opina Staten.
En realidad, para una nube privada, el autoservicio significa que una empresa ha establecido un flujo de trabajo por el cual las solicitudes de recursos pasan por un proceso de aprobación.
Una vez aprobado, la plataforma de nube despliega automáticamente el entorno especificado. Por lo general, el autoservicio de la nube privada se traducirá en un grupo de desarrolladores que piden “tres VM de tal tamaño, un volumen de almacenamiento de tal dimensión y tanto más de ancho de banda”, sintetiza Staten. Para los usuarios finales que necesiten recursos de la nube interna de la compañía, este autoservicio se resumirá a algo como “necesito un volumen SharePoint o un archivo compartido.”
En tercer lugar, para construir una nube interna se necesita compartir recursos -“y, generalmente, es en este punto que el resto de empresas quedan descalificadas”-, explica.
Aquí no se trata de tecnología. “Es una cuestión organizacional: la gente de Márketing no quiere compartir servidores con los de Recursos Humanos, y los de Finanzas no quieren compartir con nadie. Con este tipo de actitud resulta difícil operar una nube. Si los recursos no se comparten, las nubes se vuelven sumamente ineficientes”, advierte Staten.
Luego de enfrentar un desafío muy similar, el director de TI, Marcos Athanasoulis, ideó una manera creativa para que los participantes se sientan cómodos con la idea de compartir recursos en la infraestructura de nube basada en Linux que él supervisa en la Harvard Medical School (HMS) de Boston. Según sus propias palabras, se trata de un enfoque de hardware contributivo.
En la HMS, a la que Athanasoulis se refiere como “la tierra de los mil CIO”, el departamento de TI debe lidiar con un reto bastante singular: no tiene autoridad para decirle al laboratorio qué tecnología debe usar. Aunque hay ciertas regulaciones, si un laboratorio desea implementar su propia infraestructura, puede hacerlo. Así que, cuatro años atrás, cuando la HMS se acercó a la nube, lo que buscaba era “un modelo que nos permitiera tener capacidad disponible de una manera compartida en que la escuela pague un subsidio para que las personas con menores necesidades puedan ingresar y obtener lo que les hace falta para llevar a cabo su investigación y, al mismo tiempo, ser atractiva para aquellos laboratorios que pudieran querer armar su propio entorno de nube de alto rendimiento en caso de que no les ofreciéramos una alternativa adaptable”.
Con este enfoque, prosigue Athanasoulis, si un laboratorio compraba 100 nodos en la nube, obtenía acceso garantizado a esa capacidad. Pero si esa capacidad no era utilizada, otros trabajos podrían correr en ella.
“Les dijimos: ustedes son los dueños de este hardware pero si nos permiten integrarlo a la nube, lo administraremos por ustedes y lo mantendremos actualizado y conectado. Pero si no les gusta cómo funciona esta nube, se lo pueden llevar”, recuerda. “Y ese resultó ser un buen argumento para convencer los participantes. En cuatro años, nadie ha dejado la nube”.
Para darle soporte al enfoque de hardware contributivo, detalla Athanasoulis, la HMS usa el software de automatización de carga de trabajo Platform LSF de Platform Computing. “Con esa herramienta podemos establecer colas y suspender trabajos que se encuentran en los nodos de hardware contributivo, garantizando así que la gente a la que pertenece el hardware pueda acceder a él, y que los trabajos suspendidos serán recuperados”.
No dé un paso antes de comprender sus servicios
Si las nubes son ineficientes cuando no se comparten recursos, pueden perder todo sentido si los servicios no tienen un lugar preferencial en la agenda. IBM, por ejemplo, comienza todos sus potenciales acuerdos de nube haciendo un cálculo de los diferentes tipos de cargas de trabajo y del riesgo, el beneficio y el costo de pasar cada una de ellas a diferentes modelos de nube, indica Fausto Bernardini, director de estrategia de TI y arquitectura, portafolio de servicios de nube de IBM.
Si las nubes son ineficientes cuando no se comparten recursos, pueden perder todo sentido si los servicios no tienen un lugar preferencial en la agenda. IBM, por ejemplo, comienza todos sus potenciales acuerdos de nube haciendo un cálculo de los diferentes tipos de cargas de trabajo y del riesgo, el beneficio y el costo de pasar cada una de ellas a diferentes modelos de nube, indica Fausto Bernardini, director de estrategia de TI y arquitectura, portafolio de servicios de nube de IBM.
La afinidad de determinada carga de trabajo con un modelo privado, público o híbrido depende, indica Bernardini, de una serie de atributos, incluyendo los más determinantes, como compatibilidad y seguridad, pero también otros, como la latencia y la interdependencia de los componentes en las aplicaciones.
Muchas empresas piensan construir una nube privada desde una perspectiva de producto, en vez de tomar en cuenta los servicios y los requerimientos de servicios. Justamente eso es lo que no se debe hacer como primer paso, subraya Tom Bittman, vicepresidente y analista de Gartner.
“Alguien que realmente desea construir una nube privada, primero tiene que saber cuáles son sus servicios, cuáles son los convenios de nivel de servicio, los costos y las hojas de ruta para cada uno de ellos. Hay que tener realmente claro si los servicios van con el estilo del cloud computing o no”, afirma.
Los servicios comunes con interfases relativamente estáticas -aunque nuestro negocio dependa en gran medida de ellos- son los que deben tenerse en cuenta para determinar si el modelo de la nube es público o privado, agrega Bittman.
El correo electrónico es un buen ejemplo: “Yo lo utilizo permanentemente pero no está entrelazado con los trabajos internos de mi compañía. Es el tipo de servicio que corresponde a la interfase y la independencia: no quiero que esté estrechamente integrado con la compañía, sino que se mantenga lo más separado posible, que siga siendo fácil de usar y que esté disponible desde la interfase self-service”, explica Bittman. “Si este tipo de servicio ha sido previamente customizado o modificado, tendremos que volver a la versión original y estandarizarla lo más posible”.
En cambio, los servicios que definen el negocio y que son generalmente el eje de las iniciativas de innovación no son buenos candidatos para la nube, señala Bittman. “Estos servicios apuntan a la intimidad y la integración, y nunca irán a la nube. Pueden usar funciones de nube a un nivel muy bajo, para cálculos básicos por ejemplo, pero la interfase hacia la compañía no será un modelo de nube”.
Solo una vez que hayamos comprendido cuáles son los servicios adecuados para la nube y cuánto puede demorar el proceso de pasarlos a un estado de “lectura pública”, señala Bittman, estaremos listos para armar un caso de negocio y empezar a pensar en construir una nube privada desde una perspectiva tecnológica.
El último trecho: Administración del servicio y gestión de acceso
Para llegar a este objetivo, Gartner ha definido cuatro niveles de componentes en la construcción de una nube privada.
Para llegar a este objetivo, Gartner ha definido cuatro niveles de componentes en la construcción de una nube privada.
En la base está el nivel de recursos, que comprende infraestructura, plataformas o software. Aunque la primera idea que nos viene a la mente es la virtualización básica, las VM no son la única alternativa: Bittman asegura que mientras contemos con un mecanismo que nos permita pasar los recursos a un pool, estaremos por buen camino. Otra opción, por ejemplo, es la tecnología de reprovisionamiento rápido.
Sobre el pool de recursos se ubica el nivel de gestión de recursos. “Desde aquí administro ese pool de manera automatizada”, indica Bittman, precisando que para los entornos VMware, esto implica usar el VMware Distributed Resource Scheduler.
“Estos dos niveles están bastante maduros”, considera Bittman. “En el mercado ya hay productos disponibles para ambos, aunque todavía no hay mucha competencia para el nivel de administración de recursos”.
Enseguida viene el nivel de administración de servicios. “Aquí es donde hace falta un poco de magia”, comenta. “Necesitamos algo que nos dé el control del sistema, algo que nos permita convertir los pools de recursos en niveles de servicio y, finalmente, algo que nos otorgue la capacidad de presentarle al usuario una interfase de nivel de servicio que ofrezca ‘performance’ o ‘disponibilidad’. Para brindar todo eso tenemos este nivel de administración de servicios”.
Cuando pensemos en construir una nube privada, recomienda Bittman, debemos tener claro que la brecha entre la necesidad y el producto es muy grande: “Por ejemplo, VMware es un excelente aliado para administrar el pool de virtualización, pero no es muy útil cuando se trata servicios. El vCenter AppSpeed, de VMware, es un intento pionero en este aspecto”.
“Lo que realmente necesitamos es un buen “gobernador” de servicios, y por el momento eso no existe”, señala Bittman.
En la parte superior del edificio se encuentra el nivel de administración de accesos, que viene a ser la interfase de usuario self-service. “Aquí tenemos un catálogo de servicios donde los usuarios encuentran todos los botones que deben apretar mientras nosotros nos encargamos de los suscriptores”, señala Bittman. “La interfase tiene que estar vinculada de alguna manera a las áreas de costos o de facturación: es en ese punto que se conecta con el nivel de gestión de servicios”.
La facturación es un tema particularmente espinoso para los desarrolladores de nubes privadas, pero más vale hacerle frente. “Desde una perspectiva tecnológica, es bastante delicado: ¿en qué me baso para emitir los cargos? Y tampoco es sencillo desde un punto de vista político y cultural”, agrega Bittman. “Sin embargo, si queremos pasarnos al cloud computing, de todas maneras tendremos que adoptar ese modelo, así que mejor saltar esa barrera lo antes posible”.
Al final, es solo cuestión de negocios
Si bien los constructores de nubes deben pensar en términos de elasticidad, automatización, self-service y facturación, no pueden mostrarse demasiado rígidos con las distinciones en esta etapa de la evolución de la nube, aconseja Bittman. “Muchas organizaciones se inclinarán por una nube pura y simple, otras harán de todo menos nube, y otras más optarán por alguna alternativa intermedia. Ahora, la pregunta es ¿hay algún beneficio?”.
Si bien los constructores de nubes deben pensar en términos de elasticidad, automatización, self-service y facturación, no pueden mostrarse demasiado rígidos con las distinciones en esta etapa de la evolución de la nube, aconseja Bittman. “Muchas organizaciones se inclinarán por una nube pura y simple, otras harán de todo menos nube, y otras más optarán por alguna alternativa intermedia. Ahora, la pregunta es ¿hay algún beneficio?”.
Por ejemplo, el hospital Wentworth-Douglass está construyendo “una nube privada” usando un sistema vBlock de Cisco, EMC y VMware. Pero, en realidad, no les interesa tanto la idea del auto-aprovisionamiento o del software como un servicio (SaaS) sino la abstracción de servidores, indica Scott Heffner, gerente de operaciones de red de dicho centro de salud.
“Quizás en algún momento lleguemos a SaaS, y vamos a automatizar todo lo que podamos, pero estoy introduciendo lentamente una serie de conceptos en la organización, porque el modelo de nube es demasiado avanzado como para que todos lo comprendan inmediatamente”, continúa.
Finalmente, como dice Athanasoulis, de HMS, “la gente usa nuestra nube porque les brinda un valor atractivo, y es ahí donde también deben estar las TI”.
