Une bonne vulgarisation du concept d'API.

Méthode pour faire du blue-green deployment sur AWS avec des scripts python utilisant boto3 et fabric.

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.

1. Bad code does too much – Clean code is focused (cf. Single_responsibility_principle)
2. The language you wrote your code with should look like it was made for the problem
3. It should not be redundant (cf. DRY)
4. Reading your code should be pleasant (cf. KISS & YAGNI)
5. Can be easily extended by any other developer
6. It should have minimal dependencies
7. Smaller is better
8. It should have unit and acceptance tests
9. It should be expressive

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

Terraform propose désormais une registry de modules Terraform prêts à l'emploi (ex: vpc, autoscaling, rds, elb, ...)

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Quelques règles pour mettre en place un système d'alerting de la production pertinent dans le cadre d'astreintes 24/24.

1. Privilégiez les alertes sur les symptômes (disponibilité du service pour les utilisateurs, temps de réponse...) plutôt que les alertes sur les causes techniques (CPU, RAM, process, erreur 500, ...)

2. Scripter toutes les actions sur alertes qui peuvent être automatisée

3. Ne déclencher l'astreinte que pour les alertes qui nécessitent une action immédiate ne pouvant pas être automatisée

Une alternative à Google Translate qui se base sur la base de données de https://www.linguee.com/

1. Microservice First
Commencer par les microservices est non justifiable puisqu'ils ajoutent une complexité et des efforts supplémentaires aux développements.
Il faut plutôt débuter par des solutions monolithiques, ennuyeuses et classiques, pour évoluer selon le besoin vers des architectures microservices en identifiant les services qui nécessitent une refonte.
2. Gatekeeper et le versioning sémantique
Absence de stratégie de versioning : le partage des mêmes sources de données entre microservices peut ruiner la coordination, voire même ralentir les déploiements et freiner l'agilité.
"Gatekeeper" peut paraître à première vue la solution directe, n'est cependant qu’un déplacement du problème.
Le "Semantic Versioning" couplé à une bonne stratégie de gouvernance (héritage SOA) permettent la résolution de cette problématique.
3. Spiky load
Reste le partage des mêmes sources de données qui pose des soucis avec des charges non équilibrées entre services. L’exemple d’un microservice qui stresse une base de données commune et qui bloque les autres microservices.
L’utilisation des queues, pour amortir et absorber les pics et distribuer la charge, permet de résoudre le "Spiky load" entre services mais avec un coup supplémentaire de gestion du modèle asynchrone.
4. Discovery Service ou le centralised router
Le codage en dur des adresses et des ports IP simplifie le démarrage des projets. Mais très vite, il devient le cauchemar des Ops au moment du déploiement.
Tammer cite deux solutions :
La première est le "Discovery Service" comme consul ou etcd avec un effet de bord où les services seront obligés de comprendre les indirections de lookup.
Le "Centralised router" comme deuxième solution est considérée transparente et plus simple à mettre en place, étant la réplication d’un DNS.
5. Circuit Breaker pour les Dogpiles
Les "Dogpiles" : invoquer et continuer à stresser un microservice bien qu'il ne soit plus en état de répondre aux demandes, créant ainsi un effet boule de neige.
Une solution classique est l’introduction de "Circuit Breaker" qui jouera le rôle d'intermédiaire pour empêcher cet effet.
6. Correlation ID pour le débogage
Débogage : les microservices ajoutent des frais supplémentaires, y compris le débogage des services distribués et asynchrones. Ne pas concevoir une stratégie de logging dès le départ peut mettre en cause toute la solution.
L’utilisation de "Correlation ID" s'avère nécessaire pour tracer l’origine et le parcours des requêtes entre microservices. Évidemment, la gestion des id de corrélation ajoute un coût de développement et de coordination entre équipes.
7. Mocks
Lors de la phase de tests, les équipes ont tendance à créer des mocks pour les microservices utilisés. Ce qui finira par une prolifération des bouchons proportionnellement aux services consommés.
Une première solution serait de déléguer la création des mocks aux fournisseurs de services eux-mêmes, alors que les consommateurs doivent à leur tour savoir comment les invoquer. Pour répondre à cette limitation, il serait judicieux de développer une api qui, à la fois cache les détails d’implémentation et les protocoles de communication utilisés, mais aussi facilitant l’aiguillage entre les différentes implémentations pour les besoins de tests.
8. Flying Blind
"Flying Blind" ou l'expérience de s'aventurer en production sans avoir connaissance sur ce qui passe, ni sur les métriques d’utilisation de chaque microservice.
Les graphes, les alertes et les tableaux de bord sont les solutions classiques pour toute solution en production.
9. Snowflakes et Golden Image
"Snowflakes" : mettre à jour et installer les correctifs logiciels dans un univers microservices peut devenir ingérable, voire impossible.
"Golden Image" est une solution pour ce dilemme, avec l’utilisation d’une combinaison de base commune de frameworks et des runtimes avec des versions d’OS de références.
10. Doomsday et CI
Le "Doomsday", ou "La peur du jour J", le jour de la mise en production, est un problème récurrent pour les organisations qui ne déploient pas assez souvent. Déployer plus fréquemment augmente la confiance en son processus de déploiement, réduit les risques d'erreur, et améliore la rapidité à laquelle on peut délivrer de nouvelles fonctionnalités.
L'intégration continue résout cette problématique avec la mise en place d'une pipeline prédéfinie et qui donne confiance aux tests automatisés.
11. PaaS
L’explosion opérationnelle avec l’utilisation d’une grande variété de technologies, de langages et de solutions, ce qui rend leur gestion en post-production un fardeau poussant les Ops à bloquer le passage en production.
Automatiser le déploiement (CD) s'avère à première vue impossible. Mais c’est là où le rôle des platformes PaaS se confirme pour donner la souplesse et les moyens de gestion des microservices.

Un reformatteur de code python développé par Google.

$ pip install yapf
$ yapf my_file.py

Boot du Raspberry Pi 1, 2 et 3 sur une clé USB ou un disque dur. La Fondation a fait évoluer les méthodes de boot. Ce tutoriel les présente.

Pour améliorer la gestion de l'énergie sur un laptop Linux (et donc la durée de la batterie).

$ sudo apt install tlp tlp-rdw
$ sudo systemctl start tlp
$ sudo tlp-stat -s

Attention, TLP est compatible avec thermald mais pas avec laptop-mode-tools et ondemand:

$ sudo apt remove laptop-mode-tools
$ sudo systemctl disable ondemand

Pour monter un répertoire distant via ssh:

# install sshfs on client (no additional configuration required on server)
# for debian/ubuntu:
$ sudo apt install sshfs
# create mount point
$ mkdir ~/sshfs
# mount the directory
$ sshfs <remote_host>:/home/<remote_user> ~/sshfs
# umount the directory
$ fusermount -u ~/sshfs

Pour installer Firefox 57 sur Debian Testing:

$ echo "deb http://http.debian.net/debian experimental main" | sudo tee -a /etc/apt/sources.list
$ apt-get update
$ apt-get install -t experimental firefox

AVANT / APRÈS : un site dédié pour savoir quels droits nous pouvons perdre avec les ordonnances loi travail.

Un outils de restore point-in-time pour les buckets S3 bucket qui ont le versioning activé

Une command-line améliorée pour awscli: pip install aws-shell

Il est possible de tester le failover d'une base RDS Multi-AZ en la rebootant avec l'option force-failover.

aws rds reboot-db-instance \
            --db-instance-identifier dbInstanceID \
            --force-failover

Attention le changement d'AZ (AZ primary devient AZ secondary et vice versa) n'est pas visible instantanément (10 min max) dans la console AWS.
Pour vérifier que le changement a bien eu lieu, il faut vérifier que l'alias DNS de l'instance a changé:

while true; do host <my-rds-endpoint.amazonaws.com> | grep alias ; sleep 1; done