Amazon ha anunciado la publicación de repositorios públicos de datos, accesibles únicamente desde sus entornos EC2. Es decir, puedes montar estos datos en su ‘Nube’ y usarlos como quieras sin pagar nada, únicamente el tiempo de uso de las instancias EC2. Según dicen:

Nuestra meta es proveer un acceso sencillo a datos de datos públicos y comunes como el genoma humano, astronomía y al censo de los USA.

Además si tienes un conjunto de datos interesante, puedes solicitar su publicación y donar los datos a la comunidad. Como podéis ver, todo muy bonito y… ¿altruista? Bueno, todo lo altruista que debe ser una empresa: evidentemente Amazon espera recuperar el dinero invertido cobrando por el uso de EC2.

La pasada semana tuve una agradable reunión con un defensor del SaaS, y uno de los temas que han salido es el de la captura y explotación de datos de y en La Nube. Y casualmente va Amazon y saca a la luz este proyecto…

Cuando pienso en explotación de datos pienso en Business Intelligence, Datawarehouses y Datamining: lo que he visto en la empresa. Recuerdo una asignatura llamada ‘Bases de datos avanzadas’ (nosotros la llamábamos ‘Bases de datos Avanzadísimas’…). En ella se estudiaba un par de conceptos nuevos llamados ‘Datawarehouse’ y ‘Datamining’. Fascinantes conceptos en aquella época, pero nuestros profesores se empeñaban en darle más importancia a los conceptos teóricos formales que a la verdadera razón por la que explotaron los DW y los DM a mediados de los noventa: El coste de proceso y el coste de almacenamiento bajó de manera drástica, permitiendo el manejo de datos en tiempos más reducidos y por lo tanto, ajustados a la velocidad que necesitan las diferentes Unidades de Negocio para tomar decisiones. ¡Por fín era rentable explotar estos datos! Una característica fundamental de estos almacenes de datos es que trabajan con información interna de la empresa. Es decir, su ámbito es el de la corporación X o corporación Y (departamento X o departamento Y… datamarts). Resulta impensable que una corporación X ponga a disposición de sus competidores su Datawarehouse…¿o no?

Estamos a finales de la década y la situación es muy diferente: el coste de almacenamiento tiende a cero, la computación se compra por tiempo de uso, el ancho de banda aumenta y el precio se congela… El coste de proceso y almacenamiento pueden llegar a ser irrelevantes cuando manejamos grandes cantidades de datos. Y en la parte software, algoritmos como Map/Reduce surgen como alternativa a los modelos relacionales clásicos, menos eficientes para grandes volúmenes. Estamos ante el nacimiento de una Nueva Generación de Data Warehouses.

¿Pero con qué datos vamos a alimentar a esta Nueva Generación? Veo tres fuentes básicas:

1. Las propias organizaciones. No todos los datos entraban en el data warehouse, pero ahora empieza a ser factible almacenar todos y cada uno de los datos manejados en las organizaciones. Aquí entraría el almacenamiento ‘crudo’ de información recogida de las arquitecturas M2M, por ejemplo.
2. Los proveedores. De igual manera que se acuerdan niveles de calidad de servicio a proveedores clave, se podrán demandar datos ‘crudos’ a éstos. Ya se hace, pero normalmente ligado a las métricas de calidad.
3. Proveedores de Bancos de Datos: Como Amazon. Cobrando de modo directo o indirecto por el acceso a estos bancos públicos de datos. Con el tiempo, este tipo de proveedores ofrecerían datos menos genéricos y más orientados a segmentos de negocio. Posiblemente, estos proveedores de bancos de datos serán ‘Brokers’ entre organizaciones afines. Ya sea mediante la forma de consorcios o fundaciones que garanticen la ‘neutralidad’ de estos datos, o bien mediante mercadeo de datos como si fuese otra mercancia.

Lo cierto es que esta nueva generación de Data Warehouses ya existe. Hace unos años, una empresa con un novedoso software de reconocimiento de textos nos comentó cómo una importante empresa americana de tarjetas de crédito no sólo estaba digitalizando todo su almacén de datos en papel, sino que compraba bases de datos en cualquier formato con la esperanza de poder cruzarlas en el futuro. Sabían que sólo era cuestión de tiempo que el coste de cruzar estos datos compensase sus esfuerzos por calcular el riesgo de sus clientes de manera más avanzada. Y en muchas ocasiones el problema no era de costes, sino de acceso a los recursos, por sorprendente que parezca.

Actualización 9:30am: Via twitter.com me llega esta empresa que parece que intentan mover este negocio usando Amazon AWS: http://datamarket.net/

Parece que no estoy solo en mis impresiones sobre lo decepcionante que ha sido el SLA de Amazon EC2. En la lista de correo sobre Cloud Computing de Google podemos leer en este hilo una serie de comentarios realmente interesantes. Publico algunos de ellos:

…Nuestros abogados revisaron el Acuerdo de Servicio de EC2 y dicen que es completamente inaceptable, excepto para I+D. Amazon no asume ninguna responsabilidad por nada, y pueden cambiar unilateralmente el Acuerdo de Servicio en cualquier momento. Y el “SLA” parece que es puro marketing, ya que aparentemente no tienen ningún compromiso para alcanzar el SLA en el Acuerdo de Servicio. Así que no hay un SLA de verdad…

…Ellos (Amazon) on tienen ningún interés en negociar un acuerdo especial con clientes individuales, y nadie espera que lo hagan. … Simplemente si te cansan de AWS, lo dejas de usar y te vas a otro sitio. (…) Es posible que en el futuro la oferta de cloud de AT&T, IBM o HP tenga un SLA que cubra las expectativas de los abogados…

…Creo que estamos viendo cómo el SLA cambiará la competición (del Cloud Computing). …estamos viendo un modelo en evolución. (…). EC2 es un éxito entre el grupo de desarrolladores web que se mueven a gran velocidad: los que configuran primero y luego leen los términos del contrato después.  …para las empresas es diferente, buscan plataformas con costes más bajos lo que significa que tienen que prestar atención en cómo protoger el valor…

… La competencia llevarán los contratos y los precios a lugares más usables a nivel de los usuarios, y la confianza de las empresas mejorará. Este es el comienzo de una nueva industria…

… De verdad que no lo entiendo.  Su servicio es menos que mínimo para un 24×7, y su acuerdo de servicios les permite echarte de la plataforma “por cualquier razón y sin razón” con un preaviso de 60 días… 

… Es completamente razonable esperar por lo menos los Términos de Uso de un alojamiento compartido, pero están lejos de eso. …es imposible usar EC2 para algo que no sea I+D. 

… Hoy en día ninguno de los proveedores de Cloud (EC2, GoGrid, AppEngine, Azure, el que sea…) ofrece el tipo de seguridad que necesitan este tipo de aplicaciones (empresariales) en La Nube. … en el futuro los IBM, HP y demás tendrán ofertas que les permitarán mover estas aplicaciones a La Nube…

You can’t control what you can’t measure

Tom DeMarco

Cuando el otro día leí el anuncio del paso de Beta a Producción de Amazon EC2 me pareció una noticia interesante ya que con ello se anuncia la existencia de un SLA asociado al servicio. Pero cuando leí el SLA… me pareció decepcionante.

Para mi desgracia he tenido que lidiar con unos cuantos Acuerdos de Nivel de Servicio. Tanto en el lado del cliente como el del proveedor, y puedo asegurar que pueden ser documentos infernales, donde se computan docenas de métricas para garantizar el nivel de servicio contratado u ofrecido. ¿Y cuantas metricas tiene el SLA de Amazon EC2?

¡Una! Annual Uptime Percentage o Porcentage de Disponibilidad Anual. Es decir, la única métrica válida es si nuestras instancias se encuentran en estado ‘Región No disponible’. ¿Y cual es el umbral de tiempo definido? Pues un 99.95% anual, 4.38 horas exactamente en un año. No está mal.

Pero la mayoría de las veces no nos sirve una métrica que nos diga si funciona o no funciona. Necesitamos otro tipo de métricas que nos indiquen:

• Tendencias: ¿se está degradando el servicio?
• Quality of Services (QoS): ¿La calidad que nos ofrecen está por debajo de los umbrales establecidos?
• Metricas derivadas: Estadísticas acumuladas y correladas entre sí.

Estas métricas (y otras muchas) son las que piden los clientes empresariales, ya que tienen herramientas que permiten gestionar esto en sus sistemas. Todos las grandes empresas tienen sus Tivoli, Patrol, Openview para controlar el nivel de servicio de sus sistemas.

Hace unos meses un director de Amazon AWS me preguntaba que le faltaba en mi opinión a Amazon Web Services para que fuere ‘Enterprise-class’. Le dije tres cosas:

• Un SLA
• Una red de integradores
• Una red de formación en sus tecnologías

Creo que el SLA de Amazon no va a cubrir las expectativas mínimas para aplicaciones empresariales. Y me temo que cuando haga presentaciones de Amazon EC2 y sus bondades a potenciales clientes, ante la pregunta de cómo monitorizar el nivel de servicio, tendré todavía pocos argumentos para justificar La Nube como un entorno para el software empresarial.

Pero bueno, por lo menos es un comienzo.

Ayer se anunció en el foro sobre EC2 de Amazon pequeños cambios para mejorar el servicio de IPs virtuales (o elásticas como dicen ellos).

Los cambios introducidos son dos:

• Un mapeo más rápido de las direcciones IP elásticas. Ahora un cambio podía tardar unos cuantos minutos. No se cuanto se tardará ahora, pero lo probaremos.
• Las conexiones existentes cuando se realiza un remapeo son eliminadas de manera inmediata. Ya no hay que esperar a que el stack de red se de cuenta de que ya no existe conexión con el extremo. Hasta ahora lo que ocurría es que las conexiones abiertas se quedaban así durante un rato. 

Estos cambios afectan a su infraestructura, pero no afectan al código de nuestras aplicaciones. Bueno, yo creo que puede tener un efecto positivo ya que no tienes que preocuparte de implementar algoritmos de ‘KeepAlive‘ entre tus sistemas en la nube.

Al final tenía que pasar. En el blog del CTO de Amazon, Werner Wogels, se anuncia que será posible lanzar instancias de Amazon EC2 que soporten Windows Server. Resulta curioso que uno de los principales argumentos para correr Windows en la nube es que facilitaría la conversión de los contenidos a formatos propietarios de Microsoft (¿No sería más facil usar formatos abiertos?). 

No hay mucha información sobre qué tipo de virtualización se va a usar, aunque creo que XEN no es lo más adecuado para correr Windows (aunque hay gente que lo hace, es un poco rebuscado y con mal rendimiento). Tampoco se dice nada sobre el coste del servicio y lo que yo considero fundamental cómo se licenciará el uso de Windows: ¿se usarán licencias que ya posea el usuario o bien Amazon te ‘alquilará’ las licencias en función de uso?

Muchas dudas, pero seguro que poco a poco tendremos más información sobre el tema. Por ahora la beta es privada, pero se puede intentar solicitar la entrada en el grupo de beta testers aquí.