Soy arquitecto de software en el Centro de Software de Intel en Cordoba, Argentina. Arquitecto y desarrollador en lenguajes C/C++, Java, Perl y Python. Mi trabajo es hacer que los sistemas que desarrollamos para correr en el Cloud tengan muy buen tiempo de respuesta con el mayor throughput posible por servidor (unidades de trabajo procesadas por unidad de tiempo) y que puedan escalar horizontalmente cuando el sistema recibe mayor carga. Es decir, cuando aumenta el numero de usuarios accediendo a un sistema y la capacidad existente no es suficiente para soportar la carga, se puede agregar mas servidores, preferentemente virtuales, en las diferentes capas de aplicacion y presentacion asi aumentando linealmente la capacidad del sistema para soportar la carga que recibira. Algunos sistemas tambien pueden escalar en la capa de datos, en la base de datos, dependiendo de como hayan sido disenados. Hay sistemas que por limitaciones en la arquitectura y/o diseno, por mas que se agregue mas servidores no pueden escalar. Cuando esto pasa una empresa estara limitada en las posibilidades de soportar mayor cantidad de usuarios concurrentes en su pagina o servicio web.
Mi Linkedin: http://www.linkedin.com/pub/rodolfo-kohn/0/32/310
Bueno, me decidi a comenzar este blog despues de intentar acceder a las paginas de Fravega, Garbarino, Walmart, Easy, Falabella y otros sitios de tiendas en Argentina y estar cuatro horas esperando para poder comprar algun producto sin exito alguno. Hasta hace un tiempo siempre me he quejado de la pagina de Ticketek que se traba cuando se realiza la venta de entradas de un evento muy solicitado. Hoy me doy cuenta que son muchas mas empresas las que tienen el mismo problema. Esto sucedio el 2 de Diciembre de 2013.
Escribo por cuenta propia, en base a mi experiencia y conocimientos en el area de cloud computing, especialmente en sistemas que pueden escalar horizontalmente, con buena performance y con alta disponibilidad (de 3 9’s para arriba). Mi opinion no representa la opinion de la empresa en la que trabajo y es puramente personal.
Si a alguien le ponen la excusa de que fueron demasiados usuarios tratando de acceder al mismo tiempo, que sepa que esa excusa es invalida y que las fallas que tuvo el sistema durante el Cyber Monday se debieron a uno o mas de los siguientes motivos:
- El sistema tiene fallas de arquitectura y diseno que le impiden escalar de manera horizontal. Aqui la unica posibilidad es agregar hardware o un server de mayor capacidad pero esta posibilidad es limitada y ademas exige downtime.
- El sistema tal vez puede escalar en las capas de aplicacion y presentacion pero presenta un cuello de botella en la base de datos o un sistema externo que no fue detectado por falta de un analisis adecuado de escalabilidad.
- Nadie sabia cuantos usuarios puede soportar el sistema con una infraestructura estatica existente.
- Nadie sabia cual es el perfil de escalabilidad del sistema. Es decir, cual es la secuencia de cuellos de botella a medida que se agrega maquinas.
- El sistema corre sobre una infraestructura fisica y no hubo prevision de que se necesitaria mas servidores.
- Nadie se ocupo de hacer un analisis de la performance del sistema para entender cuantos usuarios el sistema podria soportar y en que momento se debe tomar medidas para aumentar la capacidad.
- Nadie se ocupo de analizar como se comporta el sistema bajo carga extrema (stress test). Un test de stress puede detectar errores complejos tales como race conditions, deadlocks, memory leaks, uso ilimitado de recursos, etc.
- Nadie analizo el comportamiento tipico de un usuario que accede a la pagina para hacer una estimacion de la carga que podria llegar al sistema tanto en situaciones normales como en un evento especial tal como el Cyber Monday. Yo los llamo normal situation y burst situation.
Sea por el motivo que sea tanto clientes de la empresa, como desarrolladores y gerentes tienen que saber que son todos problemas que pueden resolverse. En un diario lei que alguien decia que en una hora se hizo la misma cantidad de compras que las que normalmente se hace en un dia. Eso no es excusa. Cuanta carga mas recibio el sistema? 10 veces mas? 20 veces mas? Cuanto es esto? 10, 100, o 1.000 veces mas? que burst maximo podia tolerar el sistema?
Es entendible que somos nuevos en Cyber Monday pero deberiamos ser capaces de reaccionar, corregir errores y preparar nuestro sistema para que pueda escalar en estos eventos. De lo contrario afectaremos el negocio de la empresa impidiendole ganar mas dinero, impidiendo el acceso a nuevos mercados, afectando negativamente su reputacion y ayudando a la competencia a ganar mas clientes que pasan de la pagina de nuestra empresa a la pagina de ellos. El efecto negativo en la reputacion es viral ya que los clientes disconformes suelen compartir su frustracion con otras personas y muchos publican su experiencia en algun blog o en los comentarios de un diario u otro site conocido.
El siguiente es un estudio que Gomez Networks, hoy Compuware, envio a realizar sobre los efectos que tiene un site que no responde adecuadamente en momentos pico o situaciones de burst.
Algo que muchas veces pasamos por alto es que los momentos de burst son justamente los casos en que los usuarios pretenden gastar su dinero en compras. En general gran parte de su presupuesto para estas compras, se gasta en estos momentos.
En nuestro Cyber Monday muchos usuarios se encontraron con esta imagen:
La peor pagina de todas fue la de Walmart. Fue imposible acceder en todo el dia lunes:
Tal vez las paginas que mejor estuvieron, aunque con algunas fallas cada tanto, fueron las de Compumundo, Ribeiro y Falabella. Probablemente la mayoria de los que querian gastar su dinero durante el Cyber Monday, lo hicieron en estos comercios. Es de esperar que para proximos eventos los departamentos de sistemas de estas empresas solucionen los problemas encarando los 8 puntos arriba mencionados.
Si lo deseas puedes contactarme via el siguiente form o puedes dejar un comentario con tu opinion. Sera un gusto discutir sobre este topico. Desde ya muchas gracias por tu feedback.
Software Argentino 
Muy buen blog
Muy buena idea, deberiamos poner mas esfuerzos en que nuestros sistemas escalen