*

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 timeseries influxdb warp10 traefik grafana ansible elasticsearch kafka postgres python aws sécurité terraform mysql redis telegraf ovh tick cassandra chronograf cloud dashboard docker-compose git hashicorp helm timescaledb flux ptsm swarm vector kapacitor podman rancher résilience test gcp gitlab influxdata log machine-learning monitoring prometheus s3 spark timescale vscode architecture arm comptabilité confluent devops gitlab-ci iac java ksql microservice nomad postgresql raspberrypi serverless service-mesh sql angularjs api bilan cert-manager cncf consul container cérénit dns flows gke graphql ingress javascript npm opensource operator optimisation perspective pipeline rook scaleway ssh stream vault warpscript windows cli containerd csp discovery documentation elastic forecast geospatial golang hpkp influxace iot jenkins kafka-streams kibana kubedb lambda lean licence maesh maintenance mariadb microsoft mobile nginx orientdb performance quasardb redhat registry rest rethinkdb reverse-proxy sauvegarde warpstudio agile anomalie apm arima audit automatisation azure bash big-data bigdatahebdo ceph certificat challenge ci/cd cluster continous-delivery continous-integration cookie data datatask dataviz dbt deployment diff facebook fec fluxlang framework gdpr grav hsts http/3 https hypriot hébergement ia influxdays istio jq json k3s lets-encrypt linux load-balancer longhorn meetup metabase molecule mongodb nosql nvidia openebs openssh ovhcloud percona php pip questdb reaper replication rootless rpi rsyslog runc scale secrets société solr sre systemd tempo timezone tls virtualenv vitess vue.js wagtail warpfleet yarn accessibilité acme adoptopenjdk agpl akka alerte alertes alerting alibaba amazon-emr amqp anonymisation anthos apache-pulsar ara arrow artefact automation automl banque bastion beam beat bi bme680 bootstrap bounded-context branche brigade browser buildah buildkit cahier-des-charges calico cassandra-reaper cd cdc cdk centos centralisation-de-logs certificats cgroups chart check checklist chrome ci cilium circuitpython clever-cloud clickhouse cloud-init cloud-native cloud-storage cloudflare clusterip cnab cni co2 cockroachdb code codeurs-en-seine commit confluence conftest consul-connect context continous-deployment conventional-commit coreos cors covid19 cqrs crash cri cron crontab csi csrf css curl d3.js daemonset data-engineer data-pipelining data.gouv.fr databricks datacenter 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 euclidia event-sourcing faas faisabilité falco falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd formation foundation frenchtech frontend fsync fullstack git-filter-repo github gitignore glacier glowroot go google google-cloud-next gpg gpu grid géospatial hacker hadoop haproxy harbor hdfs header holt-winters html html5 http hue iaac ibm immutable incident index indluxdata influxcloud infrastructure-as-code ingénierie inspec jquery jvm jwt k3d k6 k8s k9s kaniko katz kotlin kubeadm kubecon kubectl label laravel leap-second lens letsencrypt libssh linky linter liste-de-diffusion lmap loadbalancer logstash logstatsh loi loki lstm mailing-list management maturité mesh mesos message metallb micro-service minio mot-de-passe mqtt multi-cloud médecine métrique n8n network newsletter nodejs nodeport notebook notifications nrtsearch null object-storage observability observabilité opa opendata openhab openmetrics openshit openstack openweb opnsense over-engineering packaging pandas parquet partiql password persistent-volume-claim pico pipenv pivot pod portainer portworx prediction prescience production promql prophet prévision psp ptyhon publicité pubsub pulsar push pyenv pérénnité qualité quay queue quic ram rambleed raml react readme recaptcha recherche redistimeseries reindex reinvent reliability remote-execution repository responsive retention-policy revocation revue-de-code rexec rgpd rhel rkt rolespec root rpo rto rust rwd résultat safe-harbor sarima scalabilité scanner schema scp sdk search select serverless-architecture service service-account service-worker setuptools sftp sha1 shard shard-duration shard-group sharding shell shipyard sidecar singer souveraineté-numérique spectre spinnaker spécifications sqlite sri ssh-agent ssl stabilité stash statistique storage sudo superset suse sympa sysdig syslog-ng sérénité task template terracost terrascan test-unitaire tidb tiers time timecale timer timestream tinygo training transformation travail trésorerie tsfr tsl ubuntu unikernel unit ux velero vendredi victoria-metrics vie-privée virtualbox virtualisation vm vnc volume voxxeddays vpc wasm web wireguard workflow yaml yield yq yubikey