Information Week ha elegido a Werner Vogels Chief of The Year. Werner Vogels es el Chief Technology Officer the Amazon, y uno de los responsables del éxito de Amazon Web Services. Werner Vogels se unió al equipo de Amazon en 2004. Holandés, tiene un doctorado por la universidad Vrije de Amsterdam (la misma de Tanenbaum ¿Casualidad? pues mira que no lo creo…). Antes de unirse a Amazon estuvo investigando sobre Grandes Sistemas Distribuidos en la Universidad de Cornell.

Según cuentan en el artículo, Amazon Web Services nació como Plan de Negocio antes de que Vogels fuese contratado por Amazon. Andy Jassy un Senior VP de Amazon que por el año 2002 era el consejero tecnológico de Jeff Bezos empezó a preparar un Plan de Negocio para solucionar uno de los problemas derivados por la apertura de la plataforma tecnológica de Amazon a terceros: escalar las comunicaciones entre los sistemas de Amazon y los terceros. Así, en 2004 nació Simple Queue Services (SQS), y en los años siguientes el resto de servicios ya conocidos de AWS.

Como nota curiosa, Werner Vogels reporta a Jassy. Pero Vogels no es el único responsable del éxito de AWS. El Technical Manager es el VP Charlie Bell, y el VP Adam Selipsky se encarga de la gestión de los 440.000 clientes que tienen en los servicios. Que el premio se lo hayan dado a Vogels era algo a lo que Amazon no ponía buena cara, ya que entienden que es un trabajo de equipo. De todos modos, una de las labores de Vogels es ser la cara visible del negocio en eventos y con los clientes -algo no habitual en un CTO-.

Una lectura muy recomendada para estas navidades. Podéis descargar el artículo en formato PDF en este enlace.

Durante la revisión matutina de mis feeds este Lunes, pude leer la siguiente noticia en el Amazon Web Services Blog: Amazon SimpleDB Grows up. Al pinchar sobre el enlace para leer el contenido en la web y no en el Google Reader, me dió un 404. Alguien en Amazon se había colado y había publicado el post antes de tiempo, cuando lo retiraron ya era demasiado tarde y era parte de la caché de Google.

A lo largo de la tarde la noticia se ha confirmado, así que ya puedo escribir con libertad sobre ello -aunque supongo que como yo otros tantos habrán leido el feed-. Amazon SimpleDB deja de ser una beta por invitación y pasa a beta pública o ‘ilimitada’, como ellos dicen. Aunque el servicio ha ido evolucionando a lo largo de los meses con cambios más o menos importantes, ahora nos encontramos ante un cambio en su política de precios bastante curiosa. Paso a resumirla:

• Los primeros seis meses, puedes consumir hasta 500Mb de almacenamiento gratis, y puedes usar 25 horas/máquina cada mes. El tráfico entre EC2 y SimpleDB, ni tampoco los primeros 1Gb de entrada y 1Gb de salida se tarificarán.
• Se baja el precio desde los $1.50 por GB al mes a $0.25 por Gb mensual

Como ejemplo, tengo un servicio corriendo en Amazon SimpleDB que no llegó a consumir ni una hora de computación al mes. Aunque he de confesar que no tiene mucho tráfico y tengo implementada una política de cache write-through que limita los hits a SimpleDB de manera drástica. Del coste mensual de mis servicios con Amazon, el más caro es EC2, luego es el ancho de banda consumido, y luego SimpleDB. Tengo muy poco contenido estático en S3, eso también es cierto.

Mi impresión es que posiblemente este es un servicio que está costando que adopten los clientes. Las razones pueden ser varias, pero voy a apuntar un par de ellas:

• La sombra del modelo relacional es muy alargada… y SimpleDB no sigue un esquema relacional.
• La posibilidad de caer cautivo de Amazon con SimpleDB es mayor que con otros servicios como S3 o EC2.
• No existe un entorno donde realizar pruebas unitarias sin pagar por ello a Amazon. Un poco como el entorno que ofrece Google AppEngine, por ejemplo. No es el coste de la tarifa -no es relevante-, son problemas de latencia y ancho de banda entre el entorno de desarrollo y el servicio SimpleDB.
• La necesidad de implementar procesos de sincronización entre las bases de datos locales de los clientes -normalmente relacionales- y SimpleDB -no relacional- dispara el coste total del servicio. Faltan herramientas que hagan esto de manera transparente.

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/

El servicio ya se había anunciado hace tiempo, pero ya está aquí la versión Beta de CloudFront, la Content Delivery Network (CDN) de Amazon. Es casi transparente para los usuarios actuales de Amazon S3, y permite distribuir contenido con tasas muy altas de transferencia a través de una red global de servidores de contenido en redes extremo. Siguiendo el esquema de otros servicios Amazon, el modelo es un puro pago por uso, sin desembolso inicial.

CloudFront funciona así: las peticiones se originan desde cualquier lugar del mundo, y se enrutan a alguna de los 14 servidores de contenido en los extremos de la red. Si el contenido no está presente en alguna de estos servidores, entonces se coge la información de S3 y se cachea en los extremos. Los extremos se encuentran localizados en:

• Estados Unidos: Ashburn (VA), Dallas/Fort Worth, Los Angeles, Miami, Newark, Palo Alto, Seattle y St. Louis
• Europa: Amsterdam, Dublin, Frankfurt y Londres
• Asia: Hong Kong y Tokyo

• Guía de inicio
• Guía para el desarrollador
• FAQ
• Guía de Referencia Rápida
• S3 Fox Organizer, el addon para Firefox

Otra característica interesante es que se puede integrar con Amazon EC2. Puedes configurar un servidor web en EC2 que sirva el contenido dinámico, y delegar el contenido estático a CloudFront. La verdad es que esto no tiene mucho misterio con un servidor Apache y URL rewrite, pero seguro que algo de magia meten por debajo…

Solo una pega: ¿Por qué no han colocado servidores en Australia y Nueva Zelanda? ¡Allí si que se nota el uso de un CDN!

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.

Mañana 22 de Octubre Amazon publicará los resultados para el tercer cuarto del año. Todos los indicios apuntan a que tras un espectacular segundo cuarto los resultados del tercero van a ser negativos. Los analistas han tomado como referencia al otro grande del E-commerce, Ebay, que ha tenido unos resultados muy discretos y que ha anunciado una importante reducción de plantilla.

Creo que es injusto comparar Ebay con Amazon. Ebay es y ha sido un desastre, fueron los primeros que usaron internet para sacar beneficio de la larga cola, los primeros que fueron web 2.0 y ¡ni siquiera se dieron cuenta! Compraron Skype para ponerlo en una estantería del despacho de su CEO… y por último y en pleno apogeo de la web social van y limitan el derecho a voto de los vendedores dentro de su Marketplace. Vamos, que ni a posta lo podían hacer peor.

En cambio Amazon sí que ha hecho bien las cosas. Le costó llegar a tener beneficios, pero lo hicieron y corrigieron sus defectos iniciales. No se ha limitado a ser una tienda en internet. Entendió que podía ofrecer su plataforma a terceros por eso ahora es posible montar tu propia tienda con las herramientas de Amazon y aparecer en los resultados de su buscador junto a sus productos o a los de otras tiendas como la tuya. Dado que la larga cola es muy larga… pues que sean otros los que la exploten gracias a mi plataforma -y yo tan contento porque cobro por su uso-. Pero entendieron que su propia plataforma no tenía porqué limitarse a las tiendas online, y decidieron ofrecer toda la gama de servicios de infraestructura IT que les permite escalar como bestias en épocas de gran afluencia a su sitio durante el año. ¿Resultado? Se han convertido en la estrella del Cloud Computing.

Amazon ha sido muy castigada durante este Septiembre y Octubre de 2008, perdiendo casi un 45% de su valor desde sus máximos. Mañana se publican los resultados, y tengo verdadera curiosidad por saber qué porcentaje de sus beneficios corresponden a la venta de Servicios en La Nube. Y sobre todo, cual es la tendencia.

Hace unos días en la lista de correo de cloud-computing alguien preguntaba sobre experiencias con MATLAB en La Nube. Cualquier que visite la lista verá que MATLAB soporta soluciones variopintas, con implementaciones de todos los colores en Grid.

Hoy leo que la misma persona que inició la conversación anunciaba que Mathworks había liberado un white paper explicando cómo usar MATLAB con Amazon Elastic Compute Cloud (EC2). El documento te lo puedes bajar aquí.

El documento explica cómo configurar las AMIs, además de explicar los pros y contras de la solución sobre EC2:

• Coste: pagas por lo que usas.
• Puesta en marcha: muy rápida, entre 6 y 8 horas de un administrador de sistemas sin experiencia con EC2
• Licencias: Ojo, necesitas una licencia por cada ‘Worker’ del pool.
• QoS: Es una cuestión importante ya que funciona sobre internet (obvio…)
• Rendimiento: La virtualización puede afectar a la entrada y salida, pero el verdadero problema es la latencia de red y el ancho de banda entre el entorno de escritorio y La Nube.
• Seguridad: Es necesario crear una VPN entre los ‘Workers’ y el entorno de escritorio.

¿Alguien lo ha probado?

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.

En el blog oficial de Amazon Web Services nos cuentan dos cosas muy interesantes:

• Amazon S3 soporta picos de 70000 peticiones de lectura/escritura/borrado por segundo. Impresionante.
• Cambian su estructura de precios y ahora hay cuatro tramos en función de las necesidades de almacenamiento. A más necesidad de almacenamiento menor coste. Por encima de 50Terabytes los precios bajan. Por cierto, que ya lo anuncian en su página de precios.

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í.