Thanos permit de requeter plusieurs serveurs Prometheus et d'agréger leurs données au sein d'une vue commune

Un rappel des différentes étapes pour scaler une application web de 1 à 10 millions d'utilisateurs sur une infra AWS.

Il est inutile de designer une architecture ultra-résiliente dès le début:

1. l’architecture évoluera en même temps que le nombre d'utilisateur
2. plus l’architecture sera simple à l'origine, plus elle sera facile à faire évoluer
3. l'acquisition du trafic prend en général plus longtemps que l'évolution de l'architecture.

Les 3 solutions clés pour créer une architecture scalable:

1. Load Balancing
2. Caching
3. Off-line Processing

1. Do the simple thing first. This is the secret of supporting exponential growth. There's no need to future proof everything you do. That leads to paralysis. For each new challenge find the fastest, simplest fix for each.
2. Do fewer things better. Focus on a single platform. This allows you to iterate faster because not everything has to be done twice. When you have to expand create a team explicitly for each platform.
3. Upfront work but can pay huge dividends. Create an automated scriptable infrastructure implementing a repeatable server provisioning process. This makes it easier to bring on new hires and handle disasters. Hire engineers with the right stuff who aren't afraid to work through a disaster.
4. Don’t reinvent the wheel. Instagram moved to Facebook's infrastructure because it allowed them to stay small and leverage a treasure trove of capabilities.
5. Nothing lasts forever. Be open to evolve your product. Don't be afraid of creating special teams to tackle features and adapt to a rapidly scaling community.

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

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

Une explication des problématiques rencontrées sur une architecture Web répartie (horizontal scaling)