J’ai juste fait de la config. pour porter sur Azure

Xavier

D’experience, par amis proches, une startup c’est entre 2 ans et 5 ans pour vraiment voir si ca marche, voire se faire racheter.

Sinon, s’il te reste quelques minutes parfois, n’hesite pas à nous donner des exemples ou tu trouves Groovy/Grails avantageux par rapport à du Java (genre du Spring MVC…).
Pense aux stagiaires qui vont bosser avec toi bientot! (d’experience aussi (et qui connaissent java, jsp, …)

Merci en tous cas de nous raconter tout ça, ca fait plaisir de partager tes experiences.

Gilles S

Je monterai bien ma startup mais j’ai pas envie de m’isoler. L’ambiance bureau avec des collegues mais sans être salarié d’une boite.

Mais je connais pas les adresses où c’est possible de faire ça?

Merci

Par contre (je n’ai pas été précis), je pensais plus aux casse-têtes de migration liés à la db, si c’est une db relationnelle que tu comptes utiliser.

Imaginons que ce soit le cas. Tu es dans une situation version « A »

user -> appA -> db A

Tu fais un refactoring sur ton modèle objet hibernate, qui demande plus qu’un ajout de colonne, mais un changement plus sérieux (relations modifiées, champs déplacés…). Partons du principe qu’on ne fasse pas les alter table à chaud sur dbA (ou alors sans moi ) et qu’on utilise la virtualisation au max (donc comme tu disais, préparer les environnements « nouvelle version » sur le côté)

Je sais, j’aborde le problème sous une vue fort data-centric/database-driven, alors qu’avec Hibernate, nous sommes habitués à réfléchir en entités/objets, où la db n’est qu’un accessoire (certes important, mais pas décisif pour le design). Néanmoins, dans le cas de ce problème, je pense qu’il faut retomber sur le plus bas niveau.

Nous devons donc passer dans une situation :

user -> appB -> dbB

(nouvelle(s) image(s) amazon)

sans que le user s’en rende compte (0 downtime). Alors d’accord, Amazon te permet de le rebasculer sur appB. Mais appB ne fonctionnera (et démarrera) que si dbB est ok.

Or dbB doit comporter toutes les données de dbA, histoire que l’utilisateur retrouve les données qu’il vient de persister il y a 5 secondes.

Donc, cela implique une synchro, un « messaging » continu entre dbA et dbB, autre que de la réplication par défaut, puisque la structure a changé pour que dbB soit à jour et donc prête à être mise en service.

(à vérifier, peut-être possible avec de la réplication, mais je ne suis pas expert db et aucune envie de le devenir).

C’est tout à fait faisable mais je trouve cela extrêmement compliqué et risqué…

Je rajoute une petite dose encore au-dessus de tout ça : la bonne pratique de releaser régulièrement, que je n’hésite pas une seule seconde à conseiller et mettre en place, implique donc plus de migrations à effectuer…donc plus de risques de corrompre le bazar :-S

Je suis moi-même occupé de travailler sur un projet de ce type, où la production tournera sur amazon, mais avant d’y arriver, j’essaie d’estimer les plus gros obstacles afin de définir un mode opérationnel relativement « tranquille » et n’impliquant pas trop de risques, afin de ne pas passer ma vie sur le cloud

Mais peut-être suis-je trop pessimiste et est-ce plus simple que ça en a l’air (ce serait une première…)

Maintenant, si tu vas vers des db schema-less, le problème ne se pose pas (encore que…c’est la théorie). Cependant, le choix sql / nosql est loin d’être un choix noir ou blanc, contrairement à ce que les protagonistes d’un camps ou l’autre voudraient nous le faire croire. Mais ça, c’est un autre débat…

Dans tous les cas, que la carte bleue soit avec toi !

Pour info, je suis tombé sur ceci,

http://blog.apokalyptik.com/2006/09/05/mysql-on-amazon-ec2-my-thoughts/