*

Web, Ops & Data - Octobre 2019


30/10/2019 kafka traefik kubernetes ksql kafka-streams gke anthos helm

Rendez-vous le 5 Novembre prochain à la seconde édition du Paris Time Series Meetup consacré à QuasarDB pour des cas d’usages autour de la finance et des transports.

Cloud

  • The $10m engineering problem : retour d’expérience intéressant sur l’optimisation de sa facture cloud et donc l’accroissement de sa marge opérationnelle.

Container et Orchestration

  • What’s Going on with GKE and Anthos? : Si on rapproche ça avec le fait que Google ait gardé le lead sur knative plutôt que de le confier à une fondation, on peut avoir quelques sueurs froides sur le potentiel lock-in ou alors d’une offre k8s à 2 vitesses (GKE tel qu’on le connait actuellement et Anthos GKE avec des fonctionnalités & souscriptions additionnelles…). La seule limite que je vois à ça pour le moment est le fait que Google a vendu k8s comme runtime universel de workload et qu’ils ont besoin de garder cela pour piquer des parts de marché à AWS & Azure…
  • Traefik 2.0 with Kubernetes et Advanced Traefik 2.0 with Kubernetes : pas encore implémenté mais a priori tout ce qu’il faut savoir pour passer de Traefik 1.x vers Traefik 2.x sous Kubernetes
  • Helm 2.15.0 Released : dernière version stable à apporter des nouveautés a priori avant migration vers la version 3.0. La version 2.x va passer en maintenance (correctifs de bugs & sécurité) et s’éteindra progressivement (6 mois après la release de Helm 3, elle ne prendra que des correctifs de sécurité et fin du support au bout d’un an). En attendant, cette version apporte notamment le paramètre --output <table|json|yaml> à certaines commandes. Pratique quand on manipule les sorties de Helm dans des scripts…
  • Comparing Ingress controllers for Kubernetes : une comparaison de 11 Ingress Controller (Nginx, Traefik, Kong, HAProxy, etc) sur une douzaine de fonctionnalités.

(Big) data

  • Why I Recommend My Clients NOT Use KSQL and Kafka Streams : la gestion des états et la capacité à pouvoir savoir à quel offset d’un topic kafka reprendre sa consommation peut être un sujet surtout dans le cadre d’une grosse volumétrie qui peut empêcher que le cas de reprendre la consommation du topic depuis son origine. Si Kafka Streams était doté de ce fameux “checkpoint” cela pourrait simplifier la chose. L’autre cas étant sur l’absence de “shuffle sort” utilisé dans des contexte analytiques. Du coup Kafka streams crée des topics supplémentaires pour le besoin et cela peut nuire au bon fonctionnement de votre cluster.
  • Change data capture in production with Apache Flink - David Morin & Yann Pauly : un retour d’expérience très riche et très complet sur l’utilisation de Flink chez OVH, les problématiques qu’ils ont rencontré et comment ils ont itéré sur leur pipeline d’ingestion de données. La version française donnée à DataOps.rocks devrait être disponible sous peu.

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 kafka postgres elasticsearch python sécurité aws terraform mysql redis ovh tick cassandra cloud docker-compose git helm hashicorp ptsm swarm telegraf timescaledb chronograf dashboard rancher résilience test flux gcp gitlab log machine-learning monitoring prometheus spark architecture arm confluent devops iac java kapacitor ksql microservice podman raspberrypi s3 serverless sql timescale vscode angularjs api bilan cert-manager cncf comptabilité container cérénit dns gitlab-ci gke graphql influxdata ingress javascript nomad opensource operator optimisation perspective pipeline service-mesh ssh stream vault vector warpscript windows cli containerd csp documentation elastic flows forecast geospatial hpkp influxace iot jenkins kafka-streams kibana kubedb lambda lean licence maesh maintenance mariadb microsoft mobile nginx npm orientdb performance redhat registry rest rethinkdb reverse-proxy rook sauvegarde scaleway agile apm automatisation azure bash big-data bigdatahebdo ceph certificat challenge ci/cd cluster consul continous-delivery continous-integration cookie data dataviz deployment diff fluxlang framework gdpr grav hsts http/3 https hypriot hébergement influxdays istio jq json k3s lets-encrypt linux load-balancer longhorn meetup molecule mongodb nosql nvidia openebs openssh ovhcloud percona php pip postgresql 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 agpl akka alerte alibaba amazon-emr amqp anomalie anonymisation anthos apache-pulsar ara arima arrow artefact audit banque bastion beam beat bme680 bootstrap 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 co2 cockroachdb code codeurs-en-seine commit confluence conftest 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 datatask date date-scientist dbt ddd debezium debian delta deprek8 desktop devoxx dig discovery 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é falco falcor feature-policy fec fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd formation foundation frontend fsync fullstack git-filter-repo github gitignore glacier glowroot go golang google google-cloud-next gpg gpu grid géospatial hacker hadoop haproxy harbor hdfs header html html5 http hue ia iaac ibm immutable incident index indluxdata influxcloud infrastructure-as-code ingénierie inspec jquery jwt k3d k8s k9s kotlin kubeadm kubecon kubectl label laravel leap-second letsencrypt libssh linky linter liste-de-diffusion lmap loadbalancer logstash logstatsh loi loki mailing-list management maturité mesh mesos message metabase metallb micro-service minio mot-de-passe mqtt multi-cloud médecine métrique network newsletter nodeport notebook null object-storage observability observabilité opa opendata openhab openmetrics openshit openstack openweb over-engineering packaging pandas parquet partiql password persistent-volume-claim pico pipenv pod portainer portworx prediction prescience production promql prévision psp ptyhon publicité pubsub pulsar push pyenv pérénnité qualité quasardb quay questdb queue quic ram rambleed raml react readme recaptcha recherche redistimeseries reindex reinvent reliability remote-execution repository responsive revocation revue-de-code rexec 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 spectre spinnaker spécifications sqlite sri ssh-agent ssl stabilité stash statistique storage sudo superset suse sympa sysdig syslog-ng sérénité template terracost terrascan test-unitaire tidb tiers time timer timestream 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 warpstudio wasm web yaml yq yubikey