Transparencias de base de la charla en Spring I/O 2011 sobre el recorrido tecnológico del proyecto http://www.ticketbis.com desde su concepción hasta su despliegue internacional. Escalabilidad de la arquitectura, de la plataforma de desarrollo, etc...

1. De cero a multinacional
con Grails y EC2
Eloy García-Borreguero – Grupo Evandti
Jorge Uriarte – Gailen Tecnologías

5. Un vistazo atrás

6. Pidiendo consejo

7. de Java a Grails...

8. de Java a Groovy

9. Idioms, conceptos, aprendizaje...

10. Rendimiento, profiling...

11. Cuidado con el diseño...

12. ¿Por qué Grails?
● Promesa de productividad
● Amortización de experiencia Java
● Integración empresarial
● Plataforma JVM conocida
● Plugins

13. ¿Por qué Grails?
● Promesa de productividad
● Amortización de experiencia Java
● Integración empresarial
● Plataforma JVM conocida
● Plugins

14. Riesgos
● ¿Rendimiento? ¿Penalización de groovy y
capas extra?
● Estabilidad de la base de código (v1.0.x -> )
● Salud de la comunidad, soporte, plugins...
● Curva de aprendizaje

15. Alternativas
● Java / Spring / ...
● Rails
● PHP
● ...

16. ¿Por qué EC2?
● En uso en sistemas internos, desarrollo,
preproducción desde 2008
● Diferir la decisión de “cuántos hierros comprar”
● “Autoservicio instantáneo” vs. “problemas de
aprovisionamento”
● Control absoluto vs. “Platform as a Service”

17. ¿Por qué EC2?
● En uso en sistemas internos, desarrollo,
preproducción desde 2008
● Diferir la decisión de “cuántos hierros comprar”
● “Autoservicio instantáneo” vs. “problemas de
aprovisionamento”
● Control absoluto vs. “Platform as a Service”

18. Riesgos de EC2 en 2009
● ¿Rendimiento y estabilidad?
● “pequeño cliente en gran proveedor”
● Servicios en evolución (¿load balancer, sticky
sessions, persistencia de instancias, clustering,
...?)
● ¿Caro? Alquiler vs Compra

19. Alternativas a EC2 en 2009
● Hosting “tradicional”
● PaaS: GAE, ¿Otros?
● No mucho más...

20. Decidido: Grails & EC2

21. Desarrollo inicial

22. Desarrollando en 2009
● Se inició el desarrollo con la versión 1.1
● Productividad aceptable
● Aspectos de inmadurez (recarga en caliente,
soporte de pruebas, bugs con namespaces,...)
● Carencia de un blueprint de arquitectura
estándar. Hubo que improvisar.

23. Desarrollando en 2009
● Soporte de IDEs “inmaduro” y “lento”
● Herramientas de apoyo no satisfactorias o no
adaptadas del todo (formato, QA, profiling, ...)
● Buenas sensaciones de la evolución del
producto, nuevas versiones, bug-fixing y
workarounds

24. Echábamos de menos...
● Sistema de workflows: Varias opciones,
ninguna madura, ninguna bendecida.
● Terminamos por inventar nuestra propia,
pequeña rueda: “grails-fsm-plugin”

25. Nuestro primer plugin - fsm

26. La iluminación de los plugins
● Aspectos,
comportamientos,
extensiones...
● DSLs específicos...
● Integración de librerías

27. Internacionalización - Idiomas

28. I18n estándar + Spring
● Vistas
● Bundle
● Lógica específica de país/idioma

29. I18n estándar + Spring
● Vistas
● Bundle
● Lógica específica de país/idioma

30. ...pero echábamos de menos...
● Internacionalización del dominio de la
aplicación
● Cómo pasar entidades del sistema a multiples
idiomas
● ¿Modificar todas las capas, desde BD hasta
accesos a atributos en vistas?

31. Nuestro segundo plugin: i18n-fields

32. Nuestro segundo plugin: i18n-fields
● Más complicado si quieres actuar antes de que
GORM/Hibernate hagan su magia
● Primer uso serio de las transformaciones AST
de Groovy
● Sensación de potencia (y algo de miedo)
● Éxito final, transición suave sin cambios en
código cliente

33. Dudas que todavía teníamos
● ¿Va a haber problemas con el despliegue en
Amazon EC2?
● ¿Podemos usar herramientas que nos faciliten
la vida?
● ¿Soporte a avalanchas de usuarios?
– Caché de páginas “ad-hoc” vía OSCache (vs . EHCaché
en GORM)

34. Internacionalización - escalabilidad

35. Problemas en EC2 en 2009
● Falta de “sticky sessions” en balancer (ELB)
● Falta de soporte multicast para clustering
● Problemas https en ELB
● Demasiado trabajo “a mano”

36. Palancas para “pasar nivel”
● Terracotta
● Integración de Springcache
● Cloudfront

37. Evolución de la arquitectura en EC2

45. Explotación – Operación
● WAR único
● Script centralizado orquestando despliegue
● Cambio de modelo -> Limpieza TERRACOTTA
● Breve downtime:
● Despliegue gradual
● Mirror del entorno
● AWS Beanstalk

48. El futuro

49. 2 años después...
● El desarrollo es mucho más estable y
productivo
● El soporte de IDEs ha mejorado mucho
● Migraciones indoloras desde 1.1 hasta 1.3.x
● Existe un “core” de plugins estable que mejora
la plataforma

50. 2 años después...
● Aún es un infierno recargar clases de dominio
● Mucha magia sigue siendo secreta y poco
documentada
● Insuficientes herramientas de soporte aún
● Sorpresas agradables (Spock, remote-
control, ...)

51. Ya no sabría vivir sin...
● Generación de XML es mágica, crítico para
integración con sistemas externos
● Sintáxis “semi-funcional” muy potente
● Magia incluída en el lenguaje
● Inyección e integración de librerías en el
lenguaje vía DSLs

52. Problemas de diseño
● Peter ya nos lo advirtió...
● Tendencia a modelo anémico, con lógica en
torno a clases de “Servicio”
– Fomentado por que el dominio no recarga en caliente
– Inducido por la propia literatura
– Problemas en inyección de dependencias al dominio
– Es algo que se puede combatir/revertir

53. ¿Rendimiento?
● Grails/Groovy nunca han sido el problema
● Tuning de BBDD y app sigue siendo la clave
● Tuning de JVM y de los GC – Peor que JEE
● Groovy sí ha sido un problema en esto
● Las grandes caché en Java son todo un reto

54. 2 años después...
● Estabilidad incuestionable
● Rendimiento bueno
● Evolución continua
● Servicios que surgieron “por el camino”:
● LBS (+https, +sticky), RDS, Cloudfront, Email
● Cloudwatch
● Beanstalk

55. ¿conclusiones?

56. http://www.ticketbis.com http://www.gailen.es http://www.eventbis.com
http://www.gailen.es http://www.ticketbis.com http://www.eventbis.com