“Trabajar en la Nube”, podcast de “En días como hoy” de RNE
Estas son las cosas que uno no puede hacerle a una madre: sales por la radio en un programa de esos de campanillas y no le dices nada. Pero lo peor es que se entere por alguna de sus amigas…
“En días como hoy” el programa de la mañana de Juan Ramón Lucas me entrevistó para su programa. El tema claro está era hablar de La Nube. Aunque la entrevista está editada y solo salgo 30 segundos al final, ya puedo presumir de mi momento de gloria en ‘prime time’.
Pinchad aquí para ir a la web de RTVE.
Tags: entrevista
Supermicro mete 96 cores y 1TB de RAM en una caja 2U
Apr 4, 2010 cloud, datacenter
Hace ya más de un año que Cisco anunció la gama de productos herederos de su Proyecto California, los UCS (Unified Computing System). El proyecto California significó el desembarco de Cisco en el mercado de los servidores, aunque en realidad lo que hizo es una plataforma completa para el Centro de Datos: servidores, redes y gestión (espera… ¿y el almacenamiento?). Una cosa que llamó la atención enseguida era que los servidores UCS se anunciaban como ‘blades’ pero venían en un formato horizontal en vez de vertical. Por cada 1U se pueden meter 2 ‘blades’ gemelos (twin) o bien un servidor 1U completo. La conexión a las ‘unified fabrics‘ se hacen en el chasis y se ahorra en costes a la vez que se obtiene una gran densidad.
Si realmente Cisco ha tenido éxito o no con esta propuesta entre sus clientes, lo desconozco, aunque se que tiene grandes proyectos en cartera con esta plataforma. Lo que sí tengo claro es que los competidores le han copiado hasta donde han podido. Así, Dell ha anunciado su nueva gama de servidores PowerEdge C (C de Cloud, claro) donde aparece este nuevo formato en el PowerEdge C6100, un chasis 2U para cuatro nodos. HP tambíen tiene su chasis 2U para cuatro nodos en su gama Proliant SL, en el modelo SL2x170z.
Pero quien se lleva la palma sin duda es Supermicro. Los californianos han anunciado su “2U Twin2 System”, un chasis 2U donde pueden meter cuatro nodos. Gracias a que cada nodo soporta dos de los nuevos AMD Opteron 6100 con 12 cores y hasta 256GB de RAM DDR3-1333, tenemos que en una caja 2U podemos llegar a tener 96 Cores y 1TB de RAM. Una bestialidad. Cada nodo puede albergar 3 discos de 3.5″ hot swap. Le acompaña una unidad de alimentación de 1400W y como opción trae en placa base una conexión QDR Infiniband de 40Gbps.
Es evidente que el Cloud Computing, la Virtualización y las Infraestructuras como Servicio están acelerando los cambios dentro del Centro de Datos, hasta el punto que empresas centradas en el hardware más estandarizado empiecen a ofrecer pequeños monstruos como estos. La información que he encontrado sobre los precios de todos estos productos es muy escasa y contradictoria. En el caso de Supermicro ya aparece en listas de precios de vendedores americanos, aunque con una disparidad de precio muy grande, sin dejar claro qué partes componen la solución.
Este tipo de plataformas son perfectas para la implantación de soluciones Cloud dentro de las empresas o los proveedores, sin duda, ya que el coste por core de una plataforma como estas baja de manera significativa. No tardaremos mucho antes de que en la división de costes de una plataforma Cloud, el software de gestión y virtualización suponga más del 30% o el 40% de la solución. Bueno, algunos proveedores ya tienen ese porcentaje y más… pero tendrán que bajarse de la ‘nube’.
Tags: hardware, infraestructura, servidores
Microsoft anuncia los planes de precios y la fecha de comercialización de Azure
Jul 14, 2009 cloud
Microsoft nos anuncia en su blog oficial las fechas y precios de Azure, sus plataformas IaaS y PaaS. Y parece que esta vez no es vapourware, ya que dean fechas y una lista de precios.
La disponibilidad comercial del servicio llegará a mediados de noviembre de 2009, coincidiendo con su Professional Developers Conference, Los desarrolladors han tenido acceso a la versión de pruebas de la plataforma desde el pasado otoño, gracias al programa Microsoft’s Community Technology Preview.
Para aquellos familiarizados con el modelo de precios y la forma de pago por uso que tiene Amazon Web Services, esto les va a sonar muy familiar:
Windows Azure:
- $0.12 por hora de uso
- $0.15 por GB almacenado
- $0.01 por cada 10K transacciones de almacenamiento (entradas/salidas)
SQL Azure:
- Web Edition: hasta 1Gb de base de datos relacional por $99 al mes
- Business Edition: hasta 10Gb de base de datos relacional por $999 al mes
.NET Services:
- Messages: $0.15 por cada 100K mensajes intercambiados en su Service bus y tokens de Control de Acceso
El ancho de banda consumido por estos tres servicios será:
- $0.10 por GB de entrada
- $0.15 por GB de salida
Curiosamente, la gente de Microsoft ha tenido la juiciosa idea de no cerrarse a este modelo de precios, y dejan la puerta abierta a otros modelos “que no generen tanta incertidumbre sobre el consumo” en los clientes.
Los precios son bastante similares a los precios que tiene Amazon Web Services. Creo que hacen bien en no entrar en una guerra de precios nada más lanzar el servicio al público general.
Google ChromeOS y el cambio de paradigma en la computación
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.
La nueva estrategia de Sun Microsystems respecto al Cloud Computing
Mar 30, 2009 abiquo, cloud, eventos, sun
Se que este post llega un poco tarde, pero las dos últimas semanas han sido un poco de locura en Abiquo. Ya se sabe, a veces la velocidad no te deja tiempo para la reflexión.
La semana en que estuve en el WebhostingDay de Colonia Sun Microsystems presentó su nueva estrategia de empresa en lo que a Cloud Computing se refiere. Y además tuve la oportunidad de conocer a dos de las personas que tienen mucho que ver con esta nueva estrategia: Tom Leyden y Kristof De Spiegeleer, Product Manager y CEO de Q-layer, la compañía de software para crear Nubes Privadas que compró Sun Microsystems hace 3 meses.
Creo que esta nueva estrategia se define perfectamente con la frase que se encuentra en su página web:
“En Sun tenemos la visión de un mundo con muchas nubes, públicas y privadas que son abiertas y compatibles. Con nuestra iniciativa de Open Cloud, planeamos ofrecer un extenso portfolio de productos y servicios, así como impulsar las comunidades y el ecosistema de partners, para hacer esta visión una realidad. Y todo empieza con la puesta en marcha de la Sun Cloud, una nube pública de computación y almacenaje, que saldrá a lo largo de este año.”
No puedo decir que no este de acuerdo en todo lo que dicen. Es más, es la visión que queremos para Abiquo. Y eso me hace muy feliz, porque creo que es el camino. Y la Sun Cloud la verdad es que suena fenomenal, al igual que la iniciativa Open Cloud… pero un momento… ¿qué es en realidad Sun Cloud y Open Cloud?
Señoras y Señores, la Sun Cloud no es el concienzudo trabajo de cientos de ingenieros de Sun a lo largo de muchos años. No. Ni siquiera es la herencia de la ya olvidada Sun Grid Engine. Para nada. La Sun Cloud es la implementación del software de Q-Layer en un inmenso datacenter en USA. Nada más. En el video de presentación de la nueva estrategia, podemos ver a Dave Douglas hablando sobre esta nueva estrategia, y luego vemos a Lew Tucker haciendo una demo de… ¡¡¡¡Q-Layer!!!! Sorprendente… Nada de Project Caroline ni de Sun Grid Engine… nada de nada.
En Abiquo siempre hemos identificado a Q-Layer como la empresa con un posicionamiento más cercano al nuestro. Cuando anunciaron su adquisición por parte de Sun, nos confirmó que desde el punto de vista de posicionamiento de producto estamos en el buen camino, pero lo que nos dejó alucinados es que Sun retirase del mercado la venta del software de Q-Layer a terceros. Es decir, se lo quedó para explotarlo como nube pública, pero no para venderlo a terceros como software de infraestructura. Eso sí que nos hizo felices 
.
Una vez constatado que la Sun Cloud no es mas que una implementación a lo bestia de Q-Layer, mis ojos se dirigieron a la iniciativa Open Cloud. Revisamos su página web… y no hay mucho que rascar… exceptuando la Sun Cloud API. Sun ha liberado una versión del API de gestión de su Nube para que cualquiera que quiera usarla lo pueda hacer desde sus aplicaciones. Ok, eso no es nuevo. Las APIs de Amazon Web Services las han copiado sin piedad otros proyectos, o incluso GoGrid ha liberado las suyas bajo Creative Commons. La diferencia fundamental con esos otros proyectos es que estas APIs definen un modelo lógico de gestión de un datacenter virtual completo. Mientras que esos otros proyectos los APIs se centran en el típico problema de levantar y detener instancias de máquinas virtuales, este API modela todos los elementos de un datacenter virtualizado: Redes, Almacenamiento, Backup, Servidores… En este caso creo que Sun Microsystems ha dado en la diana. Pero un momento… ¿no habíamos dicho que la Sun Cloud es Q-Layer con el sello de Sun? ¿Quiere esto decir que el Sun Cloud API no es mas que el API de gestión de Q-Layer liberado bajo Creative Commons? Pues me temo que es así…
Yo creo que Sun ha dado en el clavo comprando Q-Layer. Si la tecnología de Q-Layer es lo suficientemente robusta para aguantar el nivel de exigencia de la nube pública de Sun (y parece que así es), es probable que pueda darles mucho beneficio. O a IBM. Quien sabe…
Los Microsoft Azure SQL Data Services tendrán caracteristicas similares a las de bases de datos relacionales
Interesante noticia sobre la plataforma de Cloud Computing de Microsoft, Azure. Los servicios de acceso a datos en La Nube permitiran ciertas características de las bases de datos relacionales tradicionales. “Pensamos que la base de datos relacional es una tecnología familiar a mucha gente. La gente la entiende y hay gente experimentada a su alrededor. Nos están diciendo que es importante que las habilidades de los desarrolladores sean fácilmente portables a los desarrollos Cloud Computing. También nos indica el tipo de aplicación que se quiere construir en La Nube, y que son bastante más sofisticadas de lo que habíamos pensado inicialmente“, ha dicho Steven Martin, senior director of product management para la plataforma de desarrollo de Microsoft.
Mientras Amazon y Google relajan el modelo relacional hasta hacerlo inexistente, y la mayoría de los sitios web realmente grandes desaconsejan su uso, Microsoft ha detectado que las bases de datos relacionales siguen muy vivas, y está dispuesto a incorporar ‘características similares’ a las de las bases de datos relacionales a sus servicios de gestión de datos en La Nube. ¿Se referirán a integridad referencial? ¿Qué pensáis?.
Tags: almacenamiento, microsoft, paas
Ubuntu 9.10 (Karmic Koala) vendrá preparado para el Cloud Computing
Feb 23, 2009 cloud, opensource
El fundador de Ubuntu Mark Shuttleworth anunció en un correo enviado a la lista ubuntu-devel-announce que la versión que sucederá a Jaunty Jackalope, Ubuntu 9.04, ya tiene nombre (Karmic Koala). Esta nueva versión 9.10 de la popular distribución está prevista para octubre. Las novedades en las versiones desktop y server son variadas, pero en lo que a Cloud Computing atañe, hay unas cuantas novedades:
- Ubuntu se orienta en la parte servidora hacia el Cloud Computing enteramente open-source.
- Para ayudar a gestionar Nubes, Ubuntu permitirá usar las APIs de Amazon.
- Karmic Koala tendrá desde el principio imágenes preparadas para Amazon (AMIs), lista para ser usadas desde un primer momento.
- Eucalyptus, será una de las opciones para montar tus propias Nubes privadas, como alternativa a Amazon.
Intersante desde luego ya que viene confirmar que el Cloud Computing más que una moda es una tendencia que va a más. Ahora, creo nos olvidamos que Ubuntu es una distribución que depende por completo de la distribución Debian. Así que, si tienes Ubuntu ya tienes Debian. Y si Debian decide incorporar sus propios paquetes para gestionar o crear otro tipo de Nubes, pues Ubuntu también los tendrá disponibles.
Tags: linux, opensource, ubuntu
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)
Tags: amazon, berkeley, estudios, google, iaas, microsoft, paas, saas
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
Tags: amazon, berkeley, estudios, google, iaas, microsoft, paas, saas
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
Tags: amazon, berkeley, estudios, google, iaas, microsoft, paas, saas
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:
- 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).
- 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.
- Defender una franquicia: Microsoft quiere defender sus productos ofreciendo soluciones en la Nube, evitando su fuga a otros proveedores.
- 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.
- 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.
- 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
Acuerdo entre IBM y Amazon Web Services
Feb 12, 2009 amazon, cloud, negocios
IBM y Amazon Web Services acaban de anunciar un acuerdo por el cual IBM publicará en el repositorio público de imágenes (AMI) para EC2 el siguiente conjunto de aplicaciones bajo licencia de desarrollo:
- IBM DB2,
- IBM Informix,
- IBM WebSphere sMash,
- IBM Lotus Web Content Management,
- IBM WebSphere Portal Server.
Esta es la lista inicial, pero IBM tiene la intención de que crezca en próximas fechas. Todas las aplicaciones pueden usarse libremente para el desarrollo de aplicaciones.
IBM y Amazon están negociando un acuerdo para poder comprar licencias de producción directamente a Amazon para correr las aplicaciones en EC2. El modelo de pago será el de pago por uso (pay-as-you-go) que todos conocemos de Amazon.
Si ya tienes licencias de producción de estas aplicaciones y quieres migrar a EC2, existe una tabla de conversión por la que puedes averiguar cuantas instancias EC2 y de que tipo puedes levantar en La Nube de Amazon. La tabla se encuentra aquí, aunque por desgracia la página se encuentra caída (en casa del herrero…).
Parece que IBM empieza a moverse en el mercado del Cloud Computing. Por mi experiencia con ellos, una empresa tan enorme le cuesta empezar a moverse, pero una vez que coge velocidad tiene una inercia que les hace imparables. Creo que este año IBM anunciará cosas interesantes en el mundo del Cloud Computing. Esto con Amazon solo son migajas.
Arquitecturas Software para el Cloud Computing
Los viernes son un día para cerrar cosas en el trabajo. No dejar cosas abiertas ayuda a planificar las nuevas tareas que se abrirán con el próximo lunes. Además, esta semana ha sido especial porque hay cambios, cambios que anunciaré próximamente.
Llevo semanas reflexionando sobre cómo afecta a los equipos de desarrollo las nuevas plataformas de escalado dinámico que tenemos en La Nube. No debemos olvidar que una plataforma tiene éxito si es adoptada por los desarrolladores. Los ejemplos son claros en las plataformas tradicionales como J2EE, .NET o RoR. Pero en el mundo de las PaaS y las IaaS la cosa no está tan clara.
Las Platform as a Service o PaaS tipo Google AppEngine, Microsoft Azure y Sun Caroline son una raza completamente nueva de plataformas, y por lo tanto necesitan de un nuevo tipo de Arquitectura. Lo cierto es que no tengo claro cual es el modelo a seguir, seguramente porque son plataformas muy verdes todavía y su planteamiento de Arquitectura Software probablemente romperá con lo conocido en la actualidad.
Sin embargo, creo que las Infrastructure as a Service o IaaS como Amazon Web Services o GoGrid, se aprovecharán de las arquitecturas software de referencia existentes en el mundo enterprise. En HighScalability.com -un blog de referencia si estás metidos en temas de arquitectura- hay un articulo interesante en el que se describe lo que ellos llaman una Arquitectura de Referencia Canónica para el Cloud Computing. En esta arquitectura no se describe nada revolucionario, ni falta que hace. Lo que se describe es una arquitectura típica enterprise altamente desacoplada, casi abusando de los procesos asíncronos. Añaden componentes imprescindibles en un entorno que se auto ajusta (me gusta más self-healing en inglés, pero en español suena fatal), y hecho en falta decir de manera explícita que en cualquier sistema escalable el Estado es el Infierno (State is Hell) y que las soluciones sin estado son las más escalables -en La Nube o en tu casa…-.
Una lectura interesante para el fin de semana.
Tags: arquitectura
Las PYMES en USA y UK pasan del Cloud Hosting
Muy interesante esta encuesta realizada por encargo de Rackspace a Pequeñas y Medianas empresas de Estados Unidos y Reino Unido. Destaca que prácticament dos tercios de los encuestados no saben lo que es el Cloud Hosting. Como se dice en el blog de James Urquhart, no haber usado el término Cloud Computing puede haber influido en el resultado.
Una de las conclusiones más interesantes de la encuesta es que las medianas empresas están adoptando el Cloud Computing más rápidamente que las pequeñas empresas. Otras conclusiones y cifras son:
- El 14% en USA y el 11% en UK de las medianas empresas usan el Cloud Hosting, mientras que sólo el 5% lo hacen en las pequeñas empresas.
- Menos de un tercio de las pequeñas empresas ni han contemplado la posibilidad de pasarse a Cloud Hosting.
- Más de la mitad de las medianas empresas tienen planes para incorporar el Cloud Hosting en su configuración actual de Hosting, pero las pequeñas empresas casi el 60% no tiene ningún plan al respecto.
- Aproximadamente dos tercios de las pequeñas empresas encuestadas no sabían lo que era Cloud Hosting ni lo que les ofrece, mientras que la mitad de las medianas empresas sí que lo conocen.
- Las pequeñas empresas piensan que el Cloud Hosting es más caro que el Hosting tradicional.
- La mitad de las pequeñas empresas Americanas y un tercio de las Británicas no entienden los beneficios del Cloud Hosting.
Si extrapolamos estos resultados al mercado español, probablemente tengamos que pensar que estamos un par de años detras de americanos e ingleses. El mercado europeo, como es tan variado, pues es una incógnita. Pero esta encuesta nos sirve para seguir perseverando en la evangelización de las soluciones en La Nube, y prestar un poco de atención a las PYMES que es un mercado potencial enorme, especialmente para los proveedores de SaaS.
Como dice Urquhart al final del artículo:
… la encuesta de Rackspace es de un gran valor. Los clientes están ahí fuera. Salgamos a por ellos y averiguemos cómo captarlos.
Parascale, una solución de Almacenamiento en Nubes Privadas competitiva
Feb 4, 2009 almacenamiento, cloud
El mundo de almacenamiento en La Nube anda un poco acelarado ante el inminente (¿o no tan inminente?) lanzamiento por parte de Google de su GDrive. Si a esto le sumamos la agitación alrededor de las Nubes Privadas, tenemos un nuevo concepto muy interesante: Private Storage Clouds o Almacenamiento en Nubes Privadas.
La diferencia frente a los sistemas de almacenamiento empresarial tradicional en las Storage Area Networks (SAN), es el uso de hardware y software commoditiziedcommoditized que permte almacenar grandes cantidades de información con tiempos de acceso muy competitivos (y próximos al de las soluciones en red) con unos costes mucho menores.
En este artículo de Plugintothecloud.com hablan de Parascale. Parascale tiene un producto en beta que teóricamente escala infinitamente (lo han probado hasta con 100 nodos, están en pruebas…) y que se apoya en Linux, el sistema de ficheros XFS y conectividad de red tradicional (sin fibra). El coste por gigabyte es de $1.05, frente a los $2 a $5 de la soluciones SAN. Es decir, muy competitivo.
Las necesidades de almacenamiento de las empresas son cada vez mayores, y en muchos casos una solución SAN no es necesaria. Con costes por gigabyte por debajo del $1 probablemente incluso los sistemas de backup tradicional pueden cuestionarse. El problema de este tipo de soluciones es que, al igual que la mayoría de las soluciones Cloud, aún están en fases muy tempranas, y solo los más valientes pueden arriesgarse. No creo que el CIO de ninguna Fortune 500 se lance a montar una Private Storage Cloud de 50Terabytes con Parascale. Pero el CIO de una startup probablemente vaya de cabeza.
Tags: almacenamiento, gdrive, parascale
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.
El Cloud Computing necesitará 7 años para madurar según Gartner
Feb 3, 2009 cloud, estudios, paas
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…
Nuevo plan de precios para Amazon CloudFront
Amazon CloudFront, la Content Delivery Network de Amazon ha cambiado su plan de precios, y ahora hay descuentos para aquellos clientes que superen los 250Tb de transferencia de datos. Estos descuentos se dirigen a grandes clientes, evidentemente.
El antiguo plan de precios para USA era:
United States Edge Locations
Data Transfer
$0.170 per GB – first 10 TB / month data transfer out
$0.120 per GB – next 40 TB / month data transfer out
$0.100 per GB – next 100 TB / month data transfer out
$0.090 per GB – data transfer out / month over 150 TBRequests
$0.010 per 10,000 GET requests
y el nuevo plan de precios para USA es:
United States Edge Locations
Data Transfer
$0.170 per GB – first 10 TB / month data transfer out
$0.120 per GB – next 40 TB / month data transfer out
$0.100 per GB – next 100 TB / month data transfer out
$0.090 per GB – next 100 TB / month data transfer out
$0.080 per GB – next 250 TB / month data transfer out
$0.070 per GB – next 250 TB / month data transfer out
$0.060 per GB – next 250 TB / month data transfer out
$0.050 per GB – data transfer out / month over 1,000 TBRequests
$0.010 per 10,000 GET requests
El esquema de precios es similar para el resto de los lugares donde Amazon tiene servidores edge.
Tags: amazon, cloudfront
Los riesgos del escalado automático: EDoS (Economic Denial of Sustainability)
Hace unos meses leí un artículo (que no he podido encontrar) sobre un pobre tipo que había montado una startup y utilizaba Amazon S3 para servir contenido estático. Todo le iba de maravilla hasta que un mes le llegó una factura absolutamente descomunal por el servicio. Tan grande era que tuvo que cerrar el sitio. Investigando qué había pasado, descubrió que alguien se había dedicado a hacer peticiones a sus ficheros alojados en S3 de manera continuada y masiva, sin hacer uso real de su servicio. El resultado fue que Amazon sirvió el contenido solicitado, aunque esas peticiones fueran falsas y maliciosas.
Exactamente esto es un ataque de tipo EDoS (Economic Denial of Sustainibility). En un ataque tipo DDoS (Distributed Denial of Service), un tio con muy mala leche ataca una aplicación o una web cualquiera con la intención de colapsarla, lanzando peticiones desde múltiples computadoras de manera concurrente y masiva. Al final, el servicio cae ya que no es capaz de copar todas las peticiones solicitadas. El EDoS es una manera más sutil de tirar el servicio abajo. Su objetivo no es la caida física de los servidores que soportan el servicio, sino la rendición de los propietarios del servicio al no poder hacer frente las facturas de uso de los recursos en La Nube.
El ataque DDoS asume que un servicio puede escalar hasta un límite fijo. Este límite lo marca la cantidad de hardware instalado y la capacidad del software para aprovecharlo. En cambio, en el Cloud Computing este límite es variable si el software es capaz de aprovecharlo de manera dinámica. Es el tan famoso escalado dinámico. Un Controlador/Agente implementa un conjunto de políticas que permite solicitar a La Nube más recursos en caso de ser necesarios, o de liberarlos si ya no lo son. En teoría (y en la práctica también) esto permite optimizar el gasto en infraestructura. El ataque EDoS aprovecha la facilidad para escalar de manera dinámica para pedir de manera alocada más y más recursos a La Nube. El servicio sigue funcionando sin que nadie se de cuenta de lo que pasa, pero la factura por el uso de recursos sube y sube hasta que se hace evidente y es cuando se toman medidas, ya tarde.
En una arquitectura Cloud es necesario este Controlador o Agente que gestione el escalado dinámico, pero no hay que olvidarse de políticas que limiten el uso de recursos para evitar abusos de este tipo. Es decir, no solo indicar cuando debe escalar con más o menos recursos, sino limitar el gasto máximo de los recursos para evitar desagradables sorpresas. Es decir, no delegar todo en el escalado dinámico, sino realizar una Planificación de la Capacidad (Capacity Planning) en la que introduzcamos como variables el límite de consumo en La Nube.
Hazte un secuestrador y monta en Amazon EC2 un cliente bittorrent con tus amigos
Jan 26, 2009 cloud
Cual Inspector Clouseau, llega un tio y suelta esto en ComputerWorld.com en plan profeta del Apocalipsis: “Amazon cloud could be hijacked to harvest BitTorrent files, researcher says” (La Nube de Amazon podría ser secuestrada para cultivar ficheros BitTorrent, dice un investigador). Tras leer esto todas mis alertas se encendieron y puse la máxima atención ya que si efectivamente ‘alguien’ puede ‘secuestrar’ La Nube de Amazon, eso es muy serio. Pero no se preocupen, mis queridos lectores, que aquí nadie secuestra, ni cultiva, ni nada… Aquí lo que hay es una falta de rigor que asusta.
Empecemos por el principio: hace unos días apareció este post en un blog en el que se detalla cómo instalar Torrentflux en una instancia Amazon EC2. En este pequeño tutorial se nos explica cómo instalar la AMI adecuada para poder ejecutarla, y cómo instalar Torrentflux. Para el que no lo sepa, Torrentflux no es mas que una interfaz web escrita en PHP y MySQL que permite gestionar las descargas bittorrent en un servidor. Tiene alguna funcionalidad chula, como poder administrar múltiples cuentas de usuario (más luego). El blogger nos dice que por unos $75 al mes podemos tener acceso a un cliente bittorrent con velocidades de subida y bajada de órdago. Sin embargo, se olvida decir que en EC2 se paga por ancho de banda consumido, por lo que si abusas del ancho de banda tendrás una bonita factura cada mes. También apunta que tienes 120Gb de espacio disponible en el servidor, pero este espacio se borra cada vez que reinicias la instancia. Así que como almacenamiento persistente de descargas, es una mala idea. Por último, Amazon prohibe expresamente el uso de sus instancias para la compartición de archivos no autorizados.
Así que de una amenaza a la seguridad de Amazon EC2 hemos pasado a un tutorial explicando cómo montar torrentflux en un Linux. Cosa que puedes hacer en cualquier empresa de hosting del mundo, y probablemente más barato que en EC2. Por el camino, una empresa de seguridad se monta una película y una publicación seria se lo traga todo. Impresionante.
Hay una cosa cierta en todo esto: pagar $75 (mínimo) al mes por tener un cliente bittorrent funcionando es una gilipollez. Lo siento, pero pagar casi $1000 al año por descargarte contenido que luego tienes que bajarte a tu entorno local me parece un sinsentido. Puede que haya ISPs que reduzcan el ancho de banda para clientes P2P, pero lo mismo podría hacer Amazon.
Hay una cosa que no comenta el artículo que es interesante: la posibilidad de crear cuentas de usuario en Torrentflux y que cada uno pueda descargar los contenidos que quiera sin interferir en los demas. Se puede configurar el número de descargas máxima por usuario, profundidad de la cola, ancho de banda de subida y de bajada… Así que si tienes un grupo de amigos que quiera compartir gastos, igual lo de los $1000 no es para tanto. Y digo lo de grupo de amigos ya que en el momento en que alguien se lucre compartiendo contenido protegido por copyright estará cometiendo un delito.
Así que no veo razón para montar Torrentflux en La Nube… ¿o si?
Tags: amazon, bittorrent, cloud, ec2
