Une Keynote intéressante fut celle de Liz Rice sur la sécurité des architectures dites Cloud natives: les vm, conteneurs, orchestrateurs, et tout ce qui va avec.

Tout d’abord, Liz Rice nous explique qu’aujourd’hui, on le sait pas forcément où le code tourne. On a des centaines de VM/serveurs, certaines applications sont composées de dizaines de microservices, et les containers et orchestrateurs rajoutent une couche de complexité au dessus de tout ça.

La speaker expliquait aussi la différence entre l’ancien temps (ou le présent si vous travaillez pour un grand groupe Français ^^) où les serveurs étaient patchés (à la main ?) et maintenus en vie sur de longues périodes, là ou aujourd’hui on va plutôt essayer de mettre en place des infrastructures immuables (en gros on pète et on reconstruit).

Mais quid de la sécurité dans ces nouvelles architectures ? Vu la multiplicité des briques logicielles et la complexité des architectures, elle doit être intégrée directement dans le pipeline de déploiement.

Par exemple, on peut scanner nos containers avant et après le build pour rechercher des vulnérabilités: voir les versions des produits déployés, vérifier que l’utilisateur lançant un process n’est pas root, vérifier l’isolation du container par rapport à l’host…​

Concernant l’host, des OS spécialisés pour faire tourner des containers (CoreOS, RancherOS…​) peuvent également être une solution. Je n’ai personnellement pas d’avis sur ces OS, ne les ayant jamais utilisés.

Bien sûr, les IDS traditionnels peuvent toujours être utilisés si besoin.

Concernant le réseau, là aussi il faut sécuriser les communications, que ce soit au niveau chiffrement, authentification, ou restrictions (j’évite que des services qui n’ont pas à discuter entre eux puissent le faire).

Enfin, des protections "au runtime" comme SELinux ou AppArmor ont été évoquées. La présentation s’est finie sur une petite démo de la faille Shellshock où un serveur httpd pouvait exécuter du code arbitraire.

En conclusion, une keynote intéressante, mais un détail méritait d’être évoqué et ne l’a pas été selon moi. La meilleure sécurité, c’est quand même d’essayer d’avoir une architecture la plus simple et comprehensible possible avec les contraintes de scalabilité/tolérance aux pannes de notre produit. Restez simple !

Peut être ma keynote préférée des deux jours, ça envoyait du lourd ! Sara-Jane Dunn travaille pour Microsoft Research, et nous expliquait ici l’importance des visualisations par rapport notamment à des chiffres bruts.

Aujourd’hui, on a de plus en plus de données, de logs…​ On calcule souvent des statistiques sur ces données, mais ces statistiques sont parfois trompeuses !

Deux jeux de données peuvent produire des statistiques (moyennes, médianes…​) semblables alors que les données n’ont rien à voir.

De plus, on doit parfois partager ces données avec des collègues, pas forcément de notre domaine (par exemple avec des scientifiques en biologie alors que nous on est informaticien).

C’est là que les visualisations interviennent. Pouvoir représenter et explorer des données de façon graphique est devenu indispensable aujourd’hui.

La speaker, à l’aide de nombreux exemples, nous montrait comment des visualisations aident à résoudre des problèmes parfois très complexes. Les exemples venaient du monde de la biologie, où un chercheur a même avoué que sans l’outil de visualisation développé par la speaker, ces recherches n’auraient probablement pas abouties. Les visualisations lui avaient permis de voir son problème sous un angle totalement différent.

La speaker présentait ensuite quelques techniques pour créer des visualisations pertinentes. Cette slide montre bien par exemple qu’une visualisation à base de formes/graphes est largement plus pertinente qu’une visualisation à base de couleurs. L’intéractivité est aussi aujourd’hui la clé de visualisations pertinentes.

En conclusion, investissez du temps pour créer les outils permettant de visualiser vos données !

Ce talk, donné par Harry Winser, expliquait les stratégies et les outils et process développés pour valider des API HTTP dans une architecture microservice.

Les problèmes pour les API HTTP sont toujours les mêmes. Comment gérer la montée de version d’un service ? Comment je m’assure que les clients d’une version antérieure sont toujours compatibles avec la nouvelle version ?

Une solution peut être les consumer driven contracts. On définit un contrat d’interface pour notre API. Cela permet aux équipes de travailler de manière indépendantes, et d’écrire des tests pour valider nos contrats. Une phrase prononcée intéressante était write your consumer first.

Attention, ces contrats ne concernent que la partie API, et ne permet donc pas de vérifier la logique métier des applications.

Le speakeur utilisait dans son entreprise un format appelé Pact, Ce format permet de décrire une requête HTTP, et s’intègre facilement dans des pipelines de déploiements grâce à une intégration avec de nombreux langages/plateformes (comme par exemple la JVM).

Les contrats Pact sont stockés dans une base appelée Pact broker. Quand une application est build, son artifact (comme par exemple son .jar pour une application Java) est poussée dans un Nexus ou autre, et les contrats Pact de cette application (et pour cette version) dans le broker. Il est aussi important de stocker des stubs/mock de l’API de l’application, qui seront ensuite utilisés par la suite.

Dans l’intégration continue des consumers d’une API, on utilise les stubs de l’API générés précédemment et les fichiers Pact présent dans le broker pour vérifier que l’API correspond bien à un ou des contrats Pact et si les clients peuvent communiquer avec.
Par exemple, un client communiquant avec 3 API pourra tester si il valide le contrat Pact pour ces 3 services.

Il est aussi possible de tester différentes versions de l’API, pour voir si on garde une rétrocompatibilité en cas d’une montée de version par exemple. Ensuite, le résultat de ces tests sont publiés pour être exploités.

Ce talk était intéressant. Je n’avais jamais entendu parler de Pact, le format et l’écosystème autour semblent prometteurs.

Slides.

Le speaker commence tout d’abord à parler du "passé" (les guillemets sont importante).

On a donc depuis longtemps des bases de données relationnelles, avec des propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité), Ces base de données fonctionnent très bien, il est facile de raisonner avec (ACID apporte sur le papier des propriétés fortes intéressantes).

Mais (car il y a toujours un mais), ACID != Serializability (en résumé que les transactions sont exécutées sans se marcher dessus) ! Des anomalies peuvent apparaîtres, et les transactions ne sont pas si isolées qu’on ne le pense (d’où les différents niveaux d’isolations dans les bases de données: read commited, snapshot isolation, serializability…​).

le problème du mode serializable dans une base de donnée est la grande perte de performance associée (il faut par exemple parfois locker complètement les tables pour avoir ce niveau d’isolation, ce qui diminue fortement les performances).

De plus, les configurations par défaut des bases de données n’activent pas la sérialization.
Ces configurations par défaut, couplées à une méconnaissance des différents niveaux d’isolations des bases de données, peuvent causer de sérieux soucis (et difficilement détectables) en production.

En conclusion, les bases de données ACID sont très utiles, fournissent un certain nombre de garanties, mais il faut faire attention car des problèmes de cohérences peuvent toujours se produire.

Cloud, NoSQL, microservices…​ On a maintenant des architectures distribués. Et cela doit vous inquiéter ! Notamment les architectures microservices, où un mauvais découpage peut avoir des conséquences désastreuses.

Parlons maintenant un peu de NoSQL. On avait avant les propriétés ACID pour les bases de données traditionnelles, on parle parfois de BASE (Basically Available, Soft state, Eventual consistency) pour les base de données NoSQL.

Mais en dehors de l’aspect technologique, un gros problème de ces base de données est le marketing et le buzz qui font que les gens l’utilisent sans n’avoir aucune connaissance sur la technologie ou des systèmes distribués en général.

Les choix de base de données se font donc pour des raisons non techniques, ce qui conduit inévitablement à la catastrophe. Anecdote personnelle, mais j’ai déjà vu des décideurs hésiter entre entre Couchbase et Cassandra (wtf) ou entre Cassandra et Redis (wtf^10000), sans même vraiment connaître ni le besoin ni ces technos !

Un grand nombre de projets n’ont pas besoin de bases NoSQL. Le speaker donnait l’exemple de MySQL qui peut très bien traiter plusieurs milliards d’enregistrements.

Les base de données NoSQL ont des use cases, mais il est limité ! Il faut également très bien comprendre les garanties (et l’absence de garanties) qu’offrent les base de données NoSQL, notamment les garanties de cohérences des données et de disponibilité de la base.

Le speaker a ensuite présenté différents problèmes pouvant se produire dans une base de données distribuée, comme par exemple le fameux read your own write, ou alors que contrairement à une croyance populaire, définir un quorum en lecture ne veut pas dire avoir un état cohérent.

Etait également présenté quelques techniques pour gérer ces problèmes de cohérences, comme par exemple le read repair. Etait évoqué également les difficultés à travailler côté développement avec une base de données BASE, où l’absence de transactions et les joies des systèmes distribués peuvent causer des surprises.

Il existe aujourd’hui une multitude d’outils, ces derniers étant quelque part entre ACID et BASE niveau cohérence des données, le choix des technologies doit donc se faire de manière intelligence.

Attention au marketing et aux promesses des vendeurs qui viennent vous vendre du rêve. Attention aux base de données NoSQL et aux architectures distribuées en général, et toujours se poser la question "est ce que j’ai vraiment besoin de ça ?".

Il faut également comprendre son système, et les différents incidents qui peuvent se produire. Même les personnes d’administrant pas mais utilisant les outils doivent le comprendre, comme par exemple les développeurs. Ces derniers doivent connaître les potentiels problèmes pouvant se produire avec des bases de données NoSQL (ou même SQL avec un niveau d’isolation faible) pour pouvoir les requêter correctement.

Et surtout, surtout, pas de transactions entre différents services/outils de storage.

Encore merci au speaker pour ce talk génial, que l’on devrait diffuser à chaque personne prononçant les mots NoSQL et microservice en entreprise.

Slides.