Un livre blanc qui recense les bonnes pratiques des acteurs du web:
de la culture devops aux architectures big data/nosql en passant par le déploiement continu, l'organisation des équipes et la conception d'api ouvertes à l'extérieur

Pour le télécharger sans s'enregistrer: https://julien.mailleret.fr/pub/octo-les-geants-du-web.pdf

Recensement des design patterns existantes pour AWS.

Dans le même genre:
http://www.cloudcomputingpatterns.org/
http://cloudpatterns.org/

Méthodologie pour construire des applications faites pour une utilisation de type cloud:

• 1 application = 1 repository de code et 1 seul
• toutes les dépendances doivent-être explicites et fournies avec l'application
• la configuration doit-être gérée dans des variables d'environnements
• tous les services externes (api, database, smtp, cache, messaging...) doivent-être gérés comme des ressources accessibles via une URL
• les étapes de build (compilation + dépendances), release (application configuration) et run (lancement de l'application) doivent être strictement séparées
• l'application doit-être stateless et "share-nothing" (aucune donnée en local)
• l'application doit gérer sa couche réseau sans dépendre d'un logiciel externe (ex: webserver embarqué pour ne pas dépendre d'apache)
• l'application doit-être composés de process instanciables sur le même serveur ou sur différents serveurs (scalabilité)
• les process ne doivent pas être démarrés en taches de font (démon) par l'application. la gestion des process (arrêt/relance, gestion logs et stdout, ...) doit être délégués à un process manager (systemd, runit, foreman, ...)
• les tâches administratives (ex: migration db, ...) doivent être traitées par des process séparées (scripts) mais fournis avec le code applicatif et lancé dans le même environnement applicatif

Explication des contraintes et des solutions pour utiliser une application Legacy qui écrit ses données sur disque dans un contexte de cloud où chaque serveur doit avoir les mêmes données