7. Metodología - Introducción
Desarrollo en nubes IaaS
Como un hosting avanzado
Desarrollo tradicional
Desarrollo en nubes PaaS
Alta escalabilidad y distribución
Hosting escalable como commodity
Google App Engine: a favor y en contra
"Cambios" en Scrum
8. Metodología - Limitaciones
Peticiones limitadas a 30 segundos de tiempo real
Se solucionan con cron y cola de tareas
Alta distribución en la ejecución de peticiones
Peticiones de la misma sesión pueden ser ejecutadas
en distintas máquinas
La sesión tiene que ser serializable y no puede ser sticky
Se persiste en la cache de GAE
White list del API de Java
La base de datos es no-SQL (DataStore)
9. Metodología - Rendimiento
Cola de tareas: API experimental
Se crean tareas desde las peticiones de clientes
Se implementan como cualquier otra petición HTTP
Todavía limitado a 30 segundos, pero lo van a cambiar
Servicio memcache
Cacheo agresivo de datos distribuido
Con timeouts y control de recursos
Implementa el API JSR 107 pero también hay otro de
bajo nivel
Control concurrente similar a ConcurrentHashMap
10. Metodología - SQL vs No-SQL
Ryan Barrett - Google I/O 2008
Dense scan index
Range scan
Entity groups & ancestors
Merge joins
!=, IN, AND, 3 reglas, MVP
joins, OR
unset, nonindexed properties
GAE Business
11. Metodología - Manejo de la sesión
Tiene que ser serializable y no hay sticky session
Se esta evaluando la posibilidad de sticky
Cuanto menos estado tengamos en sesión mejor
Dificultad en desplegar frameworks centricos en servidor
JSF, Vaadin, ZK, ...
Mejor usar Struts, WS, REST o servlets RPC
Mejor usar frameworks centricos en cliente
GWT, jQuery
12. Metodología - Pruebas en servidor
Mike Cohn
http://code.google.com/p/kotori/wiki/KotoriWebJUnitRunner
13. Metodología - Pruebas en cliente
Ejecución complicada por depender del navegador
Soporte JUnit para GWT: pero lento, muy lento
Se propone usar el patron MVP
P
M C V V2
1
SERVIDOR
CLIENTE
TESTABLE NO TESTABLE
17. Metodología - Versionado
GAE permite tener accesibles varias versiones de la misma
aplicación
Existe una privilegiada: la versión por defecto
Se puede usar como entornos: dev, pre, pro, ...
Se puede usar como entornos de cliente
Se puede usar como versiones funcionales: 1.0, 2.0, ...
Permite realizar experimentos de UI
Hay que tener cuidado con la sesión: se puede serializar en
una versión anterior y despertar en la nueva
18. Preguntas habituales
1. ¿Hay que hacer algún cambio fundamental (y cuáles) en Scrum para que
se adapte bien a proyectos hechos para entornos de cloud computing?
2. ¿Cómo hacer TDD, pruebas automáticas, integración continua y demás
prácticas de XP en estos entornos? ¿Hay buenas prácticas para estos
entornos que no sean aplicables a entornos más tradicionales?
3. ¿Cómo afecta al diseño emergente el que se usen bases de datos no
relacionales?
4. La aplicación se acopla a la plataforma elegida y después es muy difícil
cambiarlo.
5. No tengo control sobre la infraestructura, rendimiento, etc.
6. Son tecnologías nuevas, mi gente no sabe de ellas, etc.
7. Hay que hacer pruebas de rendimiento, carga, etc., aunque el entorno
utilizado supuestamente se encargue automáticamente de escalar.
8. Las aplicaciones y datos en la nube no son seguras, no se que pasa con
ellas.