Voxxeddays Microservices Paris


07/11/2018 microservice voxxeddays cloud distributed systems ddd bounded context

J’ai participé à la première édition de Voxxeddays Microservices Paris qui a eu lieu du 29 au 31 oct, sous la forme de deux jours de conférences et un jour de workshop. Je ne suis allé qu’aux deux jours de conférences.

Globalement :

  • Je crois que c’est la première conférence tech où je vois autant de femmes témoigner - après recomptage, il n’y en avait que 8 sur 45 speakers, mais 2 des 3 keynoters étaient des femmes. 1/6 c’est encore peu mais c’est mieux que d’habitude. L’assistance m’a aussi paru plus féminine que d’habitude. Le mardi, la majorité des conférences auxquelles j’ai assisté étaient assurées par des femmes.
  • Deux journées denses avec des formats de conférences variées (15/25/45 minutes) et des sujets variés également (Techno, Retours d’exéprience, Architecture, Problématiques, etc).

Sur les keynotes qui devaient articuler le passé, le présent et le futur des microservices :

Distant past of microservices - Ken Finnigén (Red Hat)

  • Tout n’est que système distribué au final - les microservices n’en sont qu’une variante, après SOA, après le client/serveur, etc.
  • Il y a un cycle des systèmes distribués : gestion toute imbriquée (“embedded”), passage par des librairies, puis des middlewares et enfin par de la gestion d’environnement (et de ses variables). Il est donc probable que l’on revienne vers du tout en un prochainement. Même s’il y a des améliorations incrémentables d’un cycle à l’autre, on reste sur la même boucle.
  • “Old is the new new” - il faudrait cesser de réinventer la roue pour la simple raison que nous pouvons le faire. il faudrait plutôt chercher à résoudre des problèmes qui n’ont pas encore été résolu. Cela me fait penser aux nouveaux langages ou frameworks qui se créent sans tenir (trop) compte des langages précédents : ils se retrouvent au final à devoir traiter les mêmes problèmes que leurs prédécesseurs et sans forcément trouver une réponse plus satisfaisante.
  • Réflexion autour de la notion de “quescient state” comme prochain but à atteindre.

The endless now : distributed systems and teams - Bridget Kromhout

  • C’est dommage que l’oratrice ait forcément voulu raccrocher des technologies et des outils à son propos car cela a nuit à son message. Je n’ai pas vu la raison ou l’intérêt de mentionner ces outils.
  • Le propos était d’appliquer les principes du CAP sur les équipes et les systèmes :
    • “Consistency” : les containers ont apporté cette reproductabilité des déploiements
    • “Avilability” : les outils d’orchestration répondent à ce besoin et à cette gestion de la disponibilité de nos applications
    • “Fault/Partition tolerance” : il faut travailler sur les effets du bus factor, la loi de Conway et la communication entre les équipes pour éviter la dépendance à une personne et développer la résilience de l’équipe et du système.

Preparing for a future microsdervices journey - Susanne Kaiser

Ma keynote préférée - l’oratrice reparcourt tout ce qui fait un micro-service et les bonnes pratiques associées :

  • Pour un simple/petit micro-service, il faut bien avoir en tête tout l’écosystème que l’on emmène avec soi (solutions et infrastructure cloud, CI/CD, etc)
  • Parcours des bonnes pratiques et des “cloud native citizen principles”
  • Elle prone le focus sur notre coeur d’activité et d’externaliser le reste en ayant recours à des services managés. Toutefois, elle fait une très belle remarque en rappelant qu’il ne faut pas négliger la charge cognitive liée à ces services managés. Ils résolvent des problèmes et font gagner du temps mais ne sont pas neutres pour autant (ex: les primitives de Kubernetes et d’un service mesh comme Istio)

Pour les conférences, celles que j’ai préféré :

Hexagonal at scale with DDD and microservices ! - Cyrille Martare (Arolla)

  • L’orateur rappelle que les microservices requiert une approche DDD puis les principes de DDD en eux même. Il rajoute que les architectures 3 tiers, par couche, par technologie ou encore que le découpage par entités ne vont pas créer de bons microservices et ne sont pas dans une approche DDD. Il faut donc définir avec le métier les fameux domaines et leurs frontières (“bounded context”). L’orateur a alors parcouru les différents heuristiques permettant de les définir.
  • Si nous avons été habitués à avoir une approche DRY (Don’t reapeat yourself"), dans une approche DDD et Microservices, cela perd son sens. Il vaut mieux accepter de la duplication de données afin d’avoir du code moins couplé et donc avoir une meilleure indépendance des microservices entre eux.

Microservices Lessons Learned - Susanne Kaiser

Dans la continuité de sa Keynote, Suzanne fait un bilan de ce qu’elle a pu faire et de comment il aurait fallu le faire. Je vous invite à voir son talk et récupérer les slides.

Coté Outils…

Quelques outils qui m’ont semblé intéressants :

  • Jenkins X : l’idée est de déployer sur un cluster Kubernetes un noeud maitre Jenkins et un Nexus (ou autre produit de stockage d’artefacts) et ensuite d’instancier les agents Jenkins à la volée pour vos besoins de CI/CD.
  • Teeid ou l’ancien site : solution permettant de définir une ou plusieurs bases virtuelles au dessus d’une base existante. Cela peut être pratique dans le cadre de la sortie d’un monolithe vers des microservices. L’idée est de permettre au micro-service d’avoir la nouvelle vue tout en conservant l’ancien système.
  • Micronaut se veut un framework java minimaliste pour être adapté aux microservices mais sans affecter la productivité des développeurs. Il est développé par l’équipe qui a réalisé Grails. Il se veut plus léger/performant que Microprofile qui est en gros la version microservice du framework JEE. Micronaut serait plus proche de Vertx.
  • Strimzi : Il s’agit d’un projet Red Hat pour fournir un Cluster Kafka à déployer sur Kubernetes ou Openshift
  • Debezium : Plateforme de Change Data Capture (CDC) - Elle est basée sur Kafka et Kafka Connect. Elle permet de récupérer les changements de vos bases MySQL/Postgres/MongoDB sous forme d’événements et de les communiquer à qui de droit en mode streaming.
  • gRPC : si vous n’avez pas besoin d’une API REST, que vous manipulez plutôt des RPC que des ressources (REST), que vous n’êtes pas dans un contexte CRUD, alors gRPC peut être fait pour vous.
  • Dependency Check et Dependency Track sont deux projets de l’OWASP permettant d’analyser vos dépendances et de surveiller les vulnérabilités de votre base de code. Ils s’intègrent notamment avec Jenkins.

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)

Nuage de tags

kubernetes docker influxdb timeseries traefik grafana kafka ansible elasticsearch postgres python warp10 aws sécurité mysql redis terraform tick cassandra cloud helm ovh git swarm telegraf rancher résilience test timescaledb chronograf docker-compose flux gitlab ptsm architecture arm confluent dashboard devops ksql log machine-learning microservice monitoring prometheus s3 serverless spark angularjs api bilan cert-manager cncf container cérénit dns gcp graphql hashicorp iac ingress java javascript opensource operator optimisation perspective raspberrypi service-mesh sql ssh stream vscode warpscript windows csp documentation elastic flows gke hpkp influxace jenkins kafka-streams kapacitor kibana kubedb lambda lean licence maesh maintenance mariadb microsoft mobile nginx npm orientdb performance pipeline redhat rest rethinkdb reverse-proxy rook sauvegarde scaleway agile apm automatisation azure bash big-data bigdatahebdo ceph certificat ci/cd cli cluster containerd continous-delivery continous-integration cookie deployment diff fluxlang forecast framework gdpr gitlab-ci grav hsts http/3 https hypriot hébergement influxdata influxdays istio jq json k3s lets-encrypt linux load-balancer longhorn meetup molecule mongodb nosql nvidia openebs percona php pip podman postgresql reaper registry replication rootless rpi rsyslog runc scale secrets société solr sre systemd timezone tls vault virtualenv vitess vue.js wagtail warpfleet yarn accessibilité acme akka alerte alibaba amazon-emr amqp anonymisation anthos apache-pulsar ara arima arrow audit bastion beam beat bounded-context branche brigade browser buildkit cahier-des-charges calico cassandra-reaper cd cdc cdk centos centralisation-de-logs certificats cgroups chart checklist chrome ci cilium cloud-init cloud-native cloud-storage clusterip cnab cni cockroachdb code codeurs-en-seine commit confluence conftest consul context continous-deployment conventional-commit coreos cors covid19 cqrs crash cri cron crontab csi csrf css curl d3.js daemonset data data-engineer data-pipelining data.gouv.fr datacenter dataviz date date-scientist ddd debezium debian delta deprek8 desktop devoxx dig distributed-systems dive docker-app docker-hub docker-registry docker-swarm dockershim documentdb dog dokcer données-personnelles draft drop-in duration déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd event-sourcing faas facebook faisabilité falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd formation foundation frontend fsync fullstack github gitignore glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy harbor hdfs header html html5 http hue ia iaac ibm immutable incident index influxcloud infrastructure-as-code ingénierie inspec iot jquery jwt k3d k8s k9s kotlin kubeadm kubecon kubectl laravel letsencrypt linky liste-de-diffusion loadbalancer logstash logstatsh loi mailing-list management maturité mesh mesos message metallb micro-service mot-de-passe mqtt multi-cloud médecine métrique network newsletter nodeport nomad null object-storage observability observabilité opa opendata openmetrics openshit openssh openstack openweb over-engineering ovhcloud packaging pandas parquet partiql password persistent-volume-claim pipenv pod portainer portworx prediction prescience production ptyhon publicité pubsub pulsar push pyenv pérénnité qualité quasardb quay questdb queue quic ram rambleed raml react recaptcha recherche redistimeseries reindex reinvent reliability responsive revocation revue-de-code rgpd rhel rkt rolespec root rpo rto rust rwd safe-harbor scalabilité scanner schema scp sdk search select serverless-architecture service service-account service-worker setuptools sftp sha1 sharding shell shipyard sidecar souveraineté-numérique spinnaker spécifications sri ssh-agent ssl stabilité stash statistique storage superset suse sympa syslog-ng sérénité terracost terrascan test-unitaire tidb tiers timer timescale timestream training travail tsl ubuntu unikernel unit ux vector vendredi victoria-metrics vie-privée virtualbox virtualisation vm vnc volume voxxeddays vpc warpstudio web yaml yq yubikey