Post on 29-May-2015
description
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