Llegamos a ustedes gracias a:



Columnas de opinión

Las tres revoluciones del cómputo en la nube: Parte 2

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

[04/03/2010] La semana pasada escribí sobre la primera de las revoluciones del cómputo de nube: la revolución en las operaciones de TI. Esta semana quiero volver a la revolución que ocurrirá debido a la naturaleza cambiante del costo en un ambiente de cómputo en la nube. En el reporte del Laboratorio RAD de Berkeley sobre cómputo en la nube, se identifica el "precio-sobre-la-marcha" como una característica clave de esta arquitectura. El precio pague-sobre-la-marcha se refiere al hecho de que los recursos de cómputo en un ambiente dela  nube son típicamente cobrados sobre la base pormenorizada del uso.

En Amazon, por ejemplo, uno paga por hora, por capacidad de procesamiento, y por Gb para la transmisión de red y el almacenamiento de datos. En lugar de recibir una factura por, digamos, el valor de un mes de hosting administrado, la factura podría ser por 63 horas de cómputo. Debido a que muchas aplicaciones solo son usadas una porción de cualquier mes dado, el modelo de hosting administrado cobraría por horas donde de hecho no se está realizando ningún cómputo; por contraste, Amazon solo cobrará por horas en que la aplicación fue necesitada y estuvo arriba y funcionando. Por supuesto, esto solo es posible si uno monitorea la aplicación y la apaga si no se necesitada. Si no se realiza ningún monitoreo, y la aplicación se deja corriendo aunque no se esté procesando ninguna carga, se aplica un cargo. 
Este tipo de sistema de precios es generalmente etiquetado como "opex en lugar de capex". Esa frase resume el tipo de presupuesto que toma lugar para costos tipo pague-sobre-la-marcha, e ilustra la naturaleza transformada del aprovisionamiento de cómputo en un ambiente de la nube -y eso va al corazón de la revolución-. El objetivo principal de correr una computadora es ejecutar algún código, lo cual tiene -supuestamente, de todos modos- beneficios de negocios. Históricamente, uno solo podría obtener la meta de ejecutar código en un servidor que uno poseía y operaba. En otras palabras, una inversión de capital en un equipo de cómputo era un pre-requisito para correr una aplicación. Las inversiones de capital (o gastos de capital, alias capex) son grandes desembolsos que pagan beneficios con el tiempo y son por lo tanto depreciados para propósitos de impuestos. En la mayoría de organizaciones, el gasto de capital es muy cuidadosamente monitoreado, ya que las compañías necesitan mantener sus índices financieros bajo control. Ese monitoreo es hecho por la organización financiera, la cual raciona el acceso al capital.
Opex, del otro lado, significa gasto operativo, y es más típicamente manejado por la organización que hace el gasto; esto es, a la organización se le da cierto presupuesto operativo, se le dice que cumpla ciertos objetivos financieros, y básicamente se le deja por sí misma. Siempre y cuando se quede dentro de su presupuesto operativo y "cumpla sus números", puede graficar su propio rumbo.
Debido a que las generaciones previas de cómputo requirieron relativamente grandes inversiones de capital mucho antes de que los beneficios de la aplicación empezaran a fluir, obtener la aprobación de proyectos TI no era fácil. Todo tenía que pasar por los ciudadanos de ojos de lince de finanzas. Esto tenía el resultado inevitable de que solo las aplicaciones más seguras, de menor riesgo y más necesarias eran financiadas. También era inevitable el hecho de que la toma de decisiones de TI fue cambiada de las unidades de negocios que se hubieran beneficiado de la inversión, al grupo financiero.
Debido a que no se requiere inversión de capital para la mayoría del uso de cómputo en la nube, la toma de decisiones relativa a qué aplicaciones deberían ser implementadas, residirá en el grupo que genera el gasto operativo, por ejemplo, la unidad de negocios. Finanzas tendrá mucha menos influencia sobre qué aplicaciones tendrán dinero dirigido hacia ellas. Una pregunta secundaria será cómo esta reducida necesidad de aprobación financiera afectará las políticas organizacionales relativas a dónde reportará TI; en muchas compañías TI reporta al CFO (gerencia financiera, por sus siglas en inglés) debido a la naturaleza de capital pesado de sus procesos de negocios. Quizás el movimiento hacia el cómputo en la nube resultará en que TI se mueva de estar debajo del CFO a reportar a las unidades de negocios o al CEO. Será fascinante observar este desarrollo.
Este capex vs. opex es la base para la mayoría de discusiones sobre el impacto financiero del cómputo en la nube; en mi opinión, sin embargo, está muy lejos de entender la revolución que ocurrirá como resultado de la asignación pormenorizada de costos operativos. No hemos ni empezado a pensar sobre los efectos posteriores para la línea de organizaciones de negocios, cuando los costos estén más directamente asignados al uso de recursos. Aquí hay algunos de los cambios que podemos esperar ver debido a los nuevos mecanismos de costos del cómputo de nube:
Cambio de control de TI a las unidades de negocios
La necesidad para grandes inversiones de capital, coordinado por TI (y supervisado por finanzas), ha significado que las unidades de negocios han tenido menos control sobre los recursos de cómputo que soportan sus esfuerzos de negocios. Con la necesidad de moverse a inversiones de mucho menos capital, TI tendrá menos que decir sobre cómo las unidades de negocios escogen dirigir su gasto de TI -y dada la reducida barrera para "enmascarar el gasto TI", quizás mucho menos conocimiento relacionado a lo que las unidades de negocios de cómputo están haciendo-. Esto le dará a las unidades de negocios mucha más discreción con relación a dónde escogen invertir.
Además, uno podría esperar que este ambiente promueva mucho menos paciencia para el "este año, tenemos que invertir en una gran actualización de la aplicación XYZ, así que los objetivos de su unidad de negocio tendrán que esperar hasta el siguiente año". Como dice el viejo dicho: "aquél que paga al flautista, pide las canciones", y el cómputo en la nube hará más claro exactamente quién es el flautista -y el flautista va a pedir diferentes melodías al ir avanzando.
Veremos mucho más de la actitud "puedo pagarlo, y esto es lo que quiero" en el futuro. Ya estamos viendo el impacto de esto -presenciamos la salida del CEO de SAP en días pasados-. Si bien la crisis financiera indudablemente exacerbó la situación, el hecho de que las unidades de negocios sean resistentes a meter enormes cantidades de dinero en un sistema ERP que hace esencialmente nada por asistir a que la innovación, también juega un rol. Estar en el lado equivocado de la ecuación de "ayudar a la innovación" es peligroso en un mundo de cómputo en la nube.
Ruta directa desde el uso de recursos hacia el valor de negocios
En el ambiente de hoy, no es fácil hacer una conexión financiera directa entre una iniciativa de negocios que usa recursos de cómputo, y el valor resultante de ese uso. La abultada asignación de costos típica de la mayoría de ambientes de cómputo, hace muy difícil hacer corresponder costo y beneficio. Mucho más común es la situación en la cual una cierta cantidad de valor es materializada (por ejemplo, más visitantes como resultado de una campaña en línea con cada visitante evaluado como siendo valioso por cierta cantidad), pero muy poco conocimiento está disponible con relación a la inversión hecha para implementar la iniciativa.
Usar recursos que son tratados como "costos hundidos", fracasar en justificar costos auxiliares como el tráfico de red, y por supuesto, fracasar en incluso autorizar los costos operativos que deberían ser asignados a la iniciativa, hacen casi imposible una contabilidad realista. Esta situación cambiará cuando todos los recursos de cómputo sean pagados "por-trago", y puedan ser más directamente asignados al valor que ellos generan. En un momento en que las operaciones de negocios están cada vez más empapadas con características TI, este rastreo llega justo a tiempo.
El bajo costo fomenta la experimentación
Un aspecto del cómputo en la nube que no es suficientemente enfatizado en la mayoría de discusiones sobre él, es el hecho de que está idealmente ajustado para la experimentación de aplicaciones. Así como las TI de alto costo e intenso capital del pasado causó que la inversión se enfocara en las aplicaciones más seguras y de bajo riesgo, las TI de bajo costo y capital ligero del cómputo en la nube motivará a las organizaciones de negocios a experimentar con nuevas iniciativas de negocios. Iniciativas de negocios que, en el pasado, no habrían obtenido suficiente soporte para justificar aportar capital precioso en tomar un volante sobre ellas, encontrarán un mucho más amistoso ambiente en el cómputo en la nube.
Un buen ejemplo de esto es la aplicación NASDAQ Market Replay que apalanca Amazon Web Services (AWS). Tratar de comprar suficiente equipo para esta aplicación habría sido prohibitivo, aun cuando el valor de la aplicación parecía intuitivo. Usando AWS, la aplicación podía ser desarrollada por mucho menos, lo cual hizo que lanzarla fuera un riesgo mucho menor. Se puede probar nuevas aplicaciones al costo de cientos o miles de dólares, en lugar de los cientos de miles de dólares requeridos anteriormente. Si es un ejecutivo de una línea de negocios con ideas innovadoras, el cómputo en la nube va a hacer sus prospectos mucho más brillantes.
En la perspectiva del "bajo costo impulsa la experimentación", el cómputo en la nube se parece mucho a la fuente abierta. En su libro "Aquí viene todo el mundo", Clay Shirky anotó que el bajo costo de la fuente abierta promueve la experimentación y el cometer errores. Cuando las apuestas son bajas, las pruebas que no funcionan son mucho más aceptables -y aumentar el número de pruebas aumenta las probabilidades de éxito-.
El costo reducido alienta las aplicaciones a gran escala
El otro lado del bajo costo impulsando la experimentación del cómputo en la nube es que los aumentos de sus costos lineares que acompañan el aumento de la escala de las aplicaciones hacen sabroso el prospecto del salvaje éxito de la aplicación. Hoy en día, es demasiado común que una aplicación muy exitosa termine siendo sofocada debido a que no se puede encontrar suficiente capital para soportar el aumento necesario en recursos; o incluso si el capital puede ser ubicado, la infraestructura física no puede ser puesta en funcionamiento lo suficientemente rápido. El éxito abruma a los sistemas, y tiene como efecto que aplicaciones muy exitosas carecen de recursos.
Cuando los propietarios de negocios puedan asumir confiadamente eso, en caso de que su iniciativa gane tracción y los recursos necesarios estuvieran disponibles a un costo razonable, ellos pueden ser mucho más osados en sus iniciativas de negocios. Un gran ejemplo de esto es lo que sucedió con un cliente nuestro, la Fundación Educativa Silicon Valley. Su aplicación Lessonpoly proporciona planes de lecciones para los maestros, permitiéndoles compartir, combinar, etcétera. Recientemente, se le ofreció a la fundación la oportunidad de hospedar un gran número de planes de estudio asociados con los Juegos Olímpicos de Invierno, con NBC presentando la sociedad en sus transmisiones. La fundación pudo acceder confiadamente a soportar el programa, segura en el conocimiento de que la aplicación basada en AWS podría escalar fácilmente: la administración simplemente apagó la pequeña instancia basada en 32-bit y lanzó la gran instancia de 64-bit, cuadruplicando inmediatamente la memoria disponible para la aplicación. Si la carga se incrementaba más allá de la habilidad de 64-bit de la máquina para manejarla, particionar la aplicación en varias máquinas podría realizarse fácilmente. En su viejo ambiente hospedado, la fundación hubiera tenido que pensarlo dos veces respecto a soportar el programa de los Juegos Olímpicos; con el cómputo en la nube la decisión puede estar basada en el atractivo de la oportunidad.
En casi cualquier ambiente en que a uno se le ocurra pensar, la transparencia de costos y la asignación directa de los costos a los beneficios causa un cambio de comportamiento. En tanto el modelo de precio de pague-como-va del cómputo en la nube empieza a impregnar el pensamiento de la unidad de negocios, veremos más cambios en la forma en que planean sus actividades de TI de lo que hemos visto en los pasados 30 años.
Se acabarán las marchas forzadas tipo big-bang, de muchos años y muchos millones; empezarán los experimentos ágiles de bajo costo, diseñados para identificar oportunidades de negocio y explotarlas. Las unidades de negocio impulsarán más confiadamente su agenda en TI, seguras en el conocimiento de que tienen más control en un mundo de cómputo en la nube. Se levantará un nuevo ambiente de evaluar costos y beneficios de negocios relativos a iniciativas de TI. El cómputo en la nube pondrá boca abajo la relación tradicional entre las unidades de negocios y las TI, y el mundo de negocios nunca lucirá igual.
CIO.com
Bernard Golden es CEO de la firma de consultoría HyperStratus, la cual se especializa en virtualización, cómputo en la nube y temas relacionados. Él también es el autor de "Virtualización para Dummies", el libro más vendido de virtualización hasta la fecha.