De cero a multinacionalcon Grails y EC2

Eloy García-Borreguero – Grupo EvandtiJorge Uriarte – Gailen Tecnologías

Un vistazo atrás

Pidiendo consejo

de Java a Grails...

de Java a Groovy

Idioms, conceptos, aprendizaje...

Rendimiento, profiling...

Cuidado con el diseño...

¿Por qué Grails?

● Promesa de productividad● Amortización de experiencia Java● Integración empresarial● Plataforma JVM conocida● Plugins

¿Por qué Grails?

● Promesa de productividad● Amortización de experiencia Java● Integración empresarial● Plataforma JVM conocida● Plugins

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

Alternativas

● Java / Spring / ...● Rails● PHP● ...

¿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”

¿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”

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

Alternativas a EC2 en 2009

● Hosting “tradicional”● PaaS: GAE, ¿Otros?● No mucho más...

Decidido: Grails & EC2

Desarrollo inicial

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.

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

Echábamos de menos...

● Sistema de workflows: Varias opciones, ninguna madura, ninguna bendecida.

● Terminamos por inventar nuestra propia, pequeña rueda: “grails-fsm-plugin”

Nuestro primer plugin - fsm

La iluminación de los plugins

● Aspectos, comportamientos, extensiones...

● DSLs específicos...● Integración de librerías

Internacionalización - Idiomas

I18n estándar + Spring

● Vistas● Bundle● Lógica específica de país/idioma

I18n estándar + Spring

● Vistas● Bundle● Lógica específica de país/idioma

...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?

Nuestro segundo plugin: i18n-fields

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

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)

Internacionalización - escalabilidad

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”

Palancas para “pasar nivel”

● Terracotta● Integración de Springcache● Cloudfront

Evolución de la arquitectura en EC2

Explotación – Operación● WAR único● Script centralizado orquestando despliegue

● Cambio de modelo -> Limpieza TERRACOTTA

● Breve downtime:● Despliegue gradual● Mirror del entorno● AWS Beanstalk

El futuro

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

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

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

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

¿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

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

¿conclusiones?

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