La visión de Berkeley sobre el Cloud Computing. Parte IV y final

Ir a La visión de Berkeley sobre el Cloud Computing. Parte I

Ir a La visión de Berkeley sobre el Cloud Computing. Parte II

Ir a La visión de Berkeley sobre el Cloud Computing. Parte III

Para concluir, los autores nos muestran el ‘Top Ten’ de los impedimentos para la adopción del Cloud Computing, tanto tecnológicos como de negocio:

1.- Disponibilidad del Servicio

Según los autores, los clientes tienen miedo a no tener un nivel de servicio adecuado. Creo que están equivocados, esto es algo que ahora mismo es secundario. Es importante, pero no es la primera preocupación, hay otras. Se empieza a asumir que la disponibilidad de los servicios en La Nube es alta.

Una ventaja que argumentan es que los servicios en una Nube tienen mayor capacidad de defensa ante un DDoS (Distributed Denial of Service). Cierto, pero debes tener un bolsillo muy profundo para soportar un ataque así, ya que por otro lado tenemos EDoS (Economical Denial Of Service). Más información en este otro post sobre el tema.

2.- Clientes cautivos de un proveedor(Vendor Lock-in)

Este si que es un problema interesante. La naturaleza actual de las soluciones de Cloud Computing son cerradas. Hay multitud de APIs propietarios, pero al final eres cautivo de tu proveedor.

La solución sería estandarizar los APIs y formatos de los objetos, para poder transitar cómodamente de un proveedor a otro. Evidentemente, los proveedores ya asentados no les interesa seguir este camino. Pero hay muchos actores que para entrar en este negocio sí les puede interesar apostar por la estandarización. Y aquí es donde el opensource puede ser la llave que permita implantar soluciones estándar que beneficien a los Cloud Users.

3.- Confidencialidad de la información y auditabilidad

Los almacenes de datos deben regirse bajo diferentes legislaciones en diferentes países o regiones. Y esto va en contra de la naturaleza del Cloud Computing, que es ubiquo. Seguro que encriptando los datos y garantizando su trazabilidad conseguimos cumplir las más exigentes legislaciones, pero es complicado cumplirlas todas en todos los casos.

En mi opinión, el nacimiento de Clouds geolocalizadas es inminente, y no va a ser por requisitos técnicos, sino púramente legislativos.

4.- Cuellos de botella en la transferencia de datos

Los requisitos de almacenamiento de datos para algunas aplicaciones puede ser gigantesco. Por ello, el coste de transferencia puede dispararse, y el coste de contratación de ancho de banda puede ser gigantesco.

No lo veo como un impedimento, sino como una restricción de la tecnología actual. Es cuestión de tiempo que los costes bajen y sea más barato transferir un disco duro entero entre Nubes que enviarlo por un mensajero.

5.- Rendimiento impredecible

La virtualización ha conseguido una separación entre máquinas virtuales fantástica cuando hablamos de CPU y de memoria RAM, pero sin embargo la Entrada/Salida (I/O) sigue siendo un problema. Lo cierto es que una máquina virtual que haga uso intensivo de la entrada salida afecta al resto de las máquinas virtuales.

De nuevo nos encontramos con un problema propio de la inmadurez de la tecnología. Los proveedores de hardware empiezan a diseñar sistemas pensando en ser virtualizados. Estos sistemas deberán tener en cuenta el problema de la entrada y salida y actuar en consecuencia.

6.-Almacenamiento escalable

Mientras que el almacenamiento escala hacia arriba, no se ha encontrado un modelo que sea capaz de soportar escalado hacia abajo de los datos, o de ‘envejecimiento’. Es decir, pagar por los datos que usas más recientemente y no por todos los que tienes almacenados.

Esto es un reto. Hay proveedores que dicen haber conseguido esto, pero bueno, hay que verlo funcionando.

7.-Bugs en sistema altamente escalables

Por la naturaleza de las soluciones masivas altamente escalables, reproducir un error en un entorno local es complicado, y si el bug tiene que ver con la naturaleza de la infraestructura subyacente que soporta la aplicación entonces será más complicado.

La solución a este problema es complicada, y puede que no tenga solución. Los que llevamos trabajando en el mundo Java unos cuantos años hemos visto como las soluciones opensource que han cogido suficiente tracción y que tienen muchos usuarios tienen menos bugs que las soluciones propietarias. Aprovecho aquí para dar un enorme tirón de orejas a Oracle/BEA, Sun e IBM. Espero que aprendan de JBoss. Por eso, una solución opensource puede ayudar a encontrar problemas más fácilmente.

8.-Escalado (suficientemente) rápido

Las demandas de picos a veces pueden predecirse y otras veces no (digged, meneado, slashdotted…). El escalado puede necesitarse de manera instantánea debido a esta demanda inesperada. El no poder escalar a tiempo puede hacer que duranto unos minutos el sistema no responda como espera el cliente y perdamos la oportunidad. Soluciones como EC2 son más sensible a este problema, pero Google AppEngine parece que es transparente.

Otra cuestión es la fracción de pago del escalado. Si tu pico ha durado unos pocos minutos, pagarás por la fracción de tiempo contratada. En el caso de EC2, por horas.

Los autores no han visto Terminator y por eso proponen máquinas que escalen solas y que aprendan, para poder reaccionar a tiempo a la demanda. Ya sabéis mi opinión al respecto.

9.-Reputación compartida entre Cloud Users y Cloud Providers

La mala práxis de un Cloud User (por ejemplo un spammer) puede afectar al resto de los usuarios y a un proveedor de Cloud. Pongamos el caso de un spammer que usa IPs de EC2 y son puestas en listas negras de antispammers. En ese caso un cliente puede poner en riesgo la reputación de Amazon.

Creo que este argumento es igual de válido para cualquier proveedor de hosting o de housing, o un ISP. Deben tener especial cuidado con las IPs que se asignan a sus clientes, para evitar que se metan en este tipo de listas. No es un argumento propio del Cloud Computing, por lo tanto.

10.-Licencias de software

El modelo de compra de licencias o de alquiler perpetuo ya no valen. Se debe pasar a un modelo donde se paguen por el tiempo que se usan las licencias. Una de las razones del éxito de los productos opensource en La Nube es que no tienes que preocuparte por esto. Los modelos posibles son variados, pero deben adaptarse al ‘pay as you go’. Microsoft Windows en Amazon EC2 tiene un sobrecoste de $0.05 por hora, e IBM está trabajando en una tabla de conversión de pago por CPU a pago por uso sobre Amazon EC2. Una sugerencia hecha por los autores es pasar a un modelo de ‘prepago’ de uso de CPU. Es decir, pagar por adelantado el uso aproximado del sistema durante uno, dos o tres años, al mismo tiempo que se negocian los contratos de mantenimiento. Una buena idea.

Conclusiones

Finalmente el Cloud Computing está emergiendo. Se han dado la combinación de factores que ha hecho que empiece a despegar. Aún quedan muchas incógnitas que resolver, especialmente cual será el papel de los medianos y pequeños proveedores de hosting contra los grandes proveedores.

La otra gran cuestión es qué características arquitectónicas deberán tener las aplicaciones que aprovechen el Cloud Computing, que pueden correr sobre cientos o miles de máquinas virtuales iguales:

  • La aplicación debe poder escalar hacia arriba y hacia abajo de manera sencilla y rápida.
  • El software de infraestructura debe estar pensado para correr sobre máquinas virtuales y no sobre el metal.
  • Los sistemas hardware deben pasar de diseñarse para racks a diseñarse para containers. Además, el hardware debe ser energéticamente eficiente cuando el sistema esté ocioso. Otra cuestión importante es que el hardware deberá tener en cuenta la virtualización y sus características (cuellos de botella de entrada/salida, por ejemplo)

La visión de Berkeley sobre el Cloud Computing. Parte III

Ir a La visión de Berkeley sobre el Cloud Computing. Parte I

Ir a La visión de Berkeley sobre el Cloud Computing. Parte II

La migración a un modelo de Cloud Computing o bien empezar una empresa directamente aprovechando las ventajas de este modelo no solo es una cuestión técnica; es también una cuestión de recursos económicos.

La elasticidad y la transferencia del riesgo

Los autores argumentan que la frase “Convertir CapEx a OpEx” se usa habitualmente como argumento de venta del Cloud Computing, “pay as you go” (paga por lo que usas no es una traducción exacta, pero nos vale…) captura mejor la esencia de los beneficios económicos del Cloud Computing. Por lo tanto, aunque Amazon por ejemplo puede ser 1.4 veces más caro que comprar y depreciar servidores del mismo tipo, los beneficios de elasticidad y transferencia del riesgo equilibran este sobrecoste. Especialmente cuando hablamos de saturación o falta de utilización de los servicios.

La elasticidad te permite soportar los picos de demanda estacionales, y la transferencia del riesgo es por no perder clientes por una mala calidad del servicio en caso de saturación. Aunque lo nombra de pasada, creo que es también importante señalar que se reduce de manera significativa el coste de optimización de las soluciones, por lo que de nuevo transferimos CapEx a OpEx. Recomiendo leer en detalle el capítulo 5.1 ya que está lleno de detalles que no puedo reproducir en el blog como quisiera.

Comparando costes: ¿Debo irme a La Nube?

He de confesar que esta parte del documento me parece confusa: no está claro si habla de Cloud Users o Cloud Providers. Cosas como la energía eléctrica consumida, refrigeración y costes de operación de la infraestructura. Creo que este punto por momentos se ponen la gorra de Cloud User y luego la de Cloud Provider, pero no lo hacen de manera rigurosa. Así que si tienes un datacenter y piensas en moverte a la Nube, estos puntos son importantes en su opinión:

  • Paga de manera separada los recursos: Si puedes pagar por ancho de banda consumido, almacenamiento, CPU… hazlo, ya que la mayoría de las aplicaciones tienen consumos dispares.
  • Ten en cuenta el coste de refrigeración, energía eléctrica y espacio físico: Estos costes duplican los costes del hardware. Para soluciones redundantes, puede ser hasta tres veces el coste.
  • Coste operaciones: El coste de las operaciones hardware ha caido de manera dramática, pero no así el coste de gestión del software de infraestructura, hay que seguir actualizando y poniendo parches. En este caso soluciones como Google AppEngine, Microsoft Azure o Force.com pueden ser interesantes.

Mañana la última parte con las 10 obstáculos para la adopción del Cloud Computing.

Ir a La visión de Berkeley sobre el Cloud Computing. Parte IV y final

La visión de Berkeley sobre el Cloud Computing. Parte II

Ir a La visión de Berkeley sobre el Cloud Computing. Parte I

Los siguientes capítulos del documento tratan un asunto que suele salir en conversaciones informales pero que normalmente pasamos por alto: Por qué despega ahora el Cloud Computing, y por qué fallo antes.

¿Por qué ahora Cloud Computing y antes no?

Para los autores la razón está detras de algo que según ellos acompaña a los modelos de negocio Web 2.0: el paso de un modelo de ‘cercanía al cliente, margenes altos y compromisos altos’ a un modelo de ‘distanciamiento del cliente, márgenes bajos y compromiso bajo’. Es decir, pasar de un modelo donde es necesario definir contratos y marcos de relación entre empresas pesados a un modelo donde el autoservicio (self-service) es el que manda. Como ejemplo Paypal y Amazon Web Services, donde no es necesario firmar un contrato para trabajar con ellos, basta con dar tu tarjeta de crédito.

Las nuevas aplicaciones

Los autores sostienen que el driver actual fundamental para la adopción de una arquitectura de aplicaciones en la Nube es el elevado coste actual para acceder a datos en una red WAN comparado con una red LAN. Aunque me parece una aproximación un poco simplista, se la compro. Los tipos de aplicaciones que proponen son:

  • Aplicaciones móviles interactivas: Estas aplicaciones normalmente necesitan alta disponibilidad en la parte servidora y capacidad de almacenamiento masiva. Lo que me parece una chorrada monumental es que sean interactivas. El mundo M2M (machine-to-machine) genera muchísimos más datos que las aplicaciones interactivas.
  • Procesado Batch en paralelo: La posibilidad de poder trabajar con cientos de máquinas en paralelo es algo desconocido hasta ahora para la gran mayoría de desarrolladores. Soluciones con MapReduce pensadas para gestionar esta complejidad emergerán.
  • Aplicaciones analíticas: El procesado de datos está en auge frente a las aplicaciones transaccionales. Cada vez es más importante analizar los datos que manejan las empresas.
  • Extensión de la capacidad de computación de los ordenadores personales: Herramientas de cálculo que lanzan sus cálculos contra los servidores en La Nube. Matlab y Mathematica como ejemplo de soluciones existentes.

Las clases existentes de utility computing

Los autores sostienen que las diferentes ofertas de utility computing se distinguirán en función del nivel de abstracción presentada al programador y el nivel de gestión de los recursos virtualizados. Cualquier aplicación necesita un modelo de computación, un modelo de almacenamiento y un modelo de comunicación entre procesos. Para conseguir la ilusión de capacidad infinita es necesario virtualizar estos recursos para poder multiplexarlos y ocultarlos al programador.

A un lado del espectro está Amazon EC2. Una instancia EC2 es como hardware físico, y los usuarios tienen control sobre todo el software de kernel hacia arriba. El API disponible es ligero. Puede ejecutarse casi cualquier cosa en las instancias. Debido a su bajo nivel de abstracción, es complicado ofrecer escalabilidad automática y tolerancia a fallos a este nivel. Esto se suele gestionar a nivel de aplicación.

En el otro extremo se encuentran las Plataformas de aplicaciones específicas para un dominio como Google AppEngine y Force.com. AppEngine está pensada para aplicaciones web y modelos petición-respuesta, por lo que se raciona el uso de la CPU en las peticiones de servicios. Force.com está pensada únicamente para trabajar con las bases de datos de Salesforce.com. Por lo tanto, no sirven como plataformas de computación de propósito general.

Microsoft Azure se encuentra a medio camino entre la flexibilidad y la facilidad para el programador. Las aplicaciones se escriben usando librerías .NET y soporta computación de propósito general. Los usuarios pueden usar el lenguaje que prefieran (mientras sea soportado por .NET), pero no pueden controlar el sistema operativo debajo o la plataforma de ejecución de .NET. Las librerías permiten configurar redes, y parámetros de escalabilidad y tolerancia a fallos, pero debe hacerlo el programador de manera declarativa.

Los autores se preguntan si un modelo podrá batir a otro en el espacio del Cloud Computing. Al igual que hay lenguajes de programación especializados en el manejo de recursos hardware como el C, y otros se especializan en el desarrollo de aplicaciones Web (olvidándose del metal) como Ruby (on Rails), lo mismo pasará con las ofertas de Cloud Computing.

Por hoy es suficiente, mañana seguiré con la Economía del Cloud Computing.

Ir a La visión de Berkeley sobre el Cloud Computing. Parte III

Ir a La visión de Berkeley sobre el Cloud Computing. Parte IV y final

La visión de Berkeley sobre el Cloud Computing. Parte I

Hace unos días recibí un correo indicándome que debía comentar un estudio que circula por la red hecho por la Universidad de Berkeley sobre el estado actual del Cloud Computing. Al leerlo me di cuenta que era un documento que necesita un análisis más detallado que mis habituales 300-500 palabras por post. Por suerte, muchos de los temas tratados ya han sido comentados en el blog, pero merece la pena dar un repaso.

El documento es el resultado de un estudio del UC Berkeley Reliable Adaptive Distributed Systems Laboratory, y viene a responder a varias cuestiones fundamentales en el estado actual del Cloud Computing:

  • ¿Qué es Cloud Computing y en qué se diferencia de otros cambios de paradigma como el Software as a Service (SaaS)?
  • ¿Por qué puede el Cloud Computing despegar ahora, cuando ha fallado en los intentos anteriores?
  • ¿Qué se necesita para llegar a ser un proveedor de Cloud Computing, y por qué una compañía consideraría convertirse en uno?
  • ¿Cuales son las oportunidades que se abren o los potenciales ‘drivers’ (de adopción, entiendo) del Cloud Computing?
  • ¿Cómo podríamos clasificar la oferta actual de Cloud Computing en el espectro, y cómo difieren los retos técnicos y de negocio dependiendo de qué lugar del espectro del producto?
  • ¿Cuales son los nuevos modelos económicos facilitados por el Cloud Computing, y cómo un operador de servicios decide si moverse a La Nube o quedarse en un Datacenter?
  • ¿Cuales son los diez obstáculos más importantes para la adopción del Cloud Computing, y las correspondientes 10 oportunidades disponibles para superar estos obstáculos?
  • ¿Qué cambios deberían hacer los diseñadores de futuras aplicaciones software, infraestructura software y hardware para aprovechar las necesidadesy oportunidades del Cloud Computing?

¿Qué es el Cloud Computing?

El comienzo del documento intenta explicar con una metáfora una de las razones del Cloud Computing, el acceso a recursos bajo demanda con menores costes debido a las economías de escala de los super datacenters. De igual manera que los fabricantes de chips -y yo añado que los fabricantes de casi todo- ya no tienen fábricas físicas para sus productos, sino que contratan la producción a empresas que únicamente tienen líneas de producción adaptables, ocurre lo mismo en el mundo de la operación de aplicaciones software.

Según ellos, el Cloud Computing es la suma del SaaS y del Utility Computing. Me ha llamado la atención cómo se desmarcan con celeridad del Software as a Service (SaaS) desde el punto de vista del usuario (Saas User). Todo el mundo conoce sus ventajas y se ha tratado ampliamente en múltiples sitios. Sin embargo el documento se centra sobre todo en lo que ellos llaman SaaS Provider/Cloud User y Cloud Provider.

El Cloud Computing desde el punto de vista de la infraestructura hardware ofrece cosas nuevas:

  • Ilusión de recursos de computación infinitos disponibles bajo demanda. Esto significa que los Cloud Users no necesitan hacer planificaciones lejanas en el tiempo. (Y yo me pregunto, ¿Significa esto que desaparece el Capacity Planning? Yo creo que no…)
  • La eliminación de compromisos tempranos de los Cloud Users, lo que permite que las empresas empiecen con poco e incrementen sus necesidades hardware solo cuando hay un incremento de sus necesidades, y
  • Poder pagar por el uso de recursos de computación por períodos cortos de tiempo (por ejemplo pagar por procesadores a la hora o almacenamiento por día), y liberándolos cuando no se necesitan.

Está claro que las ventajas para los Cloud Users son evidentes, pero ¿quién quiere convertirse en un Cloud Provider? ¿Qué necesidad tiene?

Una condición necesaria pero no suficiente para que una compañía se conviertan en proveedor de Cloud Computing es que ya debe haber realizado inversiones importantes no solo en grandes datacenters, sino también en sotfware de infraestructura a gran escala, además de los conocimientos para mantenerlos. Una vez que se dan estas condiciones, hay una gran cantidad de factores que pueden influir en que se conviertan en proveedores o no:

  1. Ganar mucho dinero: Las economías de escala de los superdatacenters pueden ofrecer costes bastante por debajo de los datacenters medianos y pequeños (ver el documento).
  2. Aprovechar inversiones ya realizadas: Añadir Servicios de Cloud Computing sobre infraestructura ya existente permite tener un nuevo flujo de benificios a cambio de costes bajos.
  3. Defender una franquicia: Microsoft quiere defender sus productos ofreciendo soluciones en la Nube, evitando su fuga a otros proveedores.
  4. Ser cabeza de playa: Si una compañía ya tiene el software y un datacenter que cumpla los requisitos, puede querer tomar la playa antes de que lleguen los Google, Microsoft y demás.
  5. Aprovechar las relaciones con clientes: Hay empresas de servicios que pueden aprovechar su oferta de servicios para reducir la ansiedad que produce a los clientes el camino hasta migrar a la Nube.
  6. Convertirse en una plataforma: Al estilo de Facebook, ofrecer la posibilidad de integrar aplicaciones dentro de la plataforma encaja con el modelo Cloud Computing.

Esta es la primera parte de mi análisis del estudio. Mañana más.

Ir a La visión de Berkeley sobre el Cloud Computing. Parte II

Ir a La visión de Berkeley sobre el Cloud Computing. Parte III

Ir a La visión de Berkeley sobre el Cloud Computing. Parte IV y final

El Cloud Computing necesitará 7 años para madurar según Gartner

La consultora Gartner ha publicado un documento en el que intenta poner fechas a la evolución y madurez del Cloud Computing. Son unos valientes estos chicos. El mercado del Cloud Computing se encuentra en un período de excitación, crecimiento y alto potencial. Pero aún necesita un periodo de maduración hasta que se convierta en algo popular y común, de acuerdo a las previsiones de Gartner.

Han dividido esta maduración en tres períodos:

Fase 1: 2007 a 2011 — Pioneros e innovadores

Es el período de desarrollo del mercado. Hasta 2011 y debido a la naturaleza inmadura de las soluciones, Gartner recomienda buscar soluciones oportunistas, donde el time to market y la productividad son más importantes que la viabilidad ténica a largo plazo. El retorno de la inversión en desarrollos cloud será muy corto, del orden de 18 a 24 meses.

Dado que primarán las virtudes técnicas sobre el aseguramiento de la inversión, triunfarán aquellos proveedores tecnológicos con mayor ‘visión’ del mercado. Muchos proveedores se centrarán en aplicaciones de desarrollo y prototipado rápido con facilidades para el despliegue en las Nubes, ya que serán más atractivas para aplicaciones de cliente final y proyectos de redes sociales.

Fase 2: 2010 a 2013 — Consolidación del mercado

Gartner predice que para el 2012, el mercado de las plataformas de Cloud Computing estará abarrotado con una amplia gama de soluciones de proveedores grandes y pequeños. La presión competitiva derivará en adquisiciones de los actores más débiles del mercado. En esta fase de consolidación estas infraestructuras serán cada vez más atractivas, aumentando la base de usuarios con perfiles más conservadores. La parte técnica ya no será más importante, y el tiempo para el retorno de la inversión se extenderá a 3 o 5 años.

Al final de esta fase, Gartner espera que las plataformas de Cloud Computing sean las preferidas para el desarrollo de aplicaciones de servicios con arquitecturas sencillas, pero no en exclusiva, de las 2000 empresas más importantes (Global 2000). Aunque algunos empezarán a incluir inversiones en estas plataformas de Cloud en sus planes estratégicos.

Fase 3: 2012 a 2015 y mas allá – La masa crítica mayoritaria

Para 2013 un reducido número de proveedores dominará el mercado con un conjunto de estándares de facto. Estos proveedores se apoyarán en las tecnologías propietarias desarrolladas en los años anteriores, pero también soportarán APIs para crear ‘fábricas’ de servicios que permitirán unir soluciones cloud de diferentes proveedores.

El mercado se expandirá por la incorporación de una base de usuarios conservadora que hará virar los esfuerzos del mercado de la innovación a la estabilidad, reducción de costes y protección de la inversión. La competencia entre soluciones propietarias y abiertas aumentará, y para 2014 esta preocupación hará que aumente el apoyo a una o más soluciones open-source. Estas soluciones open-source competirán con soluciones propietarias y empecerán a comer mercado lentamente a partir de 2015.

¡Qué tíos estos de Gartner! ¡Cómo afinan! Aunque yo la verdad no me preocuparía tanto: Para el 2015 Skynet ya habrá tomado conciencia de si misma…

Aclarando términos del Cloud Computing

ontología.

(Del gr. ὄν, ὄντος, el ser, y -logía).

1. f. Parte de la metafísica que trata del ser en general y de sus propiedades trascendentales.

Me han enviado esta pequeña presentación que trata de dar algo de luz sobre el panorama del Cloud Computing y las diferentes partes que lo forman. A ver si de una vez todos hablamos de lo mismo:Toward a Unified Ontology of Cloud Computing.

Amazon dobla a Google como el mejor proveedor de Cloud

Leo en eWeek que Amazon es el proveedor preferido de Cloud, doblando a Google. Esta encuesta ha sido realizada por Appistry, y ha sido presentada coincidiendo con la CloudComputing Expo. La información se encuentra en este documento (PDF), y fue tomada en el CloudCamp de Septiembre en Silicon Valley. El 62% de los encuestados prefieren a Amazon, el 33% a Google, el 13% a Microsoft y el 10% a otros (que incluyen a Sun, IBM y AT&T).

El 66% de los participantes cree que aumentará el interés en el Cloud Computing en los próximos 12 meses. El 39% cree que la innovación se está haciendo en las infraestructuras, el 30% en las aplicaciones y el 31% en los modelos de negocio. Curiosamente, sólo el 8% piensa que se está innovando en el almacenamiento de datos.

La encuesta ha encontrado cinco puntos claves:

  1. Amazon se percibe como el lider
  2. La infraestructura lidera la innovación en el Cloud Computing
  3. La seguridad, la fiabilidad y el cumplimiento de las promesas de escalabilidad son sus puntos críticos
  4. Más atractivo cuanto más reduzca los costes y aumente la escalabilidad
  5. Nadie conoce todavía cual es la mejor aplicación para La Nube.

Y es este último punto el que más me motiva: El Cloud Computing es el campo de juego para la creación de las futuras killer apps.

IDC estima que el gasto en Cloud Computing en 2012 será de $42000M

La consultora IDC estima que en los próximos 5 años el gasto en Cloud Computing se triplicará alcanzando la cifra de 42 mil millones de dólares, contabilizando el 9% de los ingresos en cinco segmentos del mercado claves. Pero lo más importante es que el gasto en el período se acelerará hasta capturar el 25% del gasto en IT en el 2012 y casi un tercio en el 2013. Frank Gens, Senior VP y Analista jefe en IDC dice:

Un reciente estudio entre Ejecutivos de IT, CIOs y los colegas en las líneas de negocio muestra que el Cloud Computing está ‘cruzando el abismo’ y entrando en un período de amplía adopción. Más aún, la crisis económica amplificará la adopción de La Nube. Este modelo ofrece una manera más barata para que el negocio use y adquiera tecnología… Esta ventaja es verdaderamente importante para los pequeños y medianos negocios…

El anuncio hecho por IDC se puede encontrar aquí en inglés. Entre otras cosas también diferencia entre Cloud Services y Cloud Computing, y hace un intento por definir los atributos de cada uno de estos servicios (aunque esto lo dejo para otro artículo). También menciona cómo hay oportunidades para aquellos proveedores de IT que quieran pasar del modelo tradicional de distribución de software al modelo en La Nube. Y también ve oportunidades en herramientas que faciliten que otros entren en el modelo de servicios en la Nube.

La verdad es que las cifras son realmente impresionantes, y si se cumplen, quien pueda posicionarse en este mercado tiene garantizado el éxito de su negocio. El problema es que en la mayoría de las ocasiones estos consultores metidos a oráculo no aguantan la hemeroteca, y la economía de la expectativa se ha detenido con el credit crunch. Hasta hace unos meses la economía de las startups se basaba en las expectativas de su mercado objetivo, lo cual las hacía atractivas a los fondos de capital riesgo. Pero el entorno económico es diferente y ahora las startups no pueden financiarse sólo por expectativas: necesitan tener ingresos ya que la entrada de capital para crecer es más complicada.

Eso si la tecnología tan prometedora y con tan enormes expectativas no cuaja y te quedas con un palmo de narices…