Le modèle MVC comparé à la commande d'une boisson dans un bar

Recensement des design patterns existantes pour les architectures microservices

Une introduction au concept de Phoenix Server

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/

Comment tirer partie des fonctions d'AWS pour faire du Blue/Green Deployment:

1. Créer une nouvelle stack (green) avec l'application mise à jour identique à la stack de production (blue) (Si on utilise Amazon OpsWork, il est possible de directement cloner une stack)
2. Faire tous les tests nécessaires sur la nouvelle stack (green)
3. Quand tous est OK, utiliser Amazon Route53 (DNS AWS) pour rediriger le traffic de la stack blue vers la stack green (nécessite d'avoir un TTL le plus bas possible au niveau DNS, paramétrer le TTL à 60s sur Route53)

En bonus, il est possible d'utiliser la technique Canary Release:

• Route53 permet de faire du routage pondéré: on commence par rediriger seulement 10% du traffic sur la nouvelle stack, puis 20%, ...
  Cela permet de limiter le nombre de users impactés en cas de problème et de vérifier le comportement en charge de façon plus lissée dans le temps.
• Si les stack blue et green utilisent l'autoscaling, la stack blue va se réduire et la stack green grossir au fur et à mesure que le routage pondéré amènera plus d'utilisateurs sur la nouvelle stack.

Suite de l'article qui parle notamment des problématique de modification de schema BDD dans le cadre du Blue/Green Deployment:
https://medium.com/aws-activate-startup-blog/upgrades-without-tears-part-2-blue-green-deployment-step-by-step-on-aws-29c0ffe99c60?source=rss----dad75eb79ad5---4

Le Feature Flipping permet de livrer en production des fonctions désactivées qui pourront ensuite être activé pour tout ou partie des utilisateurs.

Les cas d'utilisation sont multiples:

• livraison en prod de fonctionnalités non terminées lorsque les développeurs commitent sur le trunk (best practices pour le continuous deployment)
• rollback plus rapide (en cas de bug sur une nouvelle fonctionnalité, il suffit de la désactiver sans relivrer)
• tests sur des sous-population (A/B testing)
• proposer des fonctionnalités payantes
• Passer en mode dégradé en cas de problèmes de perfs (en desactivant les fonctions - critique mais + gourmandes en ressources)

Une très bonne présentation de l'architecture microservices par Xebia:

1) un microservice = un fonction qui possède:

• son propre code
• ses propres datas
• un ou plusieurs processus distinct

2) Chaque service doit-être complètement indépendant des autres en termes de :

• modification => changement de code sans impacts sur les autres services
• scalabilité => modification du nombre d'instance sans impacts sur les autres services

3) Toute la communication avec l’extérieur doit se faire via la couche réseau (REST ou BUS).

La suite de l'article ici:
http://blog.xebia.fr/2015/03/09/microservices-des-architectures/
http://blog.xebia.fr/2015/03/16/microservices-des-pieges/

Une synthèse des patterns utilisées pour déployer sans interruption de service dans un contexte de Continuous Deployment.

Une introduction à l'Architecture Orientée Service (SOA) et plus particulièrement les composants SCA utilisés dans IBM WebSphere ESB.