El colapso de la nube ( Lo peor ya paso? o Lo peor esta por venir?)

Hace poco se colapso un aparte de la nube de Amazon. Algo que se suponia no podia pasar... o al menos era muy improbable que pasara... como resultado un numero importante de clientes se quedaron sin servicio servicio durante 4 dias (21 al 24 de Abril).

Este fallo me hizo recordar algunas de las cosas que lei en el libro del Cisne Negro de Nicholas Taleb. Este libro trata basicamente, sobre los limites que como humanos podemos alcanzar a la hora de querer reducir al comportamiento de la realidad a modelos abstractos... basicamente nos recuerda que hay cierto tipo de problemas (como el comportamiento de la Economia) para el que existe un limite mas alla del cual, por preciso que creamos que es el modelo, fallara... y nos recuerda que al confiar en un modelo no solo debemos preguntarnos que tan probable es que falle, si no que tan grave seria el impacto de la falla.

Taleb menciona que:

Globalization creates interlocking fragility, while reducing volatility and giving the appearance of stability. In other words it creates devastating Black Swans. We have never lived before under the threat of a global collapse. Financial Institutions have been merging into a smaller number of very large banks. Almost all banks are interrelated. So the financial ecology is swelling into gigantic, incestuous, bureaucratic banks – when one fails, they all fall. The increased concentration among banks seems to have the effect of making financial crisis less likely, but when they happen they are more global in scale and hit us very hard. We have moved from a diversified ecology of small banks, with varied lending policies, to a more homogeneous framework of firms that all resemble one another. True, we now have fewer failures, but when they occur .... I shiver at the thought. The government-sponsored institution Fannie Mae, when I look at its risks, seems to be sitting on a barrel of dynamite, vulnerable to the slightest hiccup. But not to worry: their large staff of scientists deem these events "unlikely".

En resumen, la globalizacion crea una fragilidad interconectada, que aunque por un lado reduce el numero de fallas, por otro lado abre la puerta a fallas catastroficas. En el caso economico, nos advierte de que las fuertes interrelaciones entre los grandes bancos modernos hace facil que al caer uno caigan los demas... antes, cuando estaban menos interconectados quiza habia mas caidas (con impactos negativos localizados)... pero ahora las pocas que caidas que hay (o que llegue a haber) aunque son (o seran) mucho menos frecuentes (o improbables en las palabras de algunos expertos) podrian tener un efecto cataclismico.

Y eso me hace preguntarme... sera "La Nube" un sistema que puede caer en esto? Digo, por supuesto que el Datacenter de Amazon o de Google es mucho mas grande, poderoso y mejor administrado que el de una PyMe o inclusive que otras grandes (aunque quiza no tan grandes como Google o Amazon) empresas... y seguro que tiene mucho menos "downtime" pero... cuando gran parte de las empresas en diversos paises esten en "La Nube" y esta se colapse, llevandose consigo la capacidad operativa de cientos (o quizá miles) de empresas.... sera entonces y solo entonces que nos daremos cuenta de tener todo en "La Nube" no es tan buena idea? o sera que comparar al modelo de operacion de "La Nube" vs "La Economia" es simplemente un error y nunca veremos una megacatastrofe....

Ustedes que opinan? Lo peor ya paso? o Lo peor esta por venir?

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Aplicaciones

La nube tiene sus aplicaciones. Si yo tuviera una aplicación de red social o algo así no transaccional y que genere y guarde datos que no son de vida o muerte para nadie, que tal vez me represente un complemento a mi ingreso mensual, la pondría en la nube.

No pondría en la nube una aplicación que maneje dinero real y que los datos que guarda son esenciales para mi empresa o para mis clientes. (había empezado este párrafo con Jamás pero lo cambié a No porque tal vez algún día la nube sea más robusta y ya me animaría a hacer algo así. Pero por ahora no). Ese tipo de aplicaciones prefiero tenerlas en un datacenter al cual tenga yo acceso físico, en servidores que yo controlo por completo. Es mucho más latoso, porque entonces yo tengo que hacerme bolas con la configuración y mantenimiento de cada equipo, con los respaldos, etc. Pero una vez que tengo todo eso, me siento más tranquilo. Si el datacenter se queda sin internet, etc ya veremos después qué onda con las penalizaciones porque no cumplieron con el servicio que me prometieron en el contrato. Y si les cae un meteorito encima o se los traga la tierra y me quedo sin aplicación, pues... si no tengo respaldos offsite, es mi culpa. Y ya veré qué hago. Tengo que contemplar la probabilidad de que al datacenter se lo trague la tierra, pero pues de momento dejémoslo como dices, en unlikely (y luego si añades que vivimos en el país de no-pasa-nada...)

Lo que creo que pasa es que ahorita la nube está en la mente de todos, es la moda, todo mundo quiere estar en la nube, aunque no sepan ni qué es. Y entonces mucha gente está subiendo a la nube aplicaciones que no deberían poner ahí. Y además, las configuran mal. De lo poco que he leído al respecto del desastre de Amazon, es que se cayó un fragmento de la nube en una región geográfica pero sus demás regiones funcionaban bien. Los que tenían su aplicación en la nube, distribuida de modo que hubiera redundancia en distintas zonas geográficas, no tuvieron bronca. Pero los que tenían su aplicación con una configuración muy simple, para que solamente corriera casi casi igual que una aplicación local normalita tradicional en un equipo, pero pues donde fuera (o sea, la versión más simplista de poner algo en la nube), si su aplicación estaba en el fragmento que se murió, pues su aplicación quedó inaccesible.

Las reacciones que seguramente veremos:

  • Algunos se quedarán con una mala impresión de la nube y regresarán a la manera "antigua" de hacer las cosas, poniendo servidores en un datacenter y manejándolos ellos mismos
  • Otros aprenderán la lección de la configuración simplista y la cambiarán para hacerla más robusta y tener redundancia y entender que para evitar SPOF en la nube hay que hacer algo al respecto, no es automágico.
  • Otros se encogerán de hombros y seguirán como estaban antes del crash. Tal vez estiren la mano con Amazon a ver si les reembolsan algo o les dan una playera que diga "subí mi app a la nube y estuvo 4 días offline"

Por su parte, tal vez Amazon modifique las cosas para facilitar que todo mundo pueda configurar su app para tener redundancia en distintas áreas geográficas. Si no lo hacen ellos, otro proveedor de nube lo hará y será un muy buen argumento de venta.

Creo que con el tiempo, los proveedores de nube se irán estabilizando y robusteciendo, y este tipo de broncas serán menos frecuentes. También importa mucho la respuesta de Amazon y lo que haga para reparar el daño.

Es como lo de Sony; cualquier servicio de ese tamaño es vulnerable a ataques. Lo más grave fue la respuesta (o no respuesta, más bien) de Sony.

Por eso se debe de tener un

Por eso se debe de tener un plan de contingencia. Hay que respaldar los datos constantemente, tener un servidor que pueda levantarse aunque sea hospedado con un proveedor muy básico.

Los fallos suenan más ( no es lo mismo que se le caiga el servidor a hazmitarea.com que a Amazon ) pero no necesariamente son más graves o más frecuentes. Serán tan graves como malo sea el plan de contingencia y en principio menos frecuentes.

Usarlos o no ya no es opción, ya están aquí y hay que aprender a usarlos. Es como con los mercados internacionales, cuando uno se cae arrastra el resto, pero los beneficios son mayores que los daños ( de otra manera todos los países seguirían con una economía centralizada ) . Algo similar pasa con las aplicaciones en la nube, es probable que se caigan y que causen daño, pero en términos generales los beneficios son mayores.

Existe también una variación importante entre el tamaño de la aplicación, por ejemplo http://noticiashacker.com tiene gratis hospedaje en GAE, pero el número de usuarios que tiene es muy reducido. Por otro lado tener facebook ( o twitter ) en la nube sería un suicidio ( por poco importante que pareciera su información ).

El modelo debe de seguir madurando y habrá que analizar exactamente para que tipo de cosas sirve y para cuales no. Por ejemplo, stackoverflow en su lanzamiento pudo optar por poner su app en la nube pero decidieron que si han de tener el control de las cosas mejor sería controlarlo TODO ( software, hardware, hosting incluso han escrito sus propias bibliotecas para varias cosas )

Quizá el criterio a aplicar es el que menciona Joel en su blog In defense of not invented here syndrome "Si es una función básica del negocio, hazla tú mismo, sin importar otra cosa"

Mucha gente dice que "vamos de vuelta"

Comentando de éste tema en una clase de la universidad, un profe nos decía que básicamente regresabamos a los tiempo de UNIX en dónde todo tiene acceso remoto y demás, anque claro, con las ventajas de la tecnología actual.

Luego con las bases de datos NoSQL ya he escuchado a más de uno (entre ellos a @luxspes) que es regresar "técnicamente" a los tiempos Cobólicos y que incluso algunas implementaciones son más rudimentarias que el mismo Cobol.

Otra gente que dice: "MVC no es algo innovador, viene desde los 70's u 80's".

Mi pregunta respecto al tema (con un pie dentro y otro fuera) es: ¿Es cierto qué nos estamos regresando o se nos han olvidado cosas del pasado que necesitaban unos pocos cambios para resolver los problemas que se atacan hoy (de esto último me viene a la cabeza REL, el cual busca hacer es enderezar el modelo relacional que traemos de los 70's y que nos hemos querido deshacer de él con la OOP)?

Imagen de ezamudio

adaptación

No es que regresemos a lo anterior, o que lo anterior siempre esté mal. En el pasado salieron cosas buenas (como MVC) y cosas no tan buenas (como bobol). De ahí han ido saliendo cosas mejores. Las cosas que son buenas y sirven, para qué dejarlas? Sí me da algo de risa y a la vez tristeza que en sistemas la historia sea tan mal documentada y tan poco importante para la mayoría; mucha gente piensa que MVC es algo que salió para la web, cuando realmente es algo que se había hecho ya tiempo atrás y se adaptó para web apps. Han salido arquitecturas y diseños nuevos, y se han adaptado diseños y patrones viejos que sirven todavía.

Otro ejemplo es la programación funcional...

Pero regresando al tema, pues sí, habrá cada vez menos caídas, esperemos que no sean más catastróficas. En contraste a lo que dice Oscar de los mercados internacionales, considero muy ingenuo pensar que todos los países le entraron a eso porque "es bueno" y que todo mundo tuvo la opción de no entrarle y seguir bien. Siguiendo con la analogía, ahora hay menos devaluaciones, pero qué es peor? que el peso se devalúe unos pocos centavos cada dos o tres meses, o que parezca estable durante unos años y de repente haya una devaluación y vemos cómo el dólar se va al doble de precio?

En sistemas, qué será peor? que seguido haya fallas menores no catastróficas, o que todo parezca siempre funcionar a la perfección, hasta que un día de repente muchísimos sitios se quedan fuera del aire por una semana?

Interesante lectura

"Find the dependencies -- and eliminate them." When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.

(Fragmento del texo "In Defense of Not-Invented-Here Syndrome" de "Joel Spolsky" que menciona @oscarryz)

Eso va en contra de la nube.

Por un lado noto que varios estan en pro de "no reinventar el hilo negro" y dicen, vamos a usar lo que ya esta hecho pero hay quienes dicen "NO" porque yo quiero esa funcionalidad pero a mi manera y sucede algo que muchos dicen "para que lo haces si existe esto, o el otro... vease: esta entrada donde se me sugirio utilizar algo que ya existia pero no era como yo lo queria... el asunto es "la nube es usar lo que otros te pueden dar" y puede resultar valido si lo que recibes es realmente lo que buscabas.... Ok, ya cubrimos un punto de "las necesidades"...

ahora que decir de lo robusto y seguro que puede ser la nube?... Todos tenemos por naturaleza un grado de escepticismo a todo lo nuevo y en cuestiones tecnologicas es totalmente valido porque en este mundo todo jala mas por buena/mala experiencia que por excelentes conceptos. Esto se me hace que fue un boom que hicieron los WS donde "woow, puedes hacer que mi aplicacion hable con la tuya" y entonces empezaron a pensar en servicios y "servicio aqui, servicio allá.. hasta llegar a aplicaciones basadas totalmente en servicios y algunas sin una buena (o mala ya de perdida) arquitectura SOA: sino hacian puro web service y para mi no era la mejor practica... A que voy con esto? que la fiebre de la nube puede que se repita en la fiebre del WS donde no importa lo que necesites y a veces tampoco importa si lo haces tecnica/tecnologicamente bien pues : "basta con esar en la nube"

Imagen de ezamudio

ni empieces con los WS

Ni me menciones los méndigos web services porque me pongo de malas.

ChromeBook es una computadora en la nube.

Por cieeeeerto, Google anunció hoy que las ChromeBooks empezarán su comercialización el 15 de junio ( para nosotros quién sabe, échenle un año más ) y básicamente es una computadora que tiene como interfaz gráfica un navegador Chrome y todos los datos se almacenan en la nube.

:) :)

Así que lo que está haciendo Google ( que ya lo lo lleva haciendo desde que inició ) es aportarle a la nube a tal grado que si el GMail o gdocs se cae, todos sus usuarios se quedaran off line ( al menos en estos servicios )

De nuevo, depende de que tipo de cosas se pongan ahí. Lo cierto es que si Google se queda fuera de linea 4 días si estaría bastante feo.

Ahi va el link del anuncio:

http://googlecode.blogspot.com/2011/05/new-kind-of-computer-chromebook.html

Por cierto, no dice el costo, pero los planes para negocios y los de educación están en 28 USD y 20 USD al mes. Por lo que una chromebook por 3 años saldría en $12,000 aprox ( más lo que se devalue el peso en ese tiempo )

Sobre los WS, comparando los WS de Google con los de Amazon los de Google son muchísimo mejores y más fáciles de usar.

Imagen de ezamudio

crédito

Por cierto java.daba.doo se te olvidó dar el merecido crédito a Joel Spolsky por esa citota que pusiste, de su artículo donde defiende al síndrome NIH.

Imagen de bferro

Un poco más de optimismo con las soluciones nubladas

Creo que los aportes a esta discusión son un poco pesimistas sobre cloud computing en la actualidad, y lo que nos espera en el futuro inmediato.
En el número de marzo de este año, la revista Computer de IEEE Computer Society aparecen varios artículos dedicados a la computación en nube.
Uno de esos artículos presenta los resultados de una encuesta realizada a compañías que han adoptado ese paradigma para hacer deploy de sus sistemas críticos. Se consultaron 155 compañías de más de 500 empleados, con el 65% de ellas con más de 1000 empleados.
Conviene si tienen acceso a esta revista que le echen un vistazo a ese y a los otros artículos. Copio a continuación algunas conclusiones importantes.

  • Más del 60% de los encuestados afirmaron que las soluciones con cloud computing son mejores en términos de disponibilidad, TCO (total cost of ownership) y TTV (time to value)
  • 28% de los encuestados dijeron que el problema de la seguridad es el concepto equivocado (misconception) número uno de las soluciones en la nube.
  • 68% de los encuestados afirmaron que tendrán la mayoría de sus aplicaciones y plataformas en la nube pública en los siguientes tres años de manera paulatina.

Son datos duros que dicen que aunque a veces llueve y hay negros nubarrones, la nube es blanca y brilla.
En los años 80 muchos consideraban que "OOP sucks". Eppur si muove.

Suena a tema de película...

En mi opinión, el título de esta entrada me suena un poco sensacionalista, pero no lo hace menos interesante; efecto que me logró convencer de comentar al respecto :)

Enrique ya mencionó sobre el el tema con el enfoque con el que personalmente yo lo tomaría, y ya @bferro compartió algunas métricas sobre adopción de tecnologías de computo en la nube, pero aquí les va el sermón de nuevo. Como actual empleado de Amazon, pero tomando en cuenta principios básicos de diseño de aplicaciones de misión crítica y a gran escala, comenzaré mi punto de vista con lo que podría ser mi conclusión: el enfoque que se le ha dado dicho problema se salió de proporciones por medios de comunicación (que raro, no?) al no comprender el concepto básico de redundancia en aplicaciones, que apuesto que más de alguno de ustedes ya ha leído en algún foro de discusión sobre el tema (infoQ, como buen ejemplo) y que muchos han logrado explicar desde el punto de vista técnico y sobre todo práctico. Sin embargo, los medios se enfocaron mucho más a comunicar un factor que la mayoría en la industria debería conocer (y que dichas empresas ignoraron): Ninguna tecnología (y vaya que no me atrevo a considerar al computo en la nube como una tecnología sino como una técnica o una arquitectura) emergente es el remedio a todos tus problemas, ni tampoco funcionan de manera mágica.

Citando a la Ley de Murphy: "Si algo puede fallar, fallará", que para nada exime a Centros de Datos. Obviamente cuando esto sucede, los daños en cuestiones monetarias pueden ser catastróficos; razón por la cual muchas empresas --principalmente aquellas con fondos-- inviertan en consultores que les ayuden a hacer análisis de planes de contingencia contra catástrofes e incluso siniestros naturales, gastos que obviamente no toda empresa puede absorber o lo ve como prioridad inicial. Tampoco quiero decir que toda empresa tenga que hacerlo así, hay definitivamente medidas técnicas y tecnológicas que puedes tomar para evitar bajas como estas y tomar planes de contingencia a menor costo.

En este caso no todo un centro de datos falló, sino parte de él, causando errores graves en unidades EBS a causa de algunos servicios corriendo para RDS.

Por otro lado, recuerdan qué empresas fueron mayormente afectadas por dicho fallo? Así es... el 90% (sino es que el 100%) de ellas startups. Clientes que por la razón que ustedes quieran imaginarse, sin hacerlos menos importantes para Amazon, no tenían (o tienen) instancias de sus aplicaciones corriendo en diferentes zonas geográficas y que como ya mencionaron arriba, quisieron aventarse a beber el kool-aid del cómputo en la nube. Que por cierto, son servicios que obviamente Amazon facilita y que pueden ser adaptados también para hacer réplicas de unidades EBS, auto-despliegue de imágenes AMI, entre otras muchas monerías y servicios de monitoreo, que no vengo a venderles en esta ocasión :) Empresas como Netflix y Zynga (que fueron algunas que hicieron público su status) no sufrieron pérdias o fueron afectadas a muy menor grado.

Moraleja de la historia? Si no quieres estar como mi cuate de http://awe.sm (cuya compañía se encarga de proveer métricas de propagación y uso de URLs ala bit.ly, con 4 empleados) que por 4 días estuvo intentando levantar la base de datos en MySQL que tenían en unidades EBS, con respaldos de hace un mes, y con 0 réplicas: entonces invierte un poco de tiempo y dinero en algunas soluciones redundantes, algunas herramientas de monitoreo y recuperación de instancias; pero sobre todo, aprende de lo sucedido.

Qué pasará con Amazon? Claro que hubo un profundo análisis de los hechos y se realizaron muchos cambios al respecto. Amazon es una empresa 100% enfocada a sus clientes, y creanlo cuando digo que le importa lo que dicen todos y cada uno de ellos. Pero como dicen: "lo que no te mata te hace mas fuerte", y Amazon, en especial los equipos de AWS, definitivamente intentará encontrar soluciones mas viables en cuanto a tolerancia a fallos. Garantias? Basta decir que Amazon es, y sigue siendo el pionero en IaaS, cuyos servicios son utilizados incluso por otras empresas que compiten en el mismo sector.

Por obvias razones tengo que omitir muchos detalles tanto técnicos como de propaganda, pero creo que también ya me excedí en la longitud del comentario :) En otra ocasión se podrá discutir sobre sistemas de misión crítica en la nube (ugh).

Imagen de bferro

@amnesiac: Buen post contra el excepticismo

Todo se puede "caer", sea una lap,una desktop, un server, un data center y por supuesto algo de la infraestructura en la nube.
Pero de que la nube va a "nublar" a muchas otras soluciones es un fact, que quien no lo acepte como una "posible" solución exitosa para muchos problemas está rotundamente equivocado. Que la nube va a evolucionar y mañana será otra cosa también es verdad, y que Amazon (no trabajo en Amazon ni Jeff Bezos me regala nada) es un empresa excelente en cloud computing y casi todo en lo que se ha aventado también es un fact. No es la única pero compite como gigante con los otros gigantes.

Imagen de luxspes

No es lo mismo mediocristan que extremistan

Todo se puede "caer", sea una lap,una desktop, un server, un data center y por supuesto algo de la infraestructura en la nube.

Una caida de 4 horas tiene un impacto muy diferente en (mediocristan) una lap,una desktop, un server, (extremistan) un data center o en la infraestructura en la nube:

Si se cae mi laptop, me amuelo yo... si se cae mi desktop, tambien solo yo... si se cae el server, se amuela mi equipo de trabajo, o tal vez la PyME en la que quiza trabajo, si se cae el datacenter, se amuela la gran empresa quiza para que trabajo... y todos sus clientes... y si se cae la nube, me amuelo yo, mi equipo, las pymes, las grandes empresas y tal ves hasta algun gobierno (o gobiernos) que haya decidido poner ahi sus sistemas...

Al final, con todo su poder de redundancia distribuida, no puedo evitar pensar que la nube es una especie de centralizacion... Supongo que me sentire mas tranquilo el dia que pueda mover un sistema entre las nube de Google a la de Amazon y la de Microsoft a mi antojo y "con un par de clics" (y hasta tenerlo corriendo en redundancia contra 3 proveedores de servicios independientes si ese es mi deseo.... )

Pero de que la nube va a "nublar" a muchas otras soluciones es un fact, que quien no lo acepte como una "posible" solución exitosa para muchos problemas está rotundamente equivocado.

Totalmente de acuerdo, decir que la nube es mala para todo, es tan equivocado como decir que es buena para todo.

Imagen de bferro

@luxspes: De acuerdo

Al final, con todo su poder de redundancia distribuida, no puedo evitar pensar que la nube es una especie de centralizacion
¿Aplica lo anterior si cambio la palabra nube por Internet?

si se cae el datacenter, se amuela la gran empresa quiza para que trabajo... y todos sus clientes.

Y también otras grandes empresas y otros gobiernos que decidieron rentar centros de datos que le dan servicios a varios en lugar de invertir la lana del mundo en eso

Es un riesgo y por supuesto que las consecuencias son mayores, pues los afectados son más. Es también un gran riesgo para la privacidad. Lo que sí es cierto que muchos y muchos billetes se la están jugando. Y también es cierto que los avances en la tecnología disminuyen paulatinamente esos riesgos.

Para aquellos que se interesen y sean miembros de ACM, pueden encontrar ahí el TechPack "Cloud Computing". De paso y quizá algunos se animan a inscribirse a ACM, que para nosotros en México es barato y la relación Beneficios/costo es inmensa.

Imagen de luxspes

Nube < Internet, Ejemplo: Facebook < Diaspora.

¿Aplica lo anterior si cambio la palabra nube por Internet?

No lo se... ciertamente hasta cierto punto suena a lo mismo... quiza lo que me hace pensar que Nube < Internet, es la diferencia entre Facebook y Diaspora... o entre Subversion y Mercurial. Con todo y que ahora Facebook he hecho publica su arquitectura de todas maneras yo no puedo extenderla de manera directa (al igual que no puedo hacerlo con otros proveedores de Nube... hasta donde se no puedo facilmente poner minidatacenter en el DF y otro en Monterrey y usar Amazon como un "puente" que los mantenga en syncronia de manera que de caerse cualquiera de los tres (mi minidatacenter en el DF, mi minidatacenter en Monterrey o Amazon los otros 2 sigan operando y sincronizandose y si compro un tercero, integrarlo de forma transparente)

No se si me explico... va otro intento:

Comparemos la arquitectura de FaceBook con la de Diaspora... e imaginemos un posible futuro competidor de Amazon que tuviera una arquitectura tan abierta como la de Diaspora, en la que proveedores de servicios independientes pudieran compartir informacion y yo pudiera ofrecer asi como los los equipos "clon" alguna ves dijeron "100% IBM compatible", una leyenda en mi nubecita "100% Amazon / Azure / Google Apps compatible"... o pensemos en la diferencia entre Mercurial y Subversion (con Bitbucket puedo tener todo mi codigo fuente en la nube a traves de Mercurial... y si NO tengo acceso a la nube,pues igual tengo acceso a toda la historia de mi codigo fuente)

O pensemos en las nuevas Chrome OS computers... un de los principios sustentadores de las mismas es "Google will always be there"... (supongo que Ashton Tate creia en lo mismo en el pinaculo de su exito). Se imaginan la bronca si todas las bases de datos dBase hubieran dejado de responder el dia que Ashton Tate quebro? Igualmente, si el software para administrar un conjunto de Chrome Os computers desde la perspectiva del server fuera algo que yo pudiera instalar en mi empresa, entonce me sentiria mas tranquilo, sabiendo que aun si Google tiene problemas, yo puedo continuar.

Supongo que me sentire mas tranquilo cuando la integracion entre la red local y la nube sea asi... donde yo pueda mover mis sistemas y datos "fuera y dentro" de la nube, y de un proveedor a otro facilmente...

Para aquellos que se interesen y sean miembros de ACM, pueden encontrar ahí el TechPack "Cloud Computing". De paso y quizá algunos se animan a inscribirse a ACM, que para nosotros en México es barato y la relación Beneficios/costo es inmensa.

Muy, muy, pero muy Interesante idea...

Imagen de bferro

@luxspes: Buena comparación

Yo también me sentiría más tranquilo si ese movimiento "pa dentro y pa fuera" de la nube se materializa. Saber si eso va a suceder está por ver. Son muchos los interese$ que están por medio y los dueños de las nubes no son angelitos, ni "están en las nubes".
Sería bueno un open talk tan open para dedicar un par de horas a varias de las cosas interesantes que se discuten en este foro.

Imagen de ezamudio

centralización

Creo que entonces lo que luxspes dice que le preocupa, no es centralización, es vendor lock-in. Ese por ahora es prácticamente inevitable; Amazon y Google, por poner dos ejemplos, son incompatibles; si tienes una app que quieres poner en ambas nubes, tienes que hacerle cosas distintas o hacerla de dos maneras distintas (algunos módulos) o de plano hacerla dos veces.

Imagen de luxspes

Digamos que me preocupan ambos

Creo que entonces lo que luxspes dice que le preocupa, no es centralización, es vendor lock-in.

Digamos que me preocupan ambos ;-) (y que vendor lock-in es una forma de centralizacion... en 1 solo vendor)

Ese por ahora es prácticamente inevitable; Amazon y Google, por poner dos ejemplos, son incompatibles; si tienes una app que quieres poner en ambas nubes, tienes que hacerle cosas distintas o hacerla de dos maneras distintas (algunos módulos) o de plano hacerla dos veces

Pero no solo eso, si no que aparte, (hasta donde se) ni siquiera puedo tener una "nube privada" que sea como un "mini-amazon" o "mini-google" en mi Datacenter, que de forma "transparente" distribuya la carga con el vendor que me tenga "lock-ineado",

Imagen de ezamudio

nube privada?

Como para qué quieres tener una nube privada? La oferta de la nube es darte poder de cómputo tan vasto como lo necesites (y puedas pagar), para lo cual necesitas hacer algunas configuraciones o modificaciones relativamente sencillas a tu aplicación. La infraestructura ya la tiene el proveedor de la nube y la idea es que ya no te tienes que preocupar por esos detalles.

Si quieres comprar 20 servidores y ponerlos en un datacenter y configurarlos como una "nubecita" que funcione de manera similar pues hay soluciones también para eso, no tan fáciles pero existen; puedes usar Hadoop, Cassandra, Terracotta, Beowulf, etc etc etc. Obvio tú la tienes que armar; no creo que ningún proveedor de nube le vea ventaja alguna a venderte una solución para armar tu propia nubecita, por la sencilla razón de que va en contra de su modelo de negocio.

Y por otro lado... si vendieran algo así, no sería vaporware? **bazzinga**

Woops, díficil de seguir cada argumento...

A estas alturas es difícil de seguir todos y cada uno de los argumentos, pero creo que tengo una idea de lo que habla cada uno de ustedes, aunque ya nos metimos en muy diferentes temas.

Nuevamente, el referirnos a que "se cayó" la "nube" es un poco sensacionalista, hubo fallas en una porción de un centro de datos (ni siquiera un centro de datos) y obviamente afectó solo a unas cuantas empresas. El argumento de @luxpes es acertado, ¿qué tal si una de esas empresas es la mía? Definitivamente se tiene que mejorar el desempeño de salvaguardar la integridad de los datos de una empresa por pequeña que sea, y Amazon definitivamente tiene tarea que hacer.

Interoperabilidad entre nubes? Vaya que no es una tarea sencilla, pero a qué nivel quieres dicha actividad? A estas alturas hablar de interoperabilidad a nivel infraestructura o plataforma son cosas muy distintas. Ya que incluso a nivel sistema operativo la hay. Por otro lado, hay empresas como dotCloud que están intentando cambiar esa perspectiva al ofrecer ciertas plataformas, frameworks y servicios correr de manera transparente entre diversos servicios de infraestructura o incluso plataforma en la nube. Nuevamente, son conceptos no muy maduros pero que se están convirtiendo en realidad por medio de terceros. Por cierto, yo no lo llamaría centralización, ni llamaría centralizado a un vendor lock-in. Jamás se te ha prometido tener un proveedor distribuido :) Lo que se te prometió en las políticas de servicio es el proveerte de infraestructura o plataformas distribuidas, cuyos detalles a estas alturas supondré que los conoces. Que tan distribuida quieres tu solución depende de tí y de las necesidades de tu arquitectura a implementar.

Nubes Privadas? Son un hecho desde hace ya (un buen) varios años. Mucho más comunes entre empresas grandes que requieren de estrecha extensibilidad y interoperabilidad entre su proveedor de infraestructura/plataforma en la nube y su red privada (virtual). Amazon obviamente es uno de los que ha utilizado su propia infraestructura para generar VPCs (Virtual Private Clouds internamente y tener, por ejemplo, instancias EC2 publicas y privadas dependiendo del tipo y servicio que otorgue cierto equipo de trabajo. No dudo que Microsoft y VMWare, como proveedores de infraestrcutura, no tengan dicha solución también. Quienes serán los clientes de dicho concepto? Cualquier empresa con servicios y datos privados. Creeme que nada se pierde del concepto de "nube" incluso en redes privadas, los mismos servicios, y los mismos usos que le das de manera publica aplican.

Imagen de luxspes

mercado de vapor

Si quieres comprar 20 servidores y ponerlos en un datacenter y configurarlos como una "nubecita" que funcione de manera similar pues hay soluciones
también para eso, no tan fáciles pero existen; puedes usar Hadoop, Cassandra, Terracotta, Beowulf, etc etc etc.

La clave esta en el "no tan facil"... a alguien como yo quiza le emociona el reto de armar su infraestructura de grid computing, pero un negocio definitivamente preferiria comprar una nubecita y saber que si algun dia tiene que migrar " a la de a deberas" sera cuestion de un solo click.

Y por otro lado... si vendieran algo así, no sería vaporware? **bazzinga**

Jajajaja, definitivamente (me pregunto cuantos entenderan la broma). Por otro lado Microsoft es uno de los que esta pensando entrarle a este mercado de las nubecitas...

Imagen de luxspes

Las cosas no pasan... hasta que pasan

Interoperabilidad entre nubes? Vaya que no es una tarea sencilla, pero a qué nivel quieres dicha actividad?

Click y mi sistema esta en Azure, click, y esta en Google, click y esta en Amazon, click, y esta en mi datacenter. Click click click, y click, y esta en los 4. A ese nivel ;-)

A estas alturas hablar de interoperabilidad a nivel infraestructura o plataforma son cosas muy distintas. Ya que incluso a nivel sistema operativo la hay. Por otro lado, hay empresas como dotCloud que están intentando cambiar esa perspectiva al ofrecer ciertas plataformas, frameworks y servicios correr de manera transparente entre diversos servicios de infraestructura o incluso plataforma en la nube.

Interesante... me pregunto si puedo instalar dotCloud localmente.

Nuevamente, son conceptos no muy maduros pero que se están convirtiendo en realidad por medio de terceros. Por cierto, yo no lo llamaría centralización, ni llamaría centralizado a un vendor lock-in.

No? por que?, veamos la definicion de centralizar:

centralizar.
(De central).
1. tr. Reunir varias cosas en un centro común. U. t. c. prnl.
2. tr. Hacer que varias cosas dependan de un poder central. U. t. c. prnl.
3. tr. Dicho del poder público: Asumir facultades atribuidas a organismos locales.

A mi me suena a que vendor lock in es precisamente hacer que varias cosas dependan de un poder central (el del vendor que te tiene en lock in)

Jamás se te ha prometido tener un proveedor distribuido :)

Jamas ha pasado algo hasta que pasa por primera vez. (Es obvio.. que no?)

Lo que se te prometió en las políticas de servicio es el proveerte de infraestructura o plataformas distribuidas, cuyos detalles a estas alturas supondré que los conoces. Que tan distribuida quieres tu solución depende de tí y de las necesidades de tu arquitectura a implementar.

Lo que se me prometiera en un momento dado, no tiene nada que ver con lo que me gustaria llegar a a tener... excepto quiza por que como no se me prometio, pues no lo tengo... y como no lo tengo... pues lo quiero ;-)

Imagen de ezamudio

tiene sentido?

Luxspes, creo que te olvidas de un aspecto muy importante de todo esto: costos.

Financieramente, qué sentido tiene para una empresa el poner una mininube a funcionar en un datacenter, para luego ver si suben todo eso "a la de berdat"? Cuánto me va a costar hospedar digamos 5 servidores, los cuales tengo que comprar (o arrendar por unos 2 años como mínimo), más la licencia del software de mininube? Luego lo comparo con lo que me cuesta subir de una vez a la nube "de a devis", seguramente el costo será mucho menor. Por lo tanto, quién va a comprar ese software para armar una mininube privada que sea igualita que la de Amazon o Google o VMWare, etc?

Como yo lo veo, la nube nació con el objetivo de quitarle esas broncas a las masas y que cualquier fulano pueda tener una aplicación distribuida en internet, o tal vez no distribuida, pero subir una app ya no requiere conseguir hospedaje en un datacenter y que te den acceso a un server que tiene instalado puro SW de infraestructura en donde tienes que montar todo a patin...

Imagen de luxspes

ya lo venden, y por ganar control, yo le veo sentido de negocio

Pues en parte ya lo venden. Quiza microsoft esta tan equivocado como yo.

En cuanto al sentido de negocios?: Control, Independencia, Interoperabilidad. En el caso de Azure, el saber que, si quieres, puedes correr tu codigo inalterado en tu nubecita, o en la mega nube de microsoft. Hay lock-in, pero al menos puedes decidir donde estan tu datos. Y si quieres iniciar tu propia "chochosnube", solo tienes que comparle el appliance a microsoft y empezarle a vender servicios a otros (aunque todavia dependes de las reglas que microsoft define para Azure ya tienes control sobre la ubicación geográfica del datacenter)

Ahora pensemos en alguien que lo lleve mas alla, quiza derivado de un proyecto opensource (quiza derivado de Diaspora, Hadoop, Cassandra, Terracotta o algun otro?) en donde el software vaporizador este listo, y uno pueda ponerlo en su empresa, o poner un hosting para unos pocos asociados, o construir una mega nube como la de amazon.

Que falta mucho para llegar ahi? de acuerdo... que nunca lleguemos ahi? eso quien sabe.

Imagen de luxspes

problemas legales

Por otro lado, la nube apenas esta empezando, todavia esta fuera del radar de por ejemplo, la clase politica de muchos paises, haciendo facil que se creen contratos donde empresas y gobiernos de un pais ejecutan sus procesos en las nubes de otros...

Pero en cuanto uno de los paises poseedores de nube aplique un embargo a otro... empezaran (quiza) a aparecer leyes de "importancia estrategia de las nubes como recursos dentro del pais" que quiza generen el incentivo economico para construir nubes locales con capacidades de interoperabilidad, si no por otro a razon que para satifacer los requerimientos legales de los gobiernos.

Imagen de luxspes

(Real) Storm Crushes Amazon Cloud, Knocks out Netflix, Pinterest

Y se volvio a caer la nube de Amazon.

Netflix, Pinterest, Instagram se fueron,junto con ella...

Amazon EC2, poder concentrado, caida concentrada.

Imagen de ezamudio

ntp+linux+jvm > Y2K

Se supone que ahora la falla fue una combinación de factores: NTP sobre Linux, en conjunto con una aplicación JVM y/o MySQL corriendo de forma contínua (un server pues). Al momento en que se hizo el ajuste del leap second que ocurrió el sábado (algo que ocurre cada quién sabe cuántos años, por broncas del reloj atómico que necesita un ajuste de vez en cuando), algo pasaba en la JVM o en el MySQL que se trababa algún proceso y se iba el CPU al 100%. Las consecuencias fueron varias: servers que se reiniciaban porque no aguantaban la carga, o se quedaban trabados y ya no respondían porque estaba totalmente atascados.

Lo raro es que yo tengo un montón de servidores con Linux corriendo aplicaciones Java todo el tiempo (son como 12 servidores, con distintas versiones de Linux, principalmente Fedora y CentOS, y distintas versiones de Java 6 y 7) y con ntp habilitado. Me enteré de esta bronca el sábado en la noche y entré a ver si había algún problema. Todos estaban con carga normal. Revisé el uptime, pensando que tal vez se habían reiniciado. Nada... uptime de varios días (tanto del server como de las aplicaciones Java y del ntp). Así que creo que no fue algo tan general de JVM; tal vez solamente cuando hacen ciertas operaciones de fecha, aunque pues mis apps piden System.currentTimeMillis() MUY seguido para ponerle timestamp a cada operación que realizan; también se crean varios objetos java.util.Date. Lo que creo que no manejan tanto es GregorianCalendar pero seguro por ahí se crea uno que otro de vez en cuando. En fin, no tuve que resetear ni arreglar nada.

Netflix sí funcionaba el sábado en la tarde; si se cayó, lo levantaron rápido. Instagram me vale gorro, no lo uso (ni pinterest) pero creo que twitter y linkedin también fueron afectados (sí me tocó que un rato twitter no respondía a algunas peticiones como ver retweets o búsquedas, y sabemos que twitter tiene varios servicios funcionando sobre la JVM).

Imagen de luxspes

Sin Netflix en Navidad... por que se cayo la nube...

Y otra vez: Sin Netflix en Navidad por que se cayo la nube...

Imagen de luxspes

Y ahora le toco a Azure

Y ahora, le toco a a Azure caer. Aparentemente un problema de certificados...

A esto es a lo que me referia con centralizacion. La nube (la de Amazon, la de Microsoft, la de Google, la Oracle) es quizá mas resistente y robusta que el pequeño servidor de una microempresa, o el datacenter de una mediana empresa...

Pero... ¿es antifragil? Digo, por supuesto que es mas facil tirar (o que se caiga) el servidor de una micro empresa, pero ¿cuales son las probabilidades de que los servidores de miles de micro empresas se caigan al mismo tiempo? fuera de la nube? muy bajas... dentro, como hemos visto, bastante probables

Y ahi es donde nos advierte Taleb:

La globalización crea fragilidad entrelazada, mientras que reduce la volatilidad y da la apariencia de estabilidad. En otras palabras, se crea devastadores Cisnes Negros. Nunca hemos vivido antes bajo la amenaza de un colapso global. Las instituciones financieras se han estado fusionando en un menor número de bancos muy grandes. Casi todos los bancos están interrelacionados. Así que la ecología financiera es esta llenando de hinchados bancos gigantescos, incestuosos y burocráticas - cuando uno falla, todos caen.

El aumento de la concentración de los bancos parece tener el efecto de hacer que las crisis financiera sean menos probables, pero cuando ocurren son de alcance mas global y nos golpean muy duro. Hemos pasado de una ecología diversificada de pequeños bancos, con diversas políticas de préstamo, a un marco más homogéneo de empresas que todos se parecen entre sí. Es cierto que ahora tenemos menos fallos, pero cuando ocurren .... Me estremezco sólo de pensarlo.

Solo sustituyamos "la banca" por "la nube"... y tendremos tema para una buena discusión...

Imagen de luxspes

Nebula

El proyecto Nebula parece el primer paso para que las empresas puedan tener sus "mini-nubes":

"NebulaOne te permite comenzar con el poder de cálculo y almacenamiento que necesitas hoy, y la capacidad para escalar a la perfección a través de varios "racks" en el futuro", afirma la compañía. "Esto se logra a través de una arquitectura sencilla y ampliable que se presenta como un sistema único en la red. El sistema operativo "Nebulosa Cosmos" ofrece una interfaz gráfica rica e intuitiva para usuarios de cualquier nivel. Para los desarrolladores, Nebulosa Cosmos implementa las API de OpenStack y Amazon Web Services para que puedan aprovechar sus conocimiento de los servicios cloud públicos ".

Imagen de ezamudio

uta

vaya mini-nube... Nebula vende sólo el controlador y tú tienes que comprar tus servers, que sean de los aprobados por ellos, como el HP DL380. Y el controlador más baratito cuesta 100mil dólares. Así que mini mini no es, y no es una opción como para que cualquier empresa pueda darse su propia nube...

Imagen de luxspes

OpenStack

Nebula es la version cara, es cierto, pero el software en el que esta basado OpenStack, es abierto.

Aqui esta la guia de instalacion.... ¿cuantas maquinas consideras que seria lo "minimo viable" para demostrar que funciona a escala mini-nube?

Imagen de luxspes

Se va formando un patrón

El patrón se va formando http://www.theguardian.com/technology/2013/aug/23/nasdaq-crash-data el cisne negro se va configurando... Pero cuando llegue todos dirán que era imposible verlo venir

Imagen de luxspes

MaidSafe : Llega una plataforma descentralizada?

Llega MaidSafe (http://maidsafe.net) una plataforma de código abierto que habilita al internet como una plataforma descentralizada... un primer paso en el camino para evitar al cisne negro del colapso de la nube centralizada?