Presentación hecha en la reunión 22 de SpringHispano y Grails.org.mx, donde hablo acerca de un proyecto donde se uso Grails para la totalidad.

1. De cero a 1.7 M de usuarios
Grails, opción real para sitios web de alta carga y escalabilidad.
Una experiencia al crear la más grande
plataforma de eCommerce con Grails en Latinoamérica.

2. Agenda
• Negocio
• Diseño inicial
• Infraestructura
• Problemas
• El futuro

3. Negocio
Una tienda en linea, con una amplia
y creciente gama de servicios y productos

4. Negocio
• Ventas en grupo
• Cupones.
• Pero no solo cupones...
• Campañas de email masivas.
• Campañas de publicidad masivas.

5. Diseño inicial
Grails, Terracotta, RabbitMQ & mySQL

6. Grails
• Grails 1.3.4
• GORM
• Servicios
• Controllers y TagLibs
• Jobs

7. GORM, lo bueno
• Facilidad de crear modelos
• Modelos ricos
• Consultas
• Criteria
• DynamicFinders
• Actualización del esquema de base de datos

8. GORM, lo malo
• No es posible probar DynamicFinder y Criteria de forma
unitaria
• Pruebas integrales, a veces toma mucho tiempo
• Es sencillo cometer errores debido a la facilidad
• Olvidar crear indices
• Iterar grandes colecciones
• Dejar que Grails nombre relaciones (tablas o campos)

9. Servicios, lo bueno
• Lógica de negocio
• Servicios que “escuchan” eventos
• Extensivo uso de Dependency Inyection
• Composición, agregación
• Reglas de negocio flexibles

10. Servicios, lo malo
• Abusar de Dependency Inyection
• Referencias circulares
• No es tema de Grails exclusivamente, con Spring
se presenta también.
• Duplicar nombres de Servicios, en diferentes
paquetes
• Olvidar quitar la administración transaccional cuando
no es necesaria.

11. Controllers, lo bueno
• Ridículamente simple
• Generar JSON/XML es trivial
• Reglas de mapeo, muy sencillo y flexible
(URLMappings)
• Totalmente desacoplado de la vista

12. Controllers, lo malo
• Nada

13. TagLibs, lo bueno
• Estúpidamente simple crearlas :)
• Apoyo de Dependency Inyection para
acceder a servicios, o a cualquier
componente.
• Condicionar la generación de contenido
• Llenar plantillas (fragmentos de una página)

14. TagLibs, lo malo
• Usarlas como scriptlets

15. Grails, en general
• Permite que un desarrollador Java, explote su
conocimiento.
• Aumenta la productividad debido a el uso de
“Convención sobre Configuración”
• Incrementa brutalmente la facilidad de
convertir requerimientos de negocio en
código ejecutable

16. Grails
• En mi humilde opinión, la mejor opción para
desarrollo web en Java, de cualquier tamaño
o requerimiento
• Disclaimer: Es solo mi experiencia personal,
no puedo garantizar el mal uso de Grails.
También puedo equivocarme. Es mi punto de
vista como desarrollador.

17. Negocio
• En Agosto de 2010 @dvd2k5
me dijo:
• Hey domix; en un año
tendremos un millón de
usuarios
• @domix
• :O

18. Escalabilidad y
Disponibilidad
Vitales para estar en un negocio muy competitivo

19. Terracotta
• Cache distribuido
• Evitamos accesos a la BD
• Guardamos Objetos Java y HTML
• Entidades de Hibernate
• Páginas completas
• Fragmentos de páginas

20. Terracotta
• Usamos EhCache como “fachada”
• En desarrollo no usamos Terracotta
• En producción y QA configurado
• El código aplicativo no se ve modificado

21. Terracotta
• IMHO, es una de las mejores piezas de software
jamas escritas en Java
• Robusto, Estable
• Confiable, Ligero
• Casi cero administración
• Configuración muy sencilla
• Uptime de meses en producción

22. Terracotta
• Lo usamos para clusterizar sesiones HTTP,
pero no quedo productivo
• No quería cargar con mas trabajo a Terracotta
• Evitar tener un solo punto de falla
• También lo usamos muy poco tiempo para
clusterizar Jobs con Quartz

23. RabbitMQ
• Servicio de mensajería
• Diferente a JMS
• Escrito en Erlang
• Muy robusto, estable
• Casi cero administración
• Desarrollado por vmWare

24. RabbitMQ
• Procesamiento asíncrono
• Procesos muy tardados
• Envío de email
• Consultas pesadas (reportes financieros)
• Integración con otras aplicaciones

25. RabbitMQ, lo malo
• No hay muchas herramientas de
administración/monitoreo
• Las que hay son poco “amistosas”
• Cuando falla, falla muy duro
• Los logs de error son como Hebreo antiguo o
mas bien como lenguaje Orco.

26. RabbitMQ, lo malo
• No hay muchas herramientas de
administración/monitoreo
• Las que hay son poco “amistosas”
• Cuando falla, falla muy duro
• Los logs de error son como Hebreo antiguo o
mas bien como lenguaje Orco.

27. RabbitMQ, nada malo
• Antes he usado varios servicios de
mensajería
• Todos ellos basados en Java
• RabbitMQ ha sido al que he visto que se le ha
puesto una carga muy grande, sin necesidad
de afinar la configuración.
• IMHO. La mejor opción.

28. RabbitMQ, nada malo
• Antes he usado varios servicios de
mensajería
• Todos ellos basados en Java
• RabbitMQ ha sido al que he visto que se le ha
puesto una carga muy grande, sin necesidad
de afinar la configuración.
• IMHO. La mejor opción.

29. mySQL
• ¿que puedo decir?

30. mySQL
• Tenemos instalada una versión “tuneada” por
RackSpace
• Una palabra para describirla: Impresionante
• He vivido engañado por muchos años.
• Un pequeño comportandose como nunca he visto
un grande.
• Nuestro mySQL ha soportado +15 millones de
queries en un día

31. Infraestructura
2 versiones

32. Cajas Versión 1
• 2 WebServers
• 1 Tomcat 6 con AJP = cluster de 2 Tomcats
• Apache HTTPD con mod_proxy
• 1 DBServer
• 1 Firewall físico
• 1 LoadBalancer físico
• Rackspace Londres

33. Cajas Versión 2
• 4 WebServers
• 2 Tomcat 6 con AJP = cluster de 8 Tomcats
• Apache HTTPD con mod_proxy
• 1 DBServer
• 1 Firewall físico
• 1 LoadBalancer físico

34. Fierros Versión 2
• Dual Quad Core Xeon 2.26 HGZ
• 24 GB de RAM
• 300 GB SAS X 3
• RedHat Enterprise Linux 5.6
• En Hospedaje dedicado en Rackspace
Chicago

35. Problemas
• Quartz Jobs clusterizados
• Ahora corren en una instancia propia
• Indices faltantes en la base de datos
• Consultas muy mal escritas
• Mala configuración del log

37. Solucionar problemas
• Necesitas métricas, indicadores
• Medición
• ¿Profiler?
• ¿JMX?

39. Competitividad
Datos de Alexa.com del día 21 de Octubre de 2011

40. ¿Como lo logramos?

42. Negocio
• En Septiembre de 2011
@dvd2k5 me dijo:
• Hey domix; en un año
tendremos 5 millones de
usuarios
• @domix
• :O

43. Estrategia actual y futura
• Hacer la webapp actual lo mas estática posible
• Modularizar la aplicación en un conjunto de
servicios
• Usar mensajería para comunicarlos
• Usar Scala como lenguaje complementario a Groovy
• Akka para procesamiento asíncrono
• MongoDB como almacén secundario
• Redis como cache recundario

44. Estrategia actual y futura
• Convirtiendo los servicios en un API Rest
• clickOnero móvil iOS este año
• clickOnero móvil Android próximo año
• Facebook App próximo año
• Apertura del API próximo año

45. El equipo

46. ¿Preguntas?

47. Créditos fotos
• http://flic.kr/p/e61Pt • http://flic.kr/p/2wGvZi
• http://flic.kr/p/7cxoek • http://flic.kr/p/7jLN6x
• http://flic.kr/p/5vSqgq • http://flic.kr/p/2VvzMw
• http://flic.kr/p/6K9jb8 • http://flic.kr/p/9c7z9T
• http://flic.kr/p/6h8UoU • http://flic.kr/p/J1NKm
• http://flic.kr/p/24GsCj