Charla del SpringIO 2011 junto con Jorge Uriarte en la que contábamos los primeros pasos de la parte técnica de Ticketbis.

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, remotecontrol, ...)

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