Grippo Blog

Te muestro mi robot

2009-11-06T06:10:41Z

,,Este es el mensaje que me envía mi robot cuando ha moderado avisos en Clasificados Grippo. Si en el asunto dice "Black List" es porque se ha cometido algun tipo de abuso, y el aviso tuvo que ser eliminado. Generalmente es por ofrecer cosas que en Internet no estan permitidas o simplemente por spam.

Vanina atrapa ladrón. Ismael observa desde ventana. Ladrón se va tranqui a su casa.

2009-10-29T17:48:11Z

¿En qué se han transformado las noticias hoy en día? Las nuevas tecnologías hacen posible que los hechos que les ocurren a amigos y gente cercana, sean más importantes que el flujo de noticias considerado principal por los medios. Aquí va el ejemplo de hoy:

Hoy poquito antes de las 13 hs, recibo en mi Twitter esta secuencia de noticias. Vanina, es ex compañera de trabajo hace un par de días compartimos un panel en un evento organizado por INADI. Con Ismael compartimos ayer mismo un evento en Google Argentina. A ambos los sigo en Twitter y leo sus blogs:

	Recién ladrón que escapaba me lleva por delante, caemos al piso y la gente lo atrapa. Le dan varias piñas.
	Fue en diag.norte y suipacha. Llegó la policía rápido pero la gente no lo soltaba. Susto #ladrón
	3 tipos redujeron a un chorro frente a la oficina a patadas en la cabeza! Lastima que el hijo de puta seguro entra y sale al toque.
	Que loco! El chorro al que cagaron a trompadas se habia chocado con @vanis antes! Y yo mirando desde la ventana y twitteando lo mismo :s

Ambos fueron testigos en el mismo lugar. Finalmente la crónica terminó así:

Al final el chorro se fue libre en la ambulancia porque la victima del robo se fue y los que lo cagaron a trompadas tambien!

Contra la discriminación en la web

2009-10-20T18:58:25Z

Voy a participar de un panel en el próximo jueves, junto a Vanina Berghella (blogs.clarin.com), Matías Botbol (Taringa.net), Sebastián Rozenfarb (Keepcon.com) y Eugenia Klein (Inadi.gov.ar).

El INADI organizó para el próximo jueves 22 de octubre, a partir de las 10:30hs, un serminario y lo denominó: Seminario Buenas Prácticas contra la Discriminacion en la Web. Se realizará en el Auditorio de la Comisión Nacional de Valores, en ese bello barrio de Buenos Aires tan parecido a Ciudad Gótica, en 25 de Mayo 175. El evento tiene cupo limitado, por lo cual si te interesa asistir debes realizar la inscripción, enviando un mensaje a inclusiondigital (arroba) inadi.gov.ar.

Pueden consultar el programa completo en INADI.

Completada la migración a Amazon AWS

2009-10-07T21:27:57Z

Se van a cumplir 90 días de que migré mis aplicaciones a Amazon AWS. El 30/set, hace justo una semana, desenchufamos, desatornillamos y retiramos los servidores del datacenter de Diveo / SkyOnline / Netizen.

Lo que ves en la imagen, es lo que me costo el consumo en Amazon AWS durante el mes de setiembre. Son 4 servidores EC2 small y uno medium. Mas S3 con CloudFront (unos 30 millones de hits), más un load balancer.
A quienes habían leído mis notas anteriores durante la migración, les debía un reporte de gastos de un mes normal. Representa un cuarto de lo que estaría pagando en el datacenter de siempre, sin ninguna de las capacidades especiales de cloud computing.

No voy a decir que fue sencillo, la verdad que no. Sobretodo para alguien que siempre usó FreeBSD y de golpe tiene que usar Debian, porque no hay opción FreeBSD todavía para XEN, que es el virtualizador de servidores. S3, CloudFront, ELB son sencillos. EC2 no tanto, hay que dedicarle tiempo a conocerlo. EC2 + EBS (la unidad de storage) es sensacional.

Tampoco voy a decir que es igual al servidor de "carne y hueso". Es bien diferente. Hay que dedicarle bastante tiempo a tunearlo y configurarlo adecuadamente. Ahora que ya pasó, estoy muy conforme, pero cada aplicación que moví, significaron días completos de problemas en la configuración que necesitaban ajustarse, para que la performance sea aceptable. Ahora todo anda mejor que óptimo. Y estoy muy contento y aliviado de haber traspasado todos los inconvenientes.

Escribiendo las notas durante la migración, encontré que mucha gente se había interesado. Luego caminando por esos mundos (reales), encontraba aquí y allá a quienes habían leído mis notas y me comentaban esto y aquello. Asique este reporte va para ustedes que venían siguiendo esta serie, se los había prometido.

También aquí y allá encontré varios sitios realmente grandes que estaban también migrando o ya habían migrado a Amazon y algunos de ellos compartieron valiosa información conmigo, les agradezco mucho!

Las proximas notas serán sobre EC2, que es lo que más problemas me trajo.

No puedo usar urls cortas y ELB al mismo tiempo

2009-09-05T06:59:41Z

ELB = Elastic Load Balancer.

El jueves pasado, cuando iba a entrar a ver Bastardos sin gloria, chequeé por un instante cómo funcionaba grippo.com en mi iphone, y encontré otro sitio en su lugar.

Ahora entiendo mejor, por qué pasó eso, y cuán equivocado estaba yo con respecto a los registros CNAME y a las direcciones IP de ELB.

Yo queria tener urls del tipo http://grippo.com/aviso/1234 y http://grippo.com/buscar/departamentos+en+mar+del+plata, es decir usar solo el dominio, sin www. Mi proveedor de DNS primario (www.mydomain.com), es un tipo de proveedor que permite poner CNAME del dominio completo (sin subdominio). Entonces siempre pensé que era legal. Pero en realidad yo no estaba entendiendo claramente qué significaba. Poner un CNAME en el dominio, si tu DNS primario te lo permite, es útil sólo cuando el dominio es efectivamente un alias 100% del host de destino del CNAME. De hecho, la primera semana de subirme a Amazon AWS, lo que hice fue poner algo asi como:

grippo.com IN CNAME grippo-2014187730.us-east-1.elb.amazonaws.com.

ya que ese es el nombre de mi load balancer. Al hacer eso, me quedé sin mails @grippo.com, porque no tenía caso haber configurado registros MX en mi archivo de zona de grippo.com, ya que ese CNAME invalidaba todo el resto. Tuve que averiguar entonces la IP de grippo-2014187730.us-east-1.elb.amazonaws.com, que era una hace unos dias, y es otra ahora, y convertir ese registro en

grippo.com IN A 123.45.67.89

Eso anduvo bien hasta que Amazon le cambio la IP a grippo-2014187730.us-east-1.elb.amazonaws.com. Eso trajo la pantalla extraña de esta historia. Ahora bien, siendo que uso un load balancer, ahora entiendo que está bien que Amazon me aconseje usar un CNAME apuntando a grippo-2014187730.us-east-1.elb.amazonaws.com, ya que eso hace que su load balancer sea más elástico, es decir que pueda ser redundante en caso de fallas, y derivar trafico por otros dispositivos, cuando el dispositivo original falla o simplemente para organizar mejor su trafico y dar un mejor servicio. Eso hace que los load balancers como grippo-2014187730.us-east-1.elb.amazonaws.com vayan ocasionalmente cambiando la direccion IP.

Por lo tanto, mi idea de usar urls del tipo http://grippo.com/aviso/1234 no funcionaría junto con load balancer de Amazon. Debería usar mi propio load balancer, cosa que considero descartar, apostando a que Amazon va a manejar mejor mi load balancer que yo mismo, que pretendo deligarme de mas tareas, antes que tomar otras nuevas.

Nuevas lecciones aprendidas:

Usar CNAME de todo el dominio, solo es viable cuando no hay otros servicios como ser mails en el mismo dominio.
Sólo las urls del tipo http://subdominio.midominio.com/aviso/1234 funcionarían con Elastic Load Balancer, por lo que las urls del tipo http://grippo.com/aviso/1234 no son viables sin comprometer el servicio en momentos de sobrecarga, o sin sobrecargar al webmaster con una nueva tarea de administrador de load balancer

Cosas que pasan, extraña apariencia de Grippo.com

2009-09-03T23:10:26Z

Una de las leyes de Murphy dice, que una serie de eventos fallará en la peor combinación posible. Acaban de avisarme (Sebastián Querelos y Gabriela Maidana), que Grippo.com aparecía con esta extraña apariencia:

¿Qué pasó?

Lo primero que pensé fue esto: ¨me hackearon el sitio, por primera vez luego de 13 años".

Pero no.
Yo mismo fuí el culpable. La respuesta corta es que en el archivo de zona del DNS de grippo.com, en vez de poner un CNAME apuntando al load balancer de Grippo.com, puse una direccion IP (A). Mi proveedor, Amazon, le cambió la IP al load balancer, y ahora el load balancer de otro, está usando la IP que era de Grippo.com.

Como me siento muy culpable, no quisiera ahora también agregar este otro detalle: mi proveedor de DNS primario, tarda horas en propagar cada cambio. Asique por más que el arreglo ya está realizado, va a tardar horas en verse online.

Lecciones aprendidas:

usar un proveedor de DNS primario que te deje propagar un cambio en minutos, no hras
usar un proveedor de DNS que te permita modificar tus registros de acuerdo a tus necesidades, no las de ellos

Por razones históricas, los DNS primarios de mis dominios, estaban en www.mydomain.com, pero ahora es momento de buscar un proveedor profesional. Ya me habían recomendado ultradns.net, pero me demoré más de la cuenta en seguir esa recomendación.

Agregado el 5 Sep:

Ahora entiendo mejor.

Yo queria tener urls del tipo http://grippo.com/aviso/1234 y http://grippo.com/buscar/departamentos+en+mar+del+plata, es decir usar solo el dominio, sin www. Mi proveedor de DNS primario (www.mydomain.com), es un tipo de proveedor que permite poner CNAME del dominio completo (sin subdominio). Entonces siempre pensé que era legal. Pero en realidad yo no estaba entendiendo claramente qué significaba. Poner un CNAME en el dominio, si tu DNS primario te lo permite, es útil sólo cuando el dominio es efectivamente un alias 100% del host de destino del CNAME. De hecho, la primera semana de subirme a Amazon AWS, lo que hice fue poner algo asi como:

grippo.com IN CNAME grippo-2014187730.us-east-1.elb.amazonaws.com.

ya que ese es el nombre de mi load balancer. Al hacer eso, me quedé sin mails @grippo.com, porque no tenía caso haber configurado registros MX en mi archivo de zona de grippo.com, ya que ese CNAME invalidaba todo el resto. Tuve que averiguar entonces la IP de grippo-2014187730.us-east-1.elb.amazonaws.com, que era una hace unos dias, y es otra ahora, y convertir ese registro en

grippo.com IN A 123.45.67.89

Eso anduvo bien hasta que Amazon le cambio la IP a grippo-2014187730.us-east-1.elb.amazonaws.com. Eso trajo la pantalla extraña de esta historia. Ahora bien, siendo que uso un load balancer, ahora entiendo que está bien que Amazon me aconseje usar un CNAME apuntando a grippo-2014187730.us-east-1.elb.amazonaws.com, ya que eso hace que su load balancer sea más elástico, es decir que pueda ser redundante en caso de fallas, y derivar trafico por otros dispositivos, cuando el dispositivo original falla o simplemente para organizar mejor su trafico y dar un mejor servicio. Eso hace que los load balancers como grippo-2014187730.us-east-1.elb.amazonaws.com vayan ocasionalmente cambiando la direccion IP.

Por lo tanto, mi idea de usar urls del tipo http://grippo.com/aviso/1234 no funcionaría junto con load balancer de Amazon. Debería usar mi propio load balancer, cosa que considero descartar, apostando a que Amazon va a manejar mejor mi load balancer que yo mismo, que pretendo deligarme de mas tareas, antes que tomar otras nuevas.

Nuevas lecciones aprendidas:

Usar CNAME de todo el dominio, solo es viable cuando no hay otros servicios como ser mails en el mismo dominio.
Sólo las urls del tipo http://subdominio.midominio.com/aviso/1234 funcionarían con Elastic Load Balancer, por lo que las urls del tipo http://grippo.com/aviso/1234 no son viables sin comprometer el servicio en momentos de sobrecarga, o sin sobrecargar al webmaster con una nueva tarea de administrador de load balancer

Bilinkis entrevista a Galperín

2009-08-07T20:19:20Z

9 minutos y medio de video imperdibles.

Hoy migré la aplicación con mayor tráfico a Amazon EC2

2009-08-06T19:30:11Z

Un sueño hecho realidad, y muchas horas despierto, esperando que el desastre ocurra en cualquier momento. Pero no ocurrió nada grave. La aplicación con mayor tráfico (Clasificados Grippo), fue migrada anoche con éxito a Amazon EC2.

Dispuse un redirect de clasificados.grippo.com.ar a grippo.com que es el dominio donde se sirven ahora las páginas, para tener el mínimo de downtime posible. La aplicación estuvo fuera de línea solo 15 minutos que es lo que tardó en migrarse la database de un lugar al otro. Comprimido 0,4GB, descomprimido 2,2GB.

La capacidad tanto del MySQL server, como de los application servers (dos detrás de un load balancer) era en teoría equivalente a un procesador Intel P4 dual core, u Opteron del 2007. Así dice la doc. de Amazon. Tienen 1.7GB de RAM. Son tamaño small, luego hay medium y large. Luego hay medium high performance y large high performance, yo tengo 3 small. Asique tenía mis dudas respecto a cómo iban a responder cuando llegue el pico de 30 requests por segundo.

Finalmente, responde muy bien, y ahora puedo decir que podrian absorber hasta 300 resquests por segundo los application servers, aunque el MySQL server voy a tener que partirlo en un master donde hacer los inserts y updates, y un slave en principio para los selects para estar tranquilo y permitir que el tráfico pueda crecer sin preocupaciones. Luego ante mayor demanda la estrategia es darle mas potencia al master y agregar más slaves para los selects.

así se ven los top en los 3 servers que están en servicio en este momento. Tengo instalado munin-node que es como MRTG pero mas sencillo de instalar, que va recolectando el usage de los recursos y me los muestra en gráficos acumulando información cada 5 minutos. Por ejemplo el uso de la CPU, que debe estar por debajo de 80 el 95 por ciento del tiempo (system + user + nice) .

Conclusión: muy contento porque todo ha salido bien y no hay que dar marcha atrás. Muy pronto: adiós final al tradicional datacenter.

¿Innovación? Me acordé de Sil haciendo Al Pacino

2009-08-05T20:00:00Z

Leyendo la nota sobre innovadores de Alec, me acordé de Silvio, de la banda de Tony Soprano, imitando a Al Pacino en el Padrino III. Este es Al Pacino, tratando de salir del mundo del crimen. Pero no lo dejan:

Y este es Sil, imitándo a Al Pacino para alegrar a los otros capos:

Versión en inglés.

Un ejemplo de por qué cuesta tanto innovar a las corporaciones.

Salvando las distancias entre la mafia y una corp., se tracciona con más fuerza para mantener el status quo, que para cambiarlo.

Usá site:tudominio para encontrar problemas

2009-08-05T18:19:33Z

El comando site, sirve para restringir la búsqueda en Google a un dominio o subdominio en particular. Es decir, en vez de buscar en toda la web, busca solo en el dominio especificado. Por ejemplo, ingresando en el buscador lo siguiente:

auto site:grippo.com.ar

Sólo busca "auto" en el dominio grippo.com.ar. Ahora bien, si sólo busco:

site:grippo.com.ar

entonces obtengo información interesante. En este instante me dice que el index de Google tien 2.260.000 páginas de grippo.com.ar. Ese dato es muy variable de todas maneras, ya que Google siempre está mezclando versiones viajes del sitio con versiones más nuevas, asique oscila mucho. De todas maneras, mirando los resultados (te recomiendo entrar en preferencias y ajustar el valor a 100 resultados por página), siempre se encuentran problemas a simple vista.

Por ejemplo, páginas indexadas que no deberían estar indexadas, como ser plantillas o documentos, o listings de directorios que quedaron dentro del espacio virtual de la web. En la próxima imagen, el segundo resultado es una versión en japonés de la documentación de Apache, que descubrí indexada hace más de un mes, y todavía no lo logro:

Google había indexado otras 100 páginas en japonés, correspondientes a la documentación de Apache. Este otro ejemplo es muy triste, por alguna razón faltaban los index.html:

Muchas veces así se indexan cartas de alguna novia/o al/la cual ya no seguimos, o alguna foto comprometedora que sin querer quedó al descubierto. El comando "site:" viene en nuestra ayuda para descubrir todos esos problemas a simle vista.

¿Por qué problema y por qué SEO? Porque muchas veces con este comando site: descubrimos duplicación de contenidos. La mayoría de los programadores somos vagos, y cuando empezamos algun proyecto nuevo, tratamos de basarnos en alguno anterior que sea parecido, abusando del copiar y pegar. A medida que unos proyectos avanzan, otros siempre quedan en la cola. Mientras están en la cola, podrían estar siendo indexados por Google. Eso me pasó y acabo de descubrir 100 mil urls indexadas duplicadas. OMG.

Mi solución siempre que quiero hacer desaparecer algo de Google, consiste en:

Hacer que el http server responda "410 Gone" a todo request que quiero eliminar del index de Google.
Ir a Webmasters Tools, e incrementar la velocidad de crawling al máximo.

No ser canuto: probá ahora con tus dominios y comentá qué macana te mandaste!

La Gaceta de Tucumán tuvo que suspender sus clasificados

2009-08-04T22:43:42Z

Según se anunció hoy oficialmente, en la sección de Opinión (?), el servicio de avisos clasificados en la web de la Gaceta de Tucumán fue suspendido por un período que puede llegar hasta un mes. Yo aplaudo a la tranquilidad con la que se trabaja en ese equipo, no especialmente la gente de sistemas de quienes presupuestar tiempos en internet de esta manera no me sorprende en absoluto, sino quienes en un diario son responsables de un servicio de avisos clasificados, que tradicionalmente es una fuente de ingresos importante. Inevitablemente debo preguntarme: ¿les preocupa algo Internet?

Pareciera que no, que el negocio de los clasificados en papel es eterno.

Para otros no tan despreocupados, especialmente para quienes hace SEO, les cuento que tengo comprobado que un downtime de horas puede hacer estragos en el flujo de referers desde buscadores, imaginen lo que puede hacer un mes completo!

Parece que es obligatorio diseñar mal los llamados diarios de internet

2009-08-03T02:11:42Z

Admitamos que los "diarios de internet" es una categoría maldita desde el momento que en internet no hay nada diario, solo un continuum, como el tiempo mismo. Pero muchas veces me lo he preguntado, y ahora eso se me transformó mágicamente en una seguridad aplastante: es obligatorio que los llamados diarios estén mal construidos.

Algunas de las causas por los cuales los llamados diarios de internet están mal construidos, es el desprecio (en el buen sentido de la palabra, no piensen que andan escupiendo a nadie por ahi) que tienen por toda industria exitosa en internet. Es decir, ellos inmediatamente cuando ven algo que funciona, lo descartan porque no es adecuado, o serio, o inseguro, o no esta probado, o lo que sea. La constante, el gesto, es negarse de plano a aceptar que si algo funciona, habría que por lo menos considerarlo.

Me encuentro con esta nota hoy sobre la gripe A:

http://www.lavoz.com.ar/09/08/02/Gripe-distribuyen-guia-recomendaciones-escuelas-bonaerenses.html

Y caigo en La Voz del Interior, como pude haber caido en cualquier diario decente, que acepta a Googlebot. ¿Y qué veo? Una lastimosa imitación de una versión de Clarin com del 2005? Firmada por 451.com. Y pienso, pagarán mal? La gente de La Voz pone varios sellos abajo, muy serios: IAB, Certifica, protección de datos, en fin, lo usual. Realmente pienso que ellos, como los otros medios tradicionales, confiaron demasiado en el modo antiguo de hacer las cosas, como cuando las hacían en el papel, y desconfían en demasía de lo que se comenzó llamando la blogósfera, y ahora directamente se lo llama web dos.

Con solo tirar a la basura sus seguros, carísimos, sofisticados y ridículos CMS, y comenzar a usar herramientas tipo WordPress o Movable Type, para bloggers (así les decimos a los periodistas cuando publican en internet), sólo por nombrar dos opciones muy populares, la primera mota de nieve que puede provocar la avalancha, podría comenzar a rodar.

Subiéndome a la nube, capítulo dos

2009-07-29T21:18:37Z

A principios de este mes, publiqué el capítulo uno, donde mostraba lo sencillo que fue migrar todos los elementos estáticos a S3 + CloudFront, el competitivo costo mensual y el upgrade que significa en tecnología pasar a servir imégenes, css, js y demás, desde una content delivery network, archivando los elementos en una plataforma indestructible, quasi-eterna y 100% disponible.

Ahora bien, una cosa son elementos estáticos, y otra cosa son páginas dinámicas. Hoy les voy a mostrar cómo va la migración de la aplicación y el tipo de setup redundante que es posible / mandatorio hacer.

Esta es la consola AWS de Amazon:

Versión para chicatos. En este dashboard vemos que ya tengo 2 running instances. Cada instancia es un server completo, con 1.7GB RAM, procesador Opteron de 2007, 160GB en disco. Uno de esos servers es solo para MySQL. El otro es un worker con Apache 2 + mod_perl 2. El plan es agregar un segundo servidor MySQL que haga replicación. Y agregar un segundo apache para atender los requests HTTP, balanceados con un ELB, ó Elastic Load Balancer en la jerga de Amazon. Cada una de las instancias (recuerden, cada instancia es un server), tiene montado por nfs un volumen externo, donde los datos importantes de la aplicación, incluyendo las databases MySQL, existen en un dispositivo redundante y externo a las instancias, llamado Elastic Block Store o EBS. Esto es importante porque si la instancia se corrompe, nunca se recuperarían los datos almacenados en su propio hard disk, los datos sensibles deben almacenarse fuera de la instancia.

En resumen:

frente a los usuarios solo está el load balancer, que es un servicio que pinguea cada 30 segundos cada apache para ver si está vivo y balancea la carga entre tantas instancias como le pongamos.
detrás del load balancer hay n cantidad de instancias, cada una corriendo apache + mod_perl, en mi caso con dos instancias puedo servir mucho mas de mis 3 millones de uniques mensuales
cada aplicación realiza inserts, updates y deletes en un servidor master MySQL (que corre en su propia instancia) y todos los selects van al slave (que por supuesto corre en una instancia separada), en total hasta aca tenemos 4 instancias corriendo
todos los datos (templates, logs, bases de datos), existen en una unidad de storage externo (EBS)
en mi repositorio S3 tengo imágenes del setup particular del OS de cada rol de servidor. En mi caso uso Debian. A cada imagen la llaman AMI (Amazon Image) y contiene una imagen binaria que aplicada a una instancia nueva, instala no solo el OS sino todas las decenas de paquetes y configuraciones específicas que se necesitan para asignarlo un rol al server. Asi tengo un AMI para servidor MySQL master, otro para servidor MySQL slave, y otro para servidor Apache + mod_perl. En caso de necesitar más apaches, simplemente lanzo una nueva instancia (launch instance), y le aplico el AMI correspondiente a apache con mod_perl. Todo el proceso implica dos clicks y esperar como 90 segundos en total. Al finalizar ese procedimiento, tengo un nuevo apache que puedo agregar al load balancer y en minutos puede estar sirviendo mas requests.

De la misma manera, si se corrompe la instancia que corre alguno de los servidores MySQL, puedo en minutos tener otro con identico setup. Como las tablas de las bases de datos se montan en el volumen externo "indestructible", lo que puede ser una verdadera catástrofe, puede pasar inadvertido si se usan otras herramientas de las que voy a hablar en el futuro, que combinan un monitor con el API de AWS, y que permite automatizar el lanzamiento de instancias nuevas en caso de necesidad.

Como yo vengo de hacer todo con el destornillador en la mano, esa mejora la dejo para más adelante, aunque es inevitable caer en automatizar todo al punto de por ejemplo, mantener dos apaches de lunes a viernes, pero sabados y domingos cuando la demanda baja, mantener solo un apache y pagar menos.

Bueno, ¿cuanto cuesta todo esto? Como dije en la nota anterior, mi interés en compartir esto es que aún habiendo conocido AWS hace años, siempre me pregunté efectivamente cuán viable era para un sitio como grippo.com. Pues bien, es mucho más viable que mantenerlo en un datacenter de clase mundial en Buenos Aires, eso se los puedo asegurar, porque mientras esté en el datacenter de clase mundial, sea en Buenos Aires, Los Angeles, Londres o donde sea, siempre llega el momento fatídico del downtime, como me pasó hoy mismo, o llega el momento que con destornillador en la mano tenemos que cambiar una fuente que dijo basta, o agregar mas pizzas al horno (sevidores en el gabinete).

Si bien falta un día o dos para cerrar el mes de julio, con aproximadamente USD 100, estoy cubriendo toda la operacion de storage S3 (22 centavos) + CloudFront (mi propia CDN para 30 y pico millones de requests por 38 dólares) + EC2 (Elastic Computing Cloud, 60 dolares más). EC2 incluye el uso de dos instancias por el momento. Estoy a punto de lanzar dos instancias nuevas, así para finales de agosto puedo mostrar el costo total de infraestructura de grippo.com. El desglose de EC2 es muy pormenorizado:

Para chicatos. El primer item que figura con USD500, es para reservar una instancia. Si la instancia no está reservada, pago USD 0,10 por hora. Eso es lo mejor para instancias lanzadas por demanda, digamos una aplicacion que tiene mucho trafico de 9 a 17 de lunes a viernes, en esos momentos usamos instancias sin reserva y pagamos 0,10 por hora. En mi caso, necesito una base de 4 instancias para mi setup, puedo reservar 4 instancias a USD500 cada una por tres años, y durante esos tres años, pago USD 0,03 por hora, el costo de cada server en este caso es de menos de USD 500 anual! Sí leíste bien, anual. Si no es reservado, pagás algo más de USD 700 anual, claro en el caso de que lo estes usando todo el tiempo, que no sería el caso jamás, porque en ese caso lo convertirías a reservado.

Luego tengo USD 32 por mil y tantas horas de instancias a 0,03. Esas son las dos instancias que ya tengo corriendo, una con MySQL, la otra con Apache.

Luego viene el costo por bandwidth. Debo aclarar que tengo migrados sitios pequeños, que en su conjunto pueden tener 5 mil usuarios por día, como por ejemplo da.com.ar, grippo.co.il, grippo.es, horoscopo.grippo.com. Asique el bandwidth me cuesta centavos. El bandwidth que va a consumir el mes que viene puede llegar a 50GB mas o menos, la espectativa de costo de este item no superaría los USD 10.

Luego viene EBS, que es el storage externo, attacheable a las instancias. Es decir donde se guardan todos mis datos sensibles, incluyendo las bases de datos y de la que puedo programar un backup instantáneo que se realice cada hora si quiero, y que se almacene en mi repositorio S3. Sólo por esto conviene pasarse a AWS. Sólo por EBS y Snapshots.

Luego vienen las EIPs, elastics IP, que si las uso, no me las cobran. Sólo me cobrarían USD 2 mensual si las reservo pero no las asigno a ninguna instancia.

Luego viene CloudWatch que es un monitor que permite automatizar las respuestas a la demanda, que hablaremos en un futuro cercano.

Luego viene el load balancer, que cuesta 18USD mensual. Como en mi setup los apaches pueden responder a todas las aplicaciones, uso solo un load balancer, y pongo detras tantos apaches como sean necesarios de acuerdo a la demanda.

Espero que no sea muy confuso esta vez, hay muchos conceptos aqui adentro, cada uno voy a tratar de explicarlos por separado, pero lo central aquí es que grippo.com siendo uno de los 10 sitios nacionales con mayor tráfico y difícilmente llegue a superar los USD 200 mensuales en agosto, migrando el 100% de los servicios a Amazon.

Dicho de otra manera: cualquier start up podría reservar USD 100 mensuales y tener un setup indestructible y escalable al nivel de google, yahoo o amazon. Quizás era un tema que podía incidir mucho más en el presupuesto mensual, pero ya no.

Dicho de otra manera: qué se puede hacer con USD200 en un datacenter en Argentina?

Dicho de otra manera: cuál es el presupuesto de servidores más conectividad de los otros 10 sitios nacionales de mayor tráfico? Creo que cada uno se podría optimizar.

En cualquier caso, aclaro que no soy socio comercial de Amazon, simplemente su AWS es genial, y yo tardé como 4 años en comprobarlo.

Feedback please!

Downtime de Clasificados Grippo

2009-07-29T19:42:25Z

A días de migrar clasificados Grippo a Amazon, hoy Skyonline se cayó casi dos horas:

¿Cuánto valor se pierde en un downtime? Muchísimo, lo se por experiencia. Si algo así ocurre mientras freshbot de Google está crawleando activamente el sitio, puede interpretar que el sitio no tolera tráfico alto, y degradar todos los resultados de búsqueda para "cuidar" al sitio en cuestión del fenómerno conocido como Efecto Shlashdot. No es mi caso, pero ha sucedido. En 48 horas se sentiría en la cantidad de referers desde Google.

El problema aparentemente fue en la red interna. Algun router, firewall o algo asi.

Hubo años enteros en los que no hubo una sola falla, pero desde hace 3 años cada tantos meses, incidentes de downtime de horas, no son infrecuentes.

Los servidores estuvieron operativos todo el tiempo, pero sin conectividad. Lo siento, no depende de mi. Un incidente como este te deja inmóvil esperando que se solucione mágicamente. En cambio en Amazon AWS, si bien es probable que un incidente similar ocurra en una de las zonas (datacenter), es improbable que ocurra en las 4 zonas al mismo tiempo, siempre hay otros tres datacenters que te asisten. Si llegara a ocurrir ese hecho tan improbable, también amazon.com estaria caído. En años nunca ocurrió.

Traducción de chats con Google Talk y Google Translate

2009-07-28T16:25:34Z

En esta nota de Aeromental, nos explica detalladamente cómo usar Google Translate para chatear en cualquier idioma. Google Translate se encarga de traducir en la línea, todo lo que escribimos en nuestro idioma, al idioma de quienes están chateando con nosotros. Cool.