Nubeblog

Google Storage for Developers ya disponible bajo petición

May 20, 2010 almacenamiento, google

Se rumoreaba que el anuncio del Amazon S3 ‘light’ presentado ayer era pura contraprogramación de Amazon. En el Google I/O 2010, se ha anunciado la disponibilidad del nuevo servicio Google Storage for Developers. Resumiendo, si conoces Amazon S3 o cualquier otro servicio de almacenaje en la nube de objetos, es lo mismo, pero hecho por Google.

Cuando veo la etiqueta ‘for Developers’, me hecho a temblar. ¿Esta coletilla se pone para indicar que el servicio no es lo suficientemente estable para el uso por el público general? ¿O bien porque para aprovechar este servicio hay que tener conocimientos de programación para usar su API REST? No lo se… pero bien la lamentable página de información del producto, me inclino a pensar lo primero. No se a qué  clase de público quieren atraer, pero dado que el servicio es de pago, me parece que deberían cuidar un poco más la presentación del producto. Son Google, no una frikistartup.

Lo que me más me ha extrañado ha sido el precio. Dado que ni están en Beta, debería ser gratis hasta cierto límite. Pero no, de gratis nada. Más aún, es más caro que Amazon S3. Comparemos:

• Coste por Gigabyte al mes: Google=$0.17 , Amazon=$0.15
• Coste por Gigabyte de subida de datos: Google=$0.10 , Amazon= $0.1
• Coste por Gigabyte de bajada de datos: Google Americas y EMEA=$0.15 , Amazon=$0.15
• 1.000 peticiones PUT, POST, LIST = Google=$0.01 ,  Amazon=$0.01
• 10.000 peticiones GET, HEAD: Google=$0.01,  Amazon=$0.1

El coste por gigabyte guardado es $0.02 menor en Amazon, pero dado que Amazon ofrece descuentos importantes en función del volumen, esta cifra disminuye en cuando pasamos de los 10TB de almacenamiento.

La verdad es que no veo todavía ninguna razón por la que alguien quisiera migrar de Amazon S3 (o de cualquier otro servicio similar) a Google Storage. No se integra con Google Apps, y por si fuera poco Google no explica cual es su arquitectura de red y sistemas, así que no sabemos si puede tener interés para reducir latencias a la hora de servir datos, por ejemplo. Es decir, nos piden que confiemos a ciegas en un producto más caro, más oscuro e inmaduro.

Quien quiera probar el servicio, debe apuntarse a una lista de espera. Y solo si eres un ciudadano americano podrás hacerlo. Así que si alguien consigue una cuenta y lo prueba, estoy encantado de ofrecerle el blog para que nos cuente la experiencia.

Actualización: Google ha anunciado que los primeros 100GB de almacenamiento y los primeros 300GB de transferencia son gratuitos durante el período de preview.

Tags: almacenamiento, google

Google ChromeOS y el cambio de paradigma en la computación

Jul 8, 2009 cloud, opinion

Parece que Google quiere darnos unas cuantas noticias interesantes estos días. Hoy anuncia que sí, que está desarrollando un Sistema Operativo, y que se llamará ChromeOS porque estará pensado para las aplicaciones en la red. Según dicen ellos, será un SO pensando en las nuevas necesidades de los usuarios: rápido, simple y seguro. El arranque será ultrarápido y se podrá navegar en segundos. La interfaz será mínima, delegando todo el trabajo al navegador, Google Chrome, claro está.

El SO correrá sobre un kernel Linux y sobre una nueva interfaz de ventanas simple. Todo el desarrollo visual será web (o bien eso he entendido). El sistema operativo abarcará desde netbooks hasta PCs de sobremesa, y su código fuente como no podía ser de otra manera, será abierto. Funcionará sobre microprocesadores x86 y, atención, sobre arquitecturas ARM. Esto es algo que muchos no han prestado demasiado importancia.

Ok, todo muy bonito, pero ¿por qué ahora? Llevamos oyendo del GoogleOS desde 2006. Sabemos Eric Schimdt es un gran defensor de aquel precioso slogan de Sun ‘The Network is the Computer’, y que tiene a Microsoft en el objetivo desde hace tiempo. ¿Lo hacen para eclipsar el lanzamiento de Windows 7? Si, probablemente sea así, pero la verdadera causa es la aparición de netbooks con versiones adaptadas de Google Android. La gente que los ha probado comenta que realmente Android está pensado para pantallas táctiles y pequeñas, no para netbooks con teclados, haciendo la experiencia muy decepcionante. Por eso, Google ha decidido anunciarlo ahora y no esperar al lanzamiento de Windows 7.

Un detalle que se ha pasado por alto es el soporte para microprocesadores ARM y no solo para arquitecturas x86. Es decir, Google ataca directamente al duopolio Wintel, y al monopolio Intel. No olvidemos que Linux, Windows y OSX mayoritariamente corren en arquitecturas x86 (bueno, Linux corre en todo…). ARM es un microprocesador mucho menos agresivo en consumo que x86, lo cual lo hace ideal para dispositivos desconectados, y aquí llegamos al verdadero objetivo de Google: La computación ubicua.

Este nuevo Sistema Operativo delega toda la lógica computacional a servidores de terceros, centrándose únicamente en la experiencia de usuario a través del navegador. Es decir, la computación se hará en las Nubes, confirmando la apuesta creciente de Google por el Cloud Computing. Proveedores de Servicios de infraestructura y aplicaciones que ofrecerán servicios a los usuarios en modo utility.

Por último y para que este puzzle encaje, Google debe dar un paso para ofrecer acceso barato a las redes inhalámbricas. Este es un mercado muy controlado por las Telecos, en su conjunto y aliadas con los reguladores regionales mucho más poderosas que Microsoft e Intel juntas. En ese momento, podremos decir que se ha completado la transición que empezó en el Mainframe, y que puede culminar en el Utilility Computing, el objetivo final del Cloud Computing.

Tags: chromeos, google

Google Apps (Gmail, Calendar, Docs and Talk) dejarán hoy de estar en Beta

Jul 7, 2009 saas

¡Qué bueno volver de vacaciones y encontrar que la gente sigue trabajando! entre los más de 500 correos pendientes y los varios miles de feeds, descubro en el Blog oficial de Google que sus servicios de Google Apps dejarán hoy día 7 de Julio (San Fermín) de estar en Beta.

GMail por ejemplo llevaba cinco años en Beta. Se ve que los chicos de Google son concienzudos. Y según parece se han dado cuenta de algo que si trabajas en el mundo del software sabes desde hace tiempo:

Nos hemos dado cuenta que la etiqueta ‘Beta’ es algo que no encaja para las grandes empresas, ya  que no desean llevar su negocio sobre software que suene a algo que está aún en fase de pruebas.

Gran verdad. Espero que muchos otros que ponen la etiqueta ‘Beta’ no para indicar que el software está en desarrollo (yo creo que todo el software en general está siempren en constante evolución y por lo tanto en desarrollo), sino para dejar claro que no asumen ninguna responsabilidad sobre el Nivel de Servicio. Así que espero ver muchas empresas (especialmente SaaS) que pasen del modo Beta al modo Final, de una vez.

Tags: gmail, google

Google AppEngine para Java. Ya está aquí

Apr 8, 2009 google

Si hubo una petición que se repitió hasta la saciedad en el último Google Developers Day en Madrid fue que Google AppEngine soportara Java. Bueno, pues ya está. En el blog de Google App Engine podemos leer que ahora va en serio:  Tenemos Java dentro del Google AppEngine.

Dicen que Java ha sido el lenguaje que más se ha solicitado. Hay otros, pero está claro que el Rey de los lenguajes es Java desde hace unos 10 años. C sigue vivo, pero la presencia de Java es aplastante. Hay muchas razones para entender que estamos ante el lenguaje de programación de toda una generación de ingenieros, pero creo que la más importante es que su comunidad de desarrolladores ha evitado el ‘casarse’ con nadie (Que se lo digan a Sun Microsystems…).

Las malas lenguas me han contado que Google tenía miedo a liberar Google AppEngine para Java ya que la avalancha de peticiones en su plataforma iba a ser tan brutal que ni ellos tenían recursos para atender la demanda. Por eso empezaron con un lenguaje elitista como Python. Parece que han superado esos problemas de capacidad.

No dan muchos detalles de la implementación dentro de AppEngine, pero comentan que soportará el API de Servlets, JDO (¿cómo?) y JPA (ah…), javax.cache y javax.mail. No dicen nada de ningún framework de desarrollo tipo Spring, o un MVC tipo Struts… ¿vamos tener que tirar de Servlets? ¡Espero que no! ¿Usaremos GWT? Creo que sí… Además hay un Google Plugin para Eclipse que ayudará en el desarrollo ydespliegue.

Una de las restricciones de la plataforma es que corre dentro de un ‘sandbox’ que controla lo que se puede hacer dentro de los servidores de Google. Así que seguro que no es coger tu código y desplegar tal cual. Habrá que currarse la adaptación a su plataforma. Por ahora, hay 10.000 cuentas disponibles para pruebas. Así que corre a pedir tu cuenta de pruebas aquí.

Está claro que Google sigue trabajando duro en su apuesta de Platform as a Service (PaaS), y abrir la plataforma a Java es acceder a un mercado de millones de desarrolladores y prácticamente la totalidad de los estudiantes de Ingeniería Informática (o Ciencias de la Computación fuera de España). Creo que como solución enterprise todavía es muy limitada, pero el Cloud Computing sigue bajando los gastos necesarios para montar una startup gracias a soluciones de este tipo. ¡Enhorabuena Google!

Actualización: Me ha pasado Pedro Navarro de Abiquo este un video con una demostración de la plataforma y su integración con eclipse

Tags: appengine, google, java

Google App Engine ya tiene planes de precios

Feb 25, 2009 google

Parece que hoy Google quiere ser el protagonista de los medios. Después de los problemas con Gfail Gmail, Google anuncia sus planes de precios para Google App Engine. Después de casi un año desde que se abrió la plataforma de Cloud Computing de Google al publico, por fin podemos usarla para algo más que las aplicaciones que su limitada cuota gratuita ofrecía. La lista es la siguiente:

• $ .10 por CPU a la hora (Amazon Web Services (AWS) carga desde $.10 hasta $1.20 dependiendo de la potencia de la máquina)
• $.10 por Gb de transferencia hacia AppEngine ($.10 carga AWS para transferencias hacia S3)
• $.12 por Gb de transferencia desde AppEngine ($.17 carga AWS para transferencia desde S3 hasta 10Tb/mes)
• $.15 por Gb almacenado al mes ($.15 carga AWS por los primeros 50Tb/mes almacenados en S3)
• $.0001 por correo

Los desarrolladores sólo pagarán cuando su aplicación supere los límites gratuitos establecidos. Estas cuotas se reducirán dentro de 90 días, hasta los cinco millones de páginas vistas al mes.

La mala noticia es que al parecer sólo podrás pagar a través de Google Checkout. Esto significa que los servicios están restringidos a los USA y UK. No lo tengo muy claro, pero es lo que dicen en O’Reilly Radar.

Sobre los nuevos lenguages (Java especialmente) y el tema de procesos batch, nada de nada por ahora.

Actualización: Google Checkout está disponible en casi todas partes. Los servicios NO están restringidos a los USA y UK. Han modificado la entrada en  O’Reilly Radar.

Tags: appengine, google

El día que GMail falló y el mundo aprendió lo que significa "Beta"

Feb 24, 2009 google

Salía de una reunión y me pareció oír una conversación de fondo ‘Creo que GMail no funciona’, decían. Pero uno no da crédito a esas y cosas, y piensas: “Serán ellos, su red o su proveedor”.

Al llegar a la oficina, nos lo confirman: “GMail” está caído desde las 10 y pico de la mañana. Intento entrar en mi cuenta, y efectivamente, no puedo. Un bonito error me lo confirma. Intento entrar usando https:// en vez de http:// y voila!, consigo entrar. Je,je… que listo soy y que tonto es el mundo… oh wait! estoy en modo offline y la aplicación está tirando del Google Gears. Bueno, por lo menos puedo leer los correos que tengo pendientes de la noche y la mañana, aunque bajarse correos nuevos, nada de nada. ¡Gracias chicos de Google Gears!

La mañana sigue avanzando y nuestros temores se confirman: no sabemos trabajar sin correo electrónico. Alguien preguntó: ¿cómo se trabajaría antes del correo electrónico en las empresas? Nadie responde… incluso yo en 1994 ya tenía un rudimentario sistema de correo electrónico interno, y email desde 1992 en la universidad, si mal no recuerdo. Somos adictos al correo electrónico. No podemos funcionar sin él.

Pero lo de esta mañana no es un problema de adicción al email, es un problema de dependencia pura y dura de Google. Las empresas se han parado porque un servicio que se daba por garantizado por Google ha fallado. Hace 9 años, cuando empecé a trabajar en Consors, el CTO de Alemania vino a España y me dijo: ‘Evita tu momento CNN‘. Es decir, nunca, nunca, nunca debes salir en las noticias por una caída del servicio. Pues Google hoy ha sido portada en los noticiarios de medio mundo. Ha tenido su ‘momento CNN‘.

¿Podemos culpar a Google por la caída del servicio? Si, claro, lo dan ellos… ¿pero podemos pedirles responsabilidades? Pues no, porque el servicio se encuentra en ‘Beta’, y claro, ya se sabe lo que pasa con los servicios en Beta: siguen en pruebas. Y pueden fallar.

Hoy lo han aprendido millones de usuarios.

Tags: gmail, google

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

Feb 19, 2009 cloud, estudios

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)

Tags: amazon, berkeley, estudios, google, iaas, microsoft, paas, saas

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

Feb 18, 2009 cloud, estudios

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

Tags: amazon, berkeley, estudios, google, iaas, microsoft, paas, saas

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

Feb 17, 2009 cloud, estudios

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

Tags: amazon, berkeley, estudios, google, iaas, microsoft, paas, saas

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

Feb 16, 2009 cloud, estudios

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

Tags: amazon, berkeley, estudios, google, iaas, microsoft, paas, saas

10 millones de usuarios corporativos en Google Apps

Feb 3, 2009 cloud, google, saas

Sorprendente lo que leo en eWeek. ¿10 millones de usuarios corporativos en Google Apps? ¿Un millon de empresas? Si un asiento de pago son $50, ¿están facturando $50 millones? ¿Los asientos son de pago?

Vale, pero de estos, ¿cuantos pagan?

Vamos en primer lugar a ver lo del millon de empresas. ¿cómo saben que es una empresa? Que yo sepa para registrarse en Google Apps solo se necesita un dominio, no te piden información fiscal ni financiera. De hecho, este humilde blog tiene una cuenta de Google Apps asociada, y no soy empresa.

Y ahora con los 10 millones de usuarios corporativos. Un usuario es un asiento o tenant en nomenclatura SaaS. Y puedes darte de alta en Google Apps con 50 asientos máximo de manera gratuita. Y lo de corporativo, ¿significa que perteneces a una cuenta de Google Apps, a una empresa o que pagas por tu asiento?

Señores de Google, les admiro por ser capaces de desarrollar una plataforma que de servicio de manera admirable a 10 millones de usuarios. Pero la próxima vez ¿por qué no nos dicen cuantos asientos son de pago y cuantos no? Así sabremos cual es la verdadera dimensión de su negocio.

Actualización 21:00 : La fuente de la información en eWeek es un informe de Technology Business Research,como apunta José Frenchin en un comentario.

Tags: google, negocios, saas

¿Para qué quiere Google GDrive?

Feb 2, 2009 google, opinion

Uno de mis blogs favoritos es SmoothSpan Blog. Su autor, Bob Warfield es un exempleado de Borland, con larga experiencia en el mundo de las ITs, especialmente en el SaaS y el Cloud Computing. Ha dado una vuelta de tuerca a la inminente aparición de GDrive, y sus conclusiones son sorprendentes.

El concepto detrás de Google GDrive no es nuevo, hay productos similares en el mercado, a saber:

• Skybox de Microsoft
• MobileMe de Apple
• Mozy de EMC (ahora Decho)
• Jundle Disk (comprado recientemente por Rackspace)
• Dropbox

Y hay más. Zumodrive aún no lo he probado, pero espero hacerlo pronto.

Así que, ¿qué nos va ofrecer Google que sea diferente? ¿Cómo va a ganar dinero Google con este producto? No está claro cómo lo va a hacer, pero parece que el producto será gratuito y con una capacidad muy superior a la de sus competidores. ¿Cómo lo va a hacer Google?

El secreto puede estar en su integración con Google Apps. Google está detras del negocio de Microsoft Office, y una de las razones que evita su adopción es la incompatibilidad entre ambos sistemas. A Microsoft no le interesa trabajar con estándares abiertos -ellos son el estándar de facto-. Así que es Google la que tiene que hacerse compatible con Microsoft Office.

Lo que plantea Bob Warfield es que Google podría ofrecer su plataforma GDrive para acceder a una cantidad ilimitada de ficheros que serían el perfecto campo de pruebas para garantizar la mejor compatibilidad posible entre ambas herramientas ofimáticas. No está mal la idea. No se trata de procesar la información y cruzarla en sus bases de datos para sacar un perfil, sino solo buscar la manera de garantizar una migración a Google Apps lo más sencilla posible.

Y va más alla. Ya que Google tiene acceso a GDrive, ¿por qué no sacar perfiles de usuarios en función del tipo de fichero almacenado? Es decir, no mirar el contenido, pero si las extensiones del fichero y probablemente su nombre. Podrán saber qué tipos de fichero son los que interesa almacenar. Cuales son las extensiones de fichero realmente importantes. Y dado que saben a quien pertenecen los ficheros, pueden crear un perfil sobre tu persona. Si es una persona con muchas hojas de cálculo y presentaciones powerpoint probablemente sea un directivo. Cruza la información con lo que sabes de esa persona por su historial de navegación, el contenido de su GMail y obtendrán un perfil bastante ajustado a la realidad. Y esta información puede hacer que sea rentable dar el GDrive gratuitamente.

Diabólico, incluso para una empresa que su lema es ‘Don’t be Evil’.

Tags: gdrive, google, opinion

debug_mode=ON entre los ganadores del Seedrocket

Jan 29, 2009 eventos, paas

Ahora veo que debug_mode=ON es un proyecto ambicioso, al que se está dedicando suficiente empeño como para presentarlo a SeedRocket y que además llega a ser uno de los tres proyectos ganadores, junto con Habitissimo y Ongest de los que ya hablaré más adelante.

Javier Martín, Loogic

Como dice Javier en su blog, no es un proyecto cualquiera. Y no creo que lo sea porque se trate de una red social para desarrolladores o porque hayan sido uno de los ganadores del SeedRocket. Lo que hace especial a un proyecto es el equipo, y este es de primera. Si estás metido en el mundo del Java hispano probablemente hayas oido hablar de alguno de ellos. 

<ironic mode on>Les perdonaremos que hayan desarrollado la aplicación en la fracasada Platform as a Service de Google, el Google App Engine. Y pasaremos por alto que la han programado en Python.</ironic mode on>

Ahora en serio, el equpo de desarrollo se ha tenido que pegar con todos los problemas de Google App Engine, y en el Google Developer Day vimos como necesitaban más cuota en el servicio desesperadamente. Google parece que se portó bien y ahora disponen más que la cuota estándar. De manera especial, me alegra ver como desarrolladores con talento deciden compaginar la parte técnica con la parte emprendedora. No es habitual, y necesitamos más gente así.

¡Enhorabuena chicos!

Tags: appengine, debugmodeon, eventos, google

Por qué Amazon Web Services sí tiene éxito, y Google App Engine no

Jan 23, 2009 cloud, opinion

Llevo meses pensando si escribir sobre esto o no. Es un tema un poco peliagudo ya que son impresiones mías y de los que me rodean sobre el éxito de las ofertas de Cloud Computing de dos pesos pesados: Amazon Web Services y Google App Engine. Pero este artículo de James Urquhart me ha recordado la polémica y me ha animado a escribir sobre ella, porque creo que ha dado en el clavo.

Creo que Google App Engine está siendo un fracaso para Google. No ha conseguido tener mucha presencia y además no ha captado el mercado empresarial. ¿Las causas? Varias en mi opinión, a saber:

• La magnífica labor de Evangelización tecnológica que hacen la gente de Amazon Web Services. Esto además ha sido reconocido nombrando a Werner Vogels CTO del año por Information Week. Puedes seguirles en twitter, en su blog y sobre todo por eventos en todo el mundo.
• Los casos de éxito de Startups que se han subido a La Nube de Amazon. Los más conocidos son SmugSmug y Animoto, aunque hay más, bastantes más.
• Una orientación hacia la empresa, ofreciendo Acuerdos de Nivel de Servicio, por ejemplo.
• Una visión de 360º respecto a los mercados potenciales para su Nube: no hay solución que no pueda migrarse.

Lo cierto es que Google App Engine no tiene la maquinaria de marketing que tiene Amazon Web Services. Pero tampoco tiene casos de éxito sonados como los de Amazon. Las posibles razones para que no haya despegado este servicio se pueden deber a las restricciones del lenguage (Python). Sabemos que Google está migrando Google App Engine para otras tecnologías -probablemente Java- aunque es algo que no han confirmado. La plataforma de Google, por su naturaleza PaaS tiene un tipo de aplicaciones objetivo: aquellas aplicaciones Web que necesitan escalado masivo y manejo masivo de datos ‘a lo Big-Table’, sacrificando las bondades del modelo relacional.

Creo que Google App Engine y las otras propuesta PaaS (Azure, Caroline…) son el verdadero futuro del Cloud Computing. Cuando Google abra App Engine a nuevos lenguajes como Java, el número de desarrolladores crecerá de manera exponencial. Solo será cuestión de tiempo que empiecen a crear aplicaciones. El tema de las aplicaciones empresariales yo no lo tengo tan claro… ¿realmente a Google le interesa ofrecer una plataforma cuyo contenido no puede indexar, y por lo tanto no puede ganar dinero con AdSense? Recordemos que Google vive de AdWords y AdSense: su interes es ofrecer plataformas y herramientas para crear más y más contenido PUBLICO. Por su naturaleza, en las aplicaciones empresariales el contenido es privado.

Tags: amazon, appengine, ec2, google, s3

Abogados, Lecheras, Cuentos y Nubes

Jan 20, 2009 cloud, opinion

Abogaaaaaaadoo (El cabo del miedo)

Supongo que a todos nos han contado el cuento de la lechera. Ya sabéis, ese tan bonito en que una lechera aspirante a broker de derivados en la City lo pierde todo por tropezar en una piedra. La semana pasada un abogado nos contó una nueva versión del cuento: ‘El cuento de la lechera 2.0′. En esta nueva versión del cuento, el prestigioso abogado Javier Mestre se mete en la piel de Pepito Grillo y nos muestra lo malos que son los consultores tecnológicos sin escrúpulos, y lo malo, malísimo que es Google y sus aplicaciones en La Nube: Google Apps Premier Edition. Ya hay suficientes reacciones en la blogosfera para que encima venga yo a darle más palos al Sr. Mestre. Para mí el mejor post es el de Desencadenado, y desde luego echo de menos algo de pedagogía por parte de Google en su tibia respuesta. ¡Si hasta Enrique Dans ha esta bien!

Javier Mestre es una figura importante en el mundo del Derecho aplicado a las tecnologías. Creo que podía haber escrito un artículo mucho más interesante si se hubiera centrado en los verdaderos problemas que deberán afrontar las empresas que quieran trasladar sus aplicaciones a La Nube. Y estos problemas son exactamente los mismos que tienen las empresas que alojan sus bases de datos locales en países remotos. Vamos, que no es algo nuevo. Pero sí más frecuente. En un mundo donde las empresas están completamente distribuidas y por lo tanto sus Centros de Datos no conocen de fronteras aplicar legislaciones cuyo marco jurisdiccional esta limitado por las fronteras es un brindis al sol. Es imposible.

Supongo que habrá que buscar otro marco que sea capaz de dar seguridad y confianza a los usuarios, independientemente del país donde se encuentren. Y aquí es donde surgen nuevos conceptos como los que proponen la gente de la Sociedad de las Indias Electrónicas. ¿Tal vez Filés? No se si lo he entendido bien, pero son conceptos que se adaptan bien a esa estructura sin restricciones físicas que es La Nube.

Todos tenemos un mal día: pensemos bien y aceptemos que el Sr. Mestre no estuvo acertado.

Tags: google, opinion

Google busca distribuidores para Google Apps

Jan 19, 2009 cloud, negocios, saas

Hace un par de meses hablé con un emprendedor de Madrid sobre qué era necesario para que se adopte el SaaS y especialmente el IaaS (hablábamos de Amazon Web Services) en España. Mi planteamiento era que para entrar en el mercado en España es necesario revendedores de Servicios: el famoso ‘canal’. Él opinaba todo lo contrario: el SaaS permite quitarte de encima el canal, solo hay que aprovechar los medios online existentes para hacerlo. La verdad es que no acabé muy convencido

Leo en el Cloud Computing Journal esta noticia: Google busca revendedores para su suite Google Apps para facilitar la entrada de las empresas en el Cloud Computing. En este programa llamado Google Apps Authorized Reseller Program, Google ya ha firmado acuerdos con 50 ‘pilot partners’. Estos revendedores autorizados (en España usamos mejor la palabra distribuidor) podrán vender, personalizar y dar soporte a la suite Google Apps Premier Edition. Podrán investigar la creación de nuevas oportunidades de negocio para ellos si facilitan el acceso a los servicios en La Nube de Google. El software incluido es GMail, Google Calendar, Google Docs, Google Sites, Google Talk y Google Video.

Las condiciones económicas son las siguientes: 20% de descuento sobre los $50 anuales por usuario. Google no facturará directamente a los clientes, sino que serán los distribuidores los que emitirán las facturas a sus clientes, pagando luego a Google.

Cada día que pasa Google se parece más a la Microsoft de mediados de los 90. Microsoft es una empresa que ha sabido rentabilizar su canal de distribución de manera notable, con una capilaridad en su red que les permite llegar hasta la última PYME del país. Es ahora Google la que se ha dado cuenta que necesita alguien cercano (y humano) al cliente para poder vender sus soluciones.

Tags: google, negocios

Android puede ser el Sistema Operativo para La Nube de Google

Jan 3, 2009 cloud, opinion

Imagen cortesía de VentureBeat

Leo en VentureBeat (un buen blog sobre inversiones en tecnología) y en el Blog de Enrique Dans (vale, lo admito, de vez en cuando también leo a Enrique Dans: ya podéis crucificarme) que unos ingenieros alemanes, Matthaus Krzykowski y Daniel Hartmann, han compilado Google Android para un netbook Asus EeePC 1000H.

Pero oiga, ¿Android no es un sistema operativo para móviles? Bueno, no exactamente. Google ya dijo que su idea era usarlo en cualquier tipo de dispositivo, y una arquitectura x86 es un dispositivo como otro cualquiera. Así que estos ingenieros en aproximadamente cuatro horas consiguieron crear una versión con gran parte de los dispositivos del EeePC funcionando. Android está basado en Linux, y cualquiera que conozca un poco de Linux sabe que es altamente portable. Pero una cosa es que sea altamente portable y otra es que se tarden cuatro horas. Esto solo se consigue si el sistema realmente está bien diseñado y el código está preparado para compilación sobre múltiples entornos.

Google Android para dispositivos móviles tiene la gran baza de ser un Sistema Operativo basado en código abierto y por el que Google no cobra licencia. Así que si lo comparamos con el líder del mercado, Symbian que sí cobra, en un mercado donde los márgenes son estrechos y la competencia feroz, todo lo que sea ahorrar en el precio final del dispositivo, bienvenido sea. Un colega que trabaja en Nokia me comentaba que un teléfono con Symbian puede ser hasta 50% coste de hardware, 50% coste de software. Imaginad si se puede eliminar ese 50% de software como pretende Google: más gente podrá tener dispositivos más potentes, lo cual redunda en más páginas vistas con más Google Adsense incrustada (que a fin de cuentas es el modelo de negocio de Google).

Pero veamos que está pasando con la migración de aplicaciones a La Nube: aplicaciones que corren en navegadores con requisitos de rendimiento y almacenamiento más que modestos. Es decir, el ecosistema ideal para equipos más pequeños y baratos (¿aún no he pronunciado la palabra netbook?). Y de nuevo, tenemos que cuanto más baratos son los ordenadores, más relevante es el precio de la licencia del sistema operativo. La diferencia entre un netbook con Windows XP y con Linux va del 10% al 20% del precio final. Si a eso le unimos licencias adicionales por drivers propietarios u otro software, nos encontramos con un modelo similar al de los dispositivos móviles.

Si vemos la estrategia de Google respecto a su Plataforma de Servicios, podemos identificar claramente una tecnología suya en todas las capas, desde BigTable a Chrome… exceptuando el Sistema Operativo. Pero parece que esto es solo cuestión de tiempo.

Tags: android, google, netbook

Google App Engine pronto en tu propio Centro de Datos

Dec 5, 2008 cloud

En el evento Google Developer Day 2008 en Madrid, una de las preguntas que más sonaron entre las asistentes era si es posible ejecutar Google App Engine fuera de La Nube de Google. Bueno, más bien si es posible montar tu propia Nube en tus servidores o en tu Centro de Datos y ejecutar tus aplicaciones desarrolladas para Google App Engine en tu propia infraestructura. Hubo gente que comentó que al parecer ya hay gente corriendo el App Engine sobre Amazon EC2. Bueno, con trampa, ya que únicamente montó la versión de desarrollo que todos podemos montar en nuestro PC. Eso, no cuenta como Nube. Y así quedó todo.

Leo en Plugintothecloud.com que hay una compañía -trabajando en ‘Stealth mode‘- que permitirá ejecutar las aplicaciones como si corrieran en la infraestructura de Google. Según el Product Manager de Google Peter Koomen, “Permitirá coger tu aplicación App Engine y ejecutarla en tus propios servidores si es necesario”.

Pero parece que no es la única empresa que está trabajando en crear una capa puente entre las tecnologías de Google y las tecnologías no Google. Y es ahí donde entran en juego nuevos conceptos como las núbes híbridas, unión de las nubes privadas y públicas. Este concepto parece ser clave en la adopción del Cloud Computing por parte de las grandes empresas, y un tema que intentaré tratar en futuros posts.

Mientras, esperaremos a que salga del anonimato la empresa que está desarrollando este producto para poderlo revisar.

Tags: appengine, google, hosting

Google Online Storage System rumours

Dec 12, 2007 Uncategorized

Tags: google, rumours, storage

Using the Google Chart API from the server side

Dec 9, 2007 Uncategorized

Tags: api, chart, development, google