Confieso que no he probado todavía Firefox 4. La verdad es que Chrome me ha dado todo lo que necesito. Pero hay algo que me ha gustado mucho de Firefox 4 sin haberlo probado, y es su página de visualización de descargas en tiempo real. Mozilla Glow. Realmente impresionante.
En un mapa del mundo se pueden ver en tiempo real todas las descargas que se están realizando de Firefox, y que no son pocas ya que en el momento de escribir estas líneas ya van 37 millones.
Desde el punto de vista técnico la utilidad de este tipo de visualizaciones es más bien nula, salvo el hecho de poder decirnos: "bien, hay gente descargando nuestro software". Desde el punto de vista de marketing el impacto es brutal. Hay que darse cuenta de que Firefox tampoco es un navegador tan popular (o era), y el efecto que tiene este gráfico en una persona de a pie es cercano al "Guau!!! ¿¿¿pero hay realmente tanta gente descargándose Firefox???". Esto no puede ser malo.
El servidor de datos más verde del mundo está donde menos me lo podría esperar. Justo debajo de la catedral de Helsinki. Para ser más exactos, se encuentra a unos 30 metros bajo tierra dentro de un antiguo refugio de guerra.
Lo que las compañías finlandesas Academica y Helsingin Energia han hecho es realmente interesante. Lo primero es que no utilizan energía para refrigerar el centro de datos sino que se aprovechan diréctamente del agua del mar, que evidéntemente en Finlandia debe de estar lo suficientemente fría.
Interesante reflexión en el blog de Percona sobre si tener más memoria RAM tiene ya sentido cuando los discos SSD están cada vez más baratos.
En sus pruebas crearon un conjunto de datos de 230Gb. y empezaron a darle caña al MySQL variando el tamaño del buffer de datos de memoria. Aquí están los resultados:
O eso dice su dueño. Le llaman el Fort Knox Suizo y se encuentra emplazado en lo que antaño era un refugio nuclear en el los Alpes suizos.
El centro de datos está formado por dos bunkers independientes situados bajo tierra, en el corazón de la montaña, y unidos por un túnel subterráneo de 10 kilómetros de largo. La compañía que diseñó el refugio de datos ha aprovechado además los recursos de la montaña y la peculiar situación para refrigerar los servidores de manera natural. Así, todo el sistema de refrigerado se abastece de agua que proviene de un lago glaciar subterráneo.
El lugar para emplazar el refugio quizás no esté tan pensado, ya que como comentan en Wired, que publicó este mes un reportaje sobre tan peculiar lugar, en el valle cercano a la montaña se encuentra la mayor concentración de billonarios de todo el planeta, y aquí estoy especulando, quizás guarden más que datos en sus cajas acorazadas.
El refugio que tuvo un coste de construcción de alrededor de los 30 millones de euros, contiene lo último de lo último en cuanto a seguridad, reconocimiento facial, plásticos anti-bala, filtros de aire militares capaces de filtrar impurezas atómicas y químicas, hotel de emergencia y cámaras acorazadas cortesía de bancos suizos. Y por supuesto su funcionalidad más deseada es la que proviene de su uso original, puede sobrevivir a un ataque nuclear.
Si queréis conocer más sobre esta bestia de la seguridad os recomiendo ver el artículo de wired.
Estaba repasando algunas entradas en la red sobre MySQL y me he encontrado sobre este artículo que habla del problema que tiene MySQL con la gestión de Threads y en particular con la plataforma Java.
Básicamente el problema es que MySQL se ejecuta como un único proceso. Este proceso crea un Thread para cada una de las conexiones que recibe. En MySQL lo implementaron de este modo porque parece que era realmente rápido. Pero entonces se encontraron con esas plataformas que, como Java, están llenas de pools de conexiones.
Para los que no estéis familiarizados con este concepto, la idea de un pool de conexiones consiste en reservar de antemano las conexiones a recursos externos como son las bases de datos. El conectarse a un recurso externo suele ser una tarea costosa en cuanto a tiempo, y por lo tanto el mantener una estructura de memoria donde se guarden conexiones abiertas que se puedan reutilizar cada vez que nuestro programa accede a ese recurso, parece una buena idea. Cualquier servidor de aplicaciones Java que utilicéis funciona de este modo, Tomcat, Glassfish, WebSphere, WebLogic, el que sea. En otros lenguajes como .NET o Rails también es algo típico.
Y ese es básicamente el problema. La persona que administra el servidor de aplicaciones puede decidir el crear un pool grande: "Voy a reservar 500 conexiones porque vamos a tener muchos usuarios concurrentes". Lo que hará el servidor de aplicaciones es abrir 500 conexiones y mantenerlas abiertas de por vida, aunque no se utilicen. Como consecuencia en MySQL se abren 500 threads, aunque no se utilicen.
Lo ideal sería que MySQL tuviese también un pool de conexiones, pero por ahora va a ser que no. Parece que MySQL 6.0 sí lo va a tener aunque están resolviendo algunos problemillas.
Por cierto si utilizáis MySQL, el blog de Percona tiene dos artículos bastante interesantes:
Hace unos meses, Tom Cook, Ingeniero de Sistemas de Facebook daba una charla en el evento Velocity 2010 de O'Reilly donde describía como es el día a día dentro del servicio de operaciones del gigante americano de las redes sociales.
La charla comienza con algunas estadísticas que le quitan el hipo a cualquiera:
- La gente pasa 16000 millones de minutos diarios en Facebook - Se comparten 6000 millones de piezas de contenido al mes - Se suben 3000 millones de fotos al mes - Hay un millón de implementaciones de Facebook Connect
A todo ello contribuye que 50 de los 100 sitios más visitados del mundo integren Facebook de algún modo, ayudando a llegar a los 400 millones de usuarios de este 2010. Para soportar esta carga de usuarios, Facebook tiene dos centros de datos. Uno en la costa Este y otro en la costa Oeste de Estados Unidos y están construyendo uno nuevo en Oregon. Todos sus servidores utilizan Linux y su distribución es CentOS.
Nada más comenzar la charla uno se da cuenta de que Facebook es un lugar donde la opinión de los ingenieros tiene realmente mucho peso, para bien o para mal. Está claro que no es trata de un lugar habitual. Algo que me ha sorprendido por ejemplo es que la propagación de parches y cambios a producción se hace con BitTorrent, moviendo ese código a más de diez mil servidores. Otro uso interesante de BitTorrent.
Pero hay cosas todavía más sorprendentes. Facebook está hecho en PHP. Sin embargo parece que el rendimiento llegó un punto en el que no era aceptable. Lejos de cambiar de plataforma, ya que a sus ingenieros les gusta PHP, crearon una herramienta interna para traducir el PHP a C++, compilándolo después con g++. El resultado fue un 50% de aumento en el rendimiento que podríamos trasladarlo, aunque no sea estríctamente así, a un 50% menos de servidores. Sea como sea, el crear un traducor de PHP a C++ no parece que sea el tipo de decisión recomendable para todas las compañías que quieran más rendimiento.
Otro modo que tienen de aumentar el rendimiento es utilizar cachés (Memcached) y una enorme cantidad de memoria RAM: más de 300Tb de datos en vivo en diferentes cachés. Utilizan MySQL en la base de datos. Sobre MySQL en Facebook ya puse unas notas hace un año en el post "Notas sobre la arquitectura de Facebook".
La principal conclusión que he extraido de esta charla es que Facebook es, sin ninguna duda, una de esas compañías dirigidas principalmente por el equipo de operaciones. Está claro el peso de este departamento en el proceso de desarrollo y producción. En mi experiencia, trabajar en este tipo de empresas puede llegar a ser un auténtico infierno en los casos en los que el equipo de producción esté demasiado aislado del equipo de desarrollo, en los casos en que los procesos de trabajo estén demasiado cargados de burocracia o en los casos en que el departamento de operaciones tenga excesivo celo en cuanto a la implantación de cambios y nuevas funcionaliades.
Facebook nuevamente es diferente. Tom Cook comenta en su charla como los ingenieros de operaciones se mezclan con los ingenieros de desarrollo para trabajar conjuntamente en los parches y funcionalidades. Asimismo, los desarrolladores adquieren plena autonomía y responsabilidad sobre sus actos, de modo que deben participar en todas las fases de despliegue y sentarse con el equipo de sistemas a la hora de pasar cambios a producción.
Una de las consecuencias de esto es que en Facebook han eliminado la capa de QA. Esto en mi opinión es un error, pero no cabe duda de que Facebook es un sitio diferente. Me imagino que todo el desarrollo de productos y parches estará dirigido por procesos controlados, pero desde luego la impresión que se extrae de la charla es que los ingenieros tienen poco más que barra libre para introducir cambios a su antojo sin el más mínimo control de calidad. Claro, uno después se explica como en funcionalidades que no son 'core' como puedan ser las aplicaciones Facebook, un día las cosas funcionan y otro no :-)
Pero entonces, ¿cómo suplen esta falta de control de Calidad? Con un gran énfasis en la monitorizacíon y la instrumentación. Todo lo que sucede en los servidores de Facebook está completamente controlado. Para ello disponen de herramientas internas o usan software Open Source como Ganglia, Nagios o CFEngine. Pueden controlar en cualquier instante el estado de cualquier servidor, rack, cluster o centro de datos. Además de resaltar la importancia de la monitorización y la instrumentación se hace relevante también el automatizar la reacción ante caidas de cualquiera de estos componentes, ya sea eliminando el nodo, reiniciándolo, etc.
Una cosa queda clara en la charla. En Facebook no se toman las operaciones a broma. Aunque nuevamente hay cosas muy desconcertantes en cuanto al control de calidad. En la charla muestran herramientas de comunicación interna que se utilizan para que todo el mundo en la compañía conozca el estado de los sistemas en cualquier momento independientemente de tu puesto en la compañía. Es algo sin duda fantástico. Pero asimismo cuando sucede un problema lo que se entiende de la charla es que lo resaltan en su portal interno de noticias y esperan a que ningún ingeniero introduzca código, ya que éstos tienen la capacidad de introducir cambios en cualquier momento. Esto no hace más que reafirmar en mi interior que Facebook no es una empresa tradicional, y que por el contrario ofrece ese sentimiento de funcionamiento bastante anárquico en ciertos aspectos.
Por último, os dejo el video por si interesa verlo vosotros mismos.
En Bank Info Security han publicado una gráfica muy interesante sobre los fraudes más importantes que se han llevado a cabo durante lo que va de año dentro de los Estados Unidos.
Para nosotros, en Europa, no es demasiado relevante pero si pasáis el ratón por la gráfica podréis ver la descripción de todos estos casos y se puede apreciar que es algo que nos puede pasar a cualquier de nosotros en cualquier lugar. ¡Da miedo!
Ayer, Abe Voelker hacía públicos varios fallos de seguridad muy graves en las web Progress Software (los que compraron IONA en el 2008). Se trata de fallos muy básicos que exponena públicamente los datos personales, incluyendo las contraseñas, de más de 96.000 clientes. Casi nada.
No voy a entrar en detalle en como acceder a esos datos, ya que todo está explicado en el blog de Abe, y el que quiera puede probar. Pero si os paráis a leer en detalle el artículo, veréis que son realmente conceptos tan simples que uno se pregunta si ha habido algún tipo de revisión de código. Me imagino que los programadores serían inexpertos, más razón para revisar el código. Si ese era el caso es una gran falta de responsabilidad del responsable del proyecto. Si ha sido por desidia, la responsabilidad es doble, del autor y de su superior.
El primero de los ataques, porque vaya es que no sé ni si se pueden definir como ataques, es el acceder a una URL de mantenimiento de perfil, que no se encuentran protegidas. Si ahí pones el nombre del usuario de cualquier persona que haya solicitado alguna mejora en el software de Progress, verás todos sus datos.
La contraseña aparece con asteriscos, pero que no os engañe, es simplemente el campo HTML, si vamos al código fuente el password está en texto plano.
El segundo ataque ya no funcionaba a la hora de escribir esto. Quizás hayan borrado el CGI, o quizás sea simplemente un error tipográfico y se pueda todavía acceder a la información, lo cierto es que no lo he intentado. Pero era más de lo mismo salvo que se exponía toda la información en texto plano en formato XML. Alguno podrá decir, "pero es que hay que conocer los login de todos los usuarios". Nada demasiado complicado cuando tienes una People Community Search. Cualquiera podría hacer un bucle y conseguir las contraseñas de todo el mundo.
Otra curiosidad es que parece ser que las únicas contraseñas que estaban en texto plano eran las de sus usuarios y clientes. Las contraseñas de sus empleados estaban encriptadas, eso sí en SHA1 sin salt. Bueno, pero algo es algo si lo comparamos con la información de los clientes. Supongo que les costaba mucho el reutilizar el código.
El otro día casualmente comentaba con un cliente lo importante que es no utilizar las mismas contraseñas en los diferentes servicios. El me comentaba que siempre utilizaba la misma, y tampoco veía demasiado peligro en ello. Puede que no, a mi tampoco me importa demasiado que me hackeen mi cuenta de Facebook. Pero si ya entran en mi cuenta de Paypal, entonces sí que me puede hacer más pupa :-)
Han pasado casi cinco meses desde mi último post, y la verdad es que hoy me he pasado por el blog y me he sorprendido al ver 990 lectores por Feedburner. Evidentemente, la mayoría de estos lectores son como yo, no leen los feeds a los que están suscritos, pero vaya que me ha hecho pensar "pero que coño estoy haciendo que estoy abandonando este blog en el que tanto trabajo he puesto". Así que he hecho el propósito de poco a poco ir retomando la actividad. A ver cuanto dura :)
Y empiezo con un tema que hace tiempo que había visto y me había entusiasmado. Últimamente no sé que pasa pero me he vuelto un apasionado de todo lo relativo a los cibercrímenes. Así que quizás tenga nueva temática para el blog. Este tema lo recordé gracias a un gran y muy educativo artículo de José Manuel Alarcón llamado reCaptcha, mucho más de lo que ves a simple vista, y en el que explica muy detalladamente como funcionan los Captchas y por qué hay tanta gente deseando romperlos. Si sois de los que piensan que son simplemente dos palabrejas que hay que meter de vez en cuando para ver si somos robots o no, echarle un vistazo porque veréis que hay mucho más.
La verdad es que a mi lo que más me gusta es la parte oscura :-) Pero voy al tema. Creo que todavía estaba en Irlanda cuando leyendo el Metro había visto que habían detenido a una banda que se dedicaba a saltarse Captchas para comprar tickets de conciertos. Recuerdo que me sorprendió porque me pareció la caña. Pues bien, hace tan sólo unos días leía que ese caso será definitivamente juzgado en Marzo, ya que hasta ahora se encontraba en un laberinto legal, pero definitivamente una juez de Nueva Jersey ha decidido proceder al juicio donde se busca condenar a esta banda por fraude electrónico y diversos abusos contra una ley de Anti Hacking o algo así :)
Podéis ver la historia completa en Wired que a mi me ha parecido apasionante. Nada más y nada menos que 25 millones de dólares en beneficios ha hecho esta gente, en siete años de nada. Para ello contrataban bloques de IPs y varias redes de ordenadores remotos que lanzaban contra webs como Ticketmaster en los momentos en los que comenzaban las subastas más interesantes, haciéndose con grandes cantidades de tickets. Algunos datos del juicio son impresionantes. Por ejemplo en el 2006 consiguieron comprar 882 de los 1000 tickets disponibles para la Rose Bowl (título de futbol americano universitario) o en 2007 que compraron 1924 tickets para los playoffs de los Yankees.
Pero lo mejor fue cuando Ticketmaster se dio cuenta de que algo no iba bien y cambió el algoritmo a utilizar Re-Captcha. Entonces la banda decidió crear bots para descargarse todos los captchas, que están identificados por ids, y creó una enorme base de datos de cientos de miles de Captchas asociados con sus respectivas ids. Bueno, ya sabéis para que sirven estos trabajos que se anuncian por correo "Trabaja desde casa. Gran sueldo. No se requieren ningunos estudios!", o quizás simplemente contrataran personas al kilo para leer captchas. También parece que configuraron su red de bots para que cometieran fallos a posta para evitar ser cazados por los filtros anti-fraude de las casas de tickets.
Pero la red iba todavía más allá. Ellos ya no eran ni siquiera los que vendían los tickets. Ejercían de intermediario. Había una red completa de brokers de tickets, usease reventas, que les proporcionaban sus datos y su tarjeta de crédito a la red, y la banda lanzaba sus ordenadores garantizándoles la compra, entiendo que por su correspondiente márgen. La leche, vamos.
No sé si vosotros os podíais imaginar que los Captchas daban para tanto pero a mi todo esto me parece de película :-)
Entre los comentarios se sacan datos muy curiosos como que en Facebook asignan un administrador para cada millón de usuarios. Partiendo de que tienen más de 30000 servidores y 230 ingenieros, utilizando 30000 como el dato exacto saldrían 130 servidores por administrador.
En Microsoft todo está más automatizado y comentan que un sólo administrador trabaja dentro del ratio de 1000 a 2000 servidores.
De OWASP ya he escrito en otras ocasiones. Es una asociación para la promoción de la seguridad en la red que no conocía, y con la que tuve contacto por primera vez en Irlanda, aunque tienen también su capítulo en España.
Una de las cosas que empezaron a finales del año pasado y que han desarrollado bastante este año es la publicación de un Podcast sobre seguridad bastante imprescindible para el que le interese estos temas. A mi personalmente muchos de los temas ahí ya se me quedan un poco grandes, sin embargo sí que me llamó un poco más la atención un podcast de hace unas semanas en el que hacían una entrevista a Andy Steingruebl (PayPal Secure Development Manager).
En el Podcast Andy comanta su experiencia en Paypal y realiza una serie de recomendaciones. He recogido unas cuantas notas del podcast que tenía pendientes de publicar y que pongo a continuación:
CSRF y Cross-site Scripting son los problemas más grandes en la actualidad. Cosas como SQL Injection todavía están muy presentes pero existe más educación sobre ellas y las soluciones son mucho más conocidas.
Una vez establecidos unos protocolos de acción y una buena metodología de trabajo los costes de hacer desarrollo de software seguro e inseguro no se diferencian tanto. Hay montones de librerías y utilidades disponibles en la red. El coste está más en conseguir la disciplina y la mentalidad en una organización para que se apliquen prácticas de desarrollo seguras.
Aplicar técnicas de desarrollo seguro en metodologías ágiles es más complicado ya que se centran siempre en pequeñas ventañas de funcionalidades. Es posible, pero es más complicado que con metodologías adhoc.
(sinceramente, aquí no le vi sentido a esto. Estoy bastante en desacuerdo. Me imagino que el problema es más de adaptar una gran empresa como Paypal y todos sus planes que tienen que realizar para auditorías de seguridad a las metodologías ágiles que otra cosa.)
No reinventar la rueda. Reutilizar frameworks de seguridad.
Aunque los IDEs incluyen herramientas de análisis estático todavía hay mercado para esas herramientas. Hay muchas compañías pagando por herramientas específicas para el análisis estático de código.
Alguién sugería la necesidad de 150.000 profesionales del software. Andy se muestra en desacuerdo y opta más por la formación y aprendizaje como la solución. Educar a los desarrolladores e incluso incluir nociones de seguridad en la formación universitaria. Los desarrolladores no necesitan ser expertos en seguridad, pero sí que deberían tener conocimientos básicos sobre los ataques más comunes y sus soluciones, así como conocimientos de que herramientas y librerías utilizar para prevenir estos ataques.
PCI no es una mala certificación ya que al menos fuerza a las personas a tomar algunas medidas de seguridad. Aún así, eso debería salir directamente de las empresas y no ser medidas encaminadas únicamente a pasar la auditoría.
Volviendo al tema del agilismo, el podcast en sí está bien pero la parte de que las metodologías ágiles hacían más difícil el desarrollo seguro no tiene ni pies ni cabeza.
Edit: Muy rápido. Después de haberme dado de alta, aclaro lo de las limitaciones porque es algo engañoso. El límite es por un único chequeo, y no por servidor o página web. Es decir, para un mismo sitio web no podrás crear varias alertas sino tan sólo una. Le resta un poco la utilidad pero bueno... es gratis.
De rebote, estos últimos días en el equipo de Jobsket nos hemos visto en medio de una situación tan rocambolesca como trágica. Tiene que ver con el servidor que utilizamos para desarrollo en Jobsket, y menos mal que se ha quedado en eso.
Os cuento, cuando empezamos con Jobsket, estábamos utilizando un servidor virtual que yo tenía contratado en los Estados Unidos. El precio era un poco alto y el tiempo de acceso también así que decidimos movernos a un centro de datos en UK para estar aquí en Europa. Todo esto que os voy a contar afecta sólo a nuestro servidor de desarrollo ya que el servidor de producción lo tenemos en otro lugar.
Como queríamos algo baratillo y funcional, ya que simplemente utilizamos esta máquina como integración, para los tests y eso, nos decidimos por VAServ que venían precedidos de muy buena fama en sitios como WebHostingTalk. Vaya por delante que la gente de VAServ siempre ha respondido prontamente y con eficacia.
Bueno, pues hace dos días recibimos un correo que comenzaba así:
"As many of you are aware, we were hacked today around 7pm GMT and portion of our service has been cut off (mostly US and portion of UK servers)."
Habían sido hackeados. Después de cambiar la contraseña, y de sentirme aliviado porque la tarjeta de crédito que había usado ya no está activa, pues me puse a investigar un poco sobre lo que había pasado. Aparentemente los hackers no se limitaron a robar datos, sino que han destruido buena parte de los datos que había en los diferentes servidores, con la gravedad que esto conlleva ya que este proveedor barato era enormemente popular con miles de clientes. Buena fé de esto da el hilo principal en WebHostingTalk sobre el tema que ahora mismo alcanza ya las 115 páginas.
En fin, la gente de VAServ lleva trabajando día y noche para solucionar el problema. Nosotros no teníamos nada demasiado importante ahí, salvo el sistema de integración continua que nos daría bastante trabajo de recuperar la configuración de las diferentes build, pero por suerte no hemos sido afectados por el ataque. Sí que lo han sido otros muchos a tenor de lo comentado en el foro, que tenían negocios más importantes.
Pero ahora viene lo grave. El ataque se debió al sistema de gestión que utiliza esta gente, HyperVM, un producto de la compañía LxLabs, una firma india fundada por K T Ligesh. Ayer, TheRegister reportaba el ataque que como podéis ver no nos ha afectado sólo a nosotros, sino que ha podido haber más de 100.000 sitios web afectados por el problema.
Pues bien, hace nada y según parece debido a la falta de interés de LxLabs se hizo pública la lista de vulnerabilidades de su producto, que incluye 24 bugs bastante graves. Como reportan en HostingFu el producto no era una maravilla, pero parece que lo peor ha sido la falta de interés.
Y ahora viene el final triste de la historia. El dueño de LxLabs, Ligesh, fue encontrado hoy ahorcado y se sospecha de suicidio. En el Times de India hablan de la pérdida de un contrato importante. Su madre y su hermana se habían suicidado hace cinco años, algo que también había afectado a Ligesh. Y parece que esto pudo ser la gota que colmó el vaso.
Una historia muy triste en la que nos hemos visto por en medio muy de refilón. Descanse en paz.
Esto va a ser enorme. Leo en Finextra que Facebook ha empezado ya a probar su sistema de micropagos virtuales. Es decir, que a partir de ahora podrás comprarte un queso de Arzúa virtual por tus 10 céntimos para regalárselo a algún amigo. O crear un juego para ver quién bebe más cubatas y cobrar 20 céntimos por instalarlo.
No hace falta ser un genio para ver la cantidad de dinero que se va a generar de esto. Y cuanto más chorra sea la aplicación mejor. En fin, parece ser que esto va a funcionar comprando créditos con tarjeta de crédito. Cada crédito valdría 10 céntimos y se podrían utilizar para pagar en Facebook. Facebook se lleva un porcentaje de cada transacción. Con 200 millones de usuarios y 54 mil aplicaciones, yo creo que hasta con sólo coger 0.1 céntimos de cada 10 la cantidad de dinero que harían sería enorme.
Por otra parte, comentan que esto puede ser bastante beneficioso para los comerciantes, ya que al comprar por créditos se evitan las comisiones de las tarjetas de crédito (estas ya han aplicado la comisión antes). Y claro, al igual que ha pasado con Facebook Connect, es muy probable que muchos sitios web externos comiencen a aceptar pagos por Facebook.
Habrá que estar muy atentos a todo esto, porque el que quiera dar un pelotazo tiene aquí una buena oportunidad. Sólo hay que pensar en algo bastante chorra :)
El artículo está muy bien hecho y todo su contenido vale la pena, así que recomiendo su lectura. Básicamente comenta como en el 2007 Facebook decidió migrar un datawarehouse (de un vendedor que no menciona) de 15 terabytes a Hadoop. Las razones eran varias: precio de las licencias, menor coste de hardware, más rendimiento al no tener necesidad de transacciones, o la capacidad del equipo de Facebook para contribuir al Open Source.
Para el sistema de datawarehouse utilizaron Hive. Es interesante mencionar que la estabilidad del sistema no es perfecta, pero que parece que a los usuarios no les importan que se caigan nodos o que las consultas puedan tardar hasta 1 hora en devolver datos siempre y cuando no tengan que enviarlas de nuevo.
Por cierto que en otra nota en el mismo blog hablan del uso de compresión gzip que hace Facebook. Me apunto este blog de DBMS2. Parece un gran recurso.
Por cierto que por si os interesa, os dejo enlaces a estos dos posts que ya había escrito anteriormente sobre la arquitectura de Facebook y el uso que Facebook hace de Hadoop:
Muy interesante este hilo en el grupo de Cloud Computing de Google Groups, donde se exponen opiniones sobre cuales son los principales retos a la hora de migrar una aplicación tradicional a un entorno de Cloud Computing como pueda ser Amazon EC2. En el hilo se exponen algunas notas importantes:
Falta de software preparado para la "nube". ¿Dónde están nuestros cloud-enabled Tomcats, WebSpheres, WebLogics o Jbosses, por decir algo? O por poner un ejemplo más reciente, Google lanza el soporte Java en Google App Engine pero hay que pasarse unas semanas arreglando Groovys, Grails, JRubys y similares.
Volviendo al tema Google App Engine. La forma de programar cambia. Donde teníamos una base de datos tradicional ahora tenemos BigTable. Encapsulado o no en JPA o cualquier otro interfaz, hay que cambiar el chip.
Bienvenidos al mundo de la programación distribuida. Aunque se puede usar la nube para desplegar una aplicación en capas tradicional. Pues aquí la idea es la promocionada por BigTables, MapReduces y similares. Es decir, distribuir el procesamiento/almacenamiento/mensajería entre los diferentes componentes de la nube. ¿Estás preparado para ello?, o incluso mejor, ¿Están tus programadores preparados para ello?
Nati Shalom de GigaSpaces comenta este mismo hilo en su blog y también Grig Gheorghiu tiene comentarios interesantes sobre sus experiencias en un despliegue importante sobre EC2.
Esperar fallos parece uno de los consejos más sensatos que se pueden extraer de estas lecturas, y también el de intentar automatizar el proceso para no morir en el intento. Una buena lectura para el que esté planteándose una migración.
Sin duda, uno de los temas más importantes a la hora de crear una aplicación es la gestión de backups. Pero claro, qué pasa si no tenemos dinero para una SAN o una NAS, o ni siquiera un segundo servidor, o resulta que no podemos usar los servicios de cloud de Amazon o simplemente que no queremos, o peor aún, qué pasa si no tenemos los conocimiento suficientes como para hacer un backup completo...
Vaya lio. Bueno, Robin Blandford nos demuestra en un post que hasta las cosas que parecen de lo más complicado, se pueden hacer de la manera más simple. Si trabajamos con Subversion y MySQL, pues por qué no utilizar el primero para hacer backup del segundo.
svn ci /var/svn/yourprojectname/yourdbname.sql -m backup
echo SVN Commit Completed
echo Backup Done! $(date)
echo —
Solo quedaria poner nuestro SVN en algun otro servidor (en Internet hay algunos proveedores gratuitos) y listo respaldos incrementales que consumen poco tamaño y además offshore. Qué más se puede pedir :)
Confieso que no he probado todavía Firefox 4. La verdad es que Chrome me ha dado todo lo que necesito. Pero hay algo que me ha gustado mucho de Firefox 4 sin haberlo probado, y es su página de visualización de descargas en tiempo real. Mozilla Glow. Realmente impresionante. 
