Escalade de bug sur la première génération de Pokemon sur Gameboy
- Fun, WTF
Développer efficacement dans un monde de conteneurs Kubernetes est devenu l'orchestrateur de choix pour déployer des applications. Mais qu'en est-il du quotidien des développeurs qui créent ces applications ? Plus on s'appuie sur la plateforme, plus il est compliqué de développer en dehors de la plateforme. Et développer à l'intérieur de conteneurs n'est pas réputé facile ni agréable. Google est à l'origine de plusieurs projets Open-Source qui se focalisent sur l'expérience des développeurs dans un monde de conteneurs.
- https://github.com/GoogleContainerTools/kaniko
- Kaniko permet de construire une image Docker à partir d'un Dockerfile, sur un cluster Kubernetes remote, de manière sécurisée.
- https://github.com/GoogleContainerTools/skaffold
- Skaffold facilite le déploiement continu d'applications pour Kubernetes.
- Facilite également le développement itératif avec la modification du code source.
Port forwardingpossible sur lelocalhost- Polyglote
- Déploiement sur cluster k8s distant
- Artifacts / Build / Test / Deploy
- https://github.com/GoogleContainerTools/distroless
- Les images Distroless offrent des images de base légères, sécurisées et de qualité.
- Permet d'utiliser des images docker avec le strict minimum pour garantir une sécurité maximale: sans package manager, sans shell ni les programmes pré-installés sur des distributions linux. Tout cela grâce au
multi-stage buildde docker. - Possible toutefois d'avoir un bash et package manager sur des versions
debugdes images.
- https://github.com/gliderlabs/docker-alpine
- Images docker minimalistes construites sur une
libcplus légère etBusyBox. - Distribution légère (~5MB) et sécurisée (surface d'attaque minimale).
docker buildclassique peu performant pour du build incrémental.Layers: effet hamburger, images de plus en plus volumineuses.
- Bazel permet de construire des images Docker sans Docker.
- https://github.com/bazelbuild/bazel
- Bazel implémente ses propres
docker_rulesqui vont venir remplacer les habituelsmaven/gradledans la chaîne de build. - Outil de build avec sa propre syntaxe (efficace, rapide, mais complexe).
- https://github.com/GoogleContainerTools/jib
- Même fonction que Bazel, mais plus simple et limité aux applications Java (construites avec Maven/Gradle).
- Pas besoin de
Dockerfile.
Comment gérer un livrable unique configuré pour plusieurs environnements ?
- https://helm.sh/ : package manager pour k8s
- Helm peut paraître complexe mais ses possibilités de généralisation font sa force avec l’ensemble des templates de déploiements déjà existant en ligne : https://github.com/helm/charts
- https://github.com/kubernetes-sigs/kustomize
- Templating de
yamlpour k8s, pour déployer les applis sur différents environnements.
- https://github.com/tazjin/kontemplate
- Templating de ressources pour k8s, plus simple que Helm, mais plus basique.
How to fight with them
- In the beginning, there was the Agile Manifesto
- 4 values, 12 principles
- Scrum
- Kanban
- Scrumban...
- On the other hand, we have Software Craftsmanship Manifesto
- Kind of an extension to Agile
- Value, quality and share matter
- "Raising the bar"
- Community of professionals
- Go and stay outside one's comfort zone
- Culture of sharing : everyone learn from each other, meetups, conferences, "I'm not always right", etc.
- Then came DevOps
- No manifesto, no real framework
- New tools, new name for Ops team...
- Most of all, it is made of culture and shared responsibility, reduced organisational silos, continuous improvement...
- Not visible... why ?
- To improve, you have to assess something is wrong
- Never finished job
- Combining all 3
- Assess and understand (identify problems, what can be done, make changes, and most of all measure)
- There is no one single way to do things (find your own path, no silver bullet, best practices are not always best for everyone)
- Show courage (leave comfort zone, be ready to fail, ask for help)
- Continuous improvement (process, work environment, knowledge, feedback)
- Keep it simple (not simpler) (easier to deliver, less failures, proceed with baby steps at first)
- Respect (people, experience, relationship, no blame)
- What's next ?
- In fact, all those experience practices were already there 20 years ago (simplicity, communication, feedback, courage, respect)
- Make your own hybrid (consider your context, continuously evaluate)
- Monolith -> µ-services
- µS with their own data
- Multiple points of entry
- More flexibility but more complexity
- Distributed computing, polyglot
- Fallacies of distributed computing
- 1 failure = cascading failure
- Multiple µS needs (API : tracing, monitoring, logging, auth, pipeline, resilience, elasticity, invocation, discovery)
- pub/sub
- streaming
- distributed and horizontally scalable
- fault-tolerant
- commit log
- sharding
- enables messaging between µs
- event sourcing: state of the application as a series of events
- Add new services around a monolith without touching or modifying it
- Event-sourcing on each action made by/on the monolith
- CDC example :
- Why Kubernetes is the New Application Server
- Service Discovery
- Basic Invocation
- Elasticity, auto-scaling
- Logging
- Monitoring
- Build and Deployment Pipelines
- Resilience, self-healing
- Authentication
- Tracing
- Kubernetes
- Discovery
- Invocation
- Elasticity
- OpenShift
- Monitoring (Prometheus)
- Logging (EFK)
- Pipelines
- Istio
- Tracing
- Monitoring
- Blue-Green deployments
- Authentication
- Resilience
- Discovery
Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.
- https://www.testcontainers.org/
- https://github.com/dadoonet/testcontainers-java-module-elasticsearch
Prise de notes visuelle La communication fait aujourd’hui partie intégrante de notre travail; il nous arrive régulièrement de vouloir diffuser une information importante, réaliser une présentation, un compte rendu de réunion… Mais comment être sûrs que le message que l’on souhaite faire passer a bien été compris et retenu par les interlocuteurs ? Le sketchnoting apporte une solution ludique, créative et agréable autant à créer qu’à lire, et permet de mettre en valeur votre communication à l’aide de procédés très visuels, simples et accessibles à tous.
Karate fournit une syntaxe facile pour tester vos APIs REST. Son format DSL plain text inspiré de la syntaxe Cucumber (ie. Gherkin) permet même aux personnes aux notions basiques en développement de venir couvrir vos APIs ou Web services (micros, nanos ou pas!)
"Réconciliez vous avec votre documentation" Les développeurs aiment écrire de la documentation... ou pas ! Pourtant même les plus réfractaires doivent l'admettre, garder une trace des décisions techniques prises au cours d'un projet peut s'avérer indispensable pour la pérennité et maintenabilité de celui-ci.
Alors comment éviter l'obsolescence programmée de la documentation, tout en réduisant la pénibilité de la rédaction ?
Il existe un format simple, les Architecture Decision Records (ADRs), pour écrire des documents d'architecture sous la forme d'un journal immuable. Cette technique simple gagne en popularité et a donné de bons résultats sur nombre de projets.
Durant cette présentation vous construirez en direct un ADR. En partant d'un problème constaté sur un projet, vous élaborerez une réponse technique qui servira de base à une implémentation ultérieure. Vous décrirez les raisons qui vous poussent à faire des compromis, tout en capturant le contexte dans lequel cette décision a été prise pour référence future.