2023-08
¶
2023-08-30 Terraform By Hashicorp Forked To OpenTF ¶
“Terraform, arguably the most popular Infrastructure as Code products, has been forked after the parent company HashiCorp changed its license from the Mozilla Public License (MPL) to the Business Source License v1.1 (BSL), “ writes long-time Slashdot reader ochinko.
“Our view is that we’re actually not the fork because we’re just changing the name but it’s the same project under the same license,” Sebastian Stadil, co-founder and CEO of DevOps automation biz Scalr told The Register.
“Our position is that the fork is actually HashiCorp that has forked its own projects under a different license.”
You can see the OpenTF manifesto here .
OpenTF sticks a fork in Terraform ¶
OpenTF announces they’re forking Terraform and joining the Linux Foundation, Meta gets in the LLM-for-codegen game with Code Llama, Matt Mullenweg announces WordPress.com’s new 100-year plan, Paul Gichuki from Thinkst learns that default behaviors stick (and so do examples) & Marco Otte-Witte makes his case for Rust on the web.
2023-08-12 Learning Rust with AI, eBPF learning map, We Hack Purple+Semgrep, 90DaysOfDevOps, eBPF Summit 2023, Coroot AI Observability, Trace-based testing with OpenTelemetry ¶
👋 🌱 🐝 🤖 🛡️⛅ 👁️ 📚 🔖 🎯 🎥 🎤
👋 Hey, lovely to see you again¶
The AI landscape is moving fast, and so is Observability and eBPF.
The latter will have a virtual eBPF Summit in September 2023 for everyone to join, inspiring new tools that help debug production workloads.
Learning AI on the other hand also means finding use cases, for example learning a new programming language and writing a blog post about the experience.
I also loved reading about AI Observability and Shadow AI this month.
Aside from continued OSS license changes and forks, a happy community moment happened with We Hack Purple joining forces with Semgrep.
🛡️ DevSecOps ¶
Daniel Bodky shared a great read about The Good, the Better, and the Ugly - Signing Git Commits. The good is called gitsign, the best is SSH Commit signing, and the ugly is – you guessed it - GPG.
If you have tried convincing the GPG agent to sign Git commits with TTY, you probably know the pain. I switched to SSH key commit signing some months ago, see the configuration in dotfiles repository: .gitconfig and allowed_signers
What’s Hurl? ¶
The Hurl maintainers revamped their tutorial pages with a playful web demo which makes it easier to get started with the first command line tests.
Hurl allows you to test websites for specific requests and responses and can also be helpful in CI/CD test automation. I wrote a blog post in late 2022 about Hurl and GitLab CI/CD.
Platform Engineering - Introduction de Stéphane Robert
¶
Après DevOps, Site Reability Engineering, voilà qu’on nous parle de Plateform Engineering. Mais de quoi s’agit-il ?
Qu’est ce que le Platform Engineering ?
Je vais m’appuyer sur le site de la communauté platformengineering.org
Voici la définition qu’on y retrouve : “Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations…”
En français, c’est donc une discipline dont l’objectif est de concevoir et de construire des chaînes d’outils et des flux de travail qui permettent de mettre à disposition des organisations d’ingénierie logicielle des environnements à la demande, leur permettant ainsi de travailler plus efficacement et de manière autonome.
On peut lire aussi que cette discipline est né des cendres du DevOps. Mais comment ça le DevOps est mort ?
Retour sur le DevOps
En écrivant ce billet, je me rends compte que je n’ai publié la suite de mes posts sur le DevOps suite à mon billet sur les racines du DevOps qui ont fait naître ce mouvement.
D’ailleurs, on remarque tout de suite la différence avec le Platform Engineering qui possède un site officiel pour sa communauté.
Lui,le DevOps est plus un mouvement culturel qu’une norme, on ne trouve pas de définition officielle.
Et pour cela que Lucas Galante, qui a rédigé cette définition du PlatForm Engineering, a tiré ce constat : Le DevOps n’étant pas une norme, cela a laissé place à beaucoup d’interprétations qui sont devenus pour la plupart des anti-patterns.
Pour rappel, l’objectif principal du DevOps au sein d’une entreprise est d’améliorer la création de valeur pour les clients et l’entreprise.
Ce n’est donc pas en soi un moyen de réduire les coûts, dont l’objectif est de tout automatiser et de tout piloter avec de la gestion de configuration …
Les anti patterns du Devops
Matthew Skelton et Manuel Pais ont ainsi recensé la plupart de ces anti-patterns. Vous pouvez les retrouver ici:
-
Le DevOps coincé entre les Dev et les Ops
-
le NoOps des Dev qui n’ont pas besoin d’Ops
-
le Devops qui est q’un outil
-
le SysOps dont on a juste changé le nom en DevOps,
-
L’Ops intégré dans l’équipe Dev,
-
…
Ils ne font pas que recenser des anti-types, mais des solutions pour intégrer correctement la démarche DevOps :
-
collaboration entre les Dev et Ops (le vrai DevOps)
-
Responsabilités partagées entre les Dev et les Ops,
-
Ops en tant que PAAS,
-
…
Le Platform Engineering c’est… ¶
Le DevOps n’est pas mort, Platform Engineering propose plutôt de l’implémenter correctement.
En traitant la plateforme de développement comme un produit, une Platform As A service, en se concentrant sur ce qui apporte une valeur réelle à nos clients internes, les développeurs d’applications entre autre.
Le Platform Engineering consiste à concevoir, développer et gérer des plateformes techniques délivrant un ensemble de services et d’outils permettant aux développeurs de travailler de manière efficace.
Conclusion ¶
J’ai été le premier à crier “au loup” quand on m’a parlé de Platform Engineering .
Je me disais que le DevOps en soi suffisait. Mais force est de constater que c’est devenu du grand n’importe quoi.
Suite à mes nombreuses déconvenues, je reconnais mon erreur.
Je pense que nous devons redéfinir clairement les choses pour construire sur des bases solides.
Comment démarrer ? ¶
Comme pour le DevOps, nous utiliserons la fameuse boucle de rétroaction dont l’objectif est de rendre la route des équipes de développement la plus lisse possible.
Dans un premier temps, il convient de lister tous les pavés et de les traiter en priorisant ceux qui apportent le plus de valeur.
Quelques exemples :
Comment je déploie un environnement qui me permette de développer mon application dans des conditions proches de la réalité ?
J’ai vérolé mon environnement comment je le reconstruis en peu de temps ?
Pour tester mon API, j’ai besoin de valider que je respecte le contrat que j’ai avec d’autres outils. Mais voilà cet outil n’est pas disponible dans mon environnement. Existe t’il un mock ?
Ce sont sur ce genre de pavés (Paved Roads) que les Platform Engineers doivent travailler pour que la route semée de pavés devienne un chemin doré (Golden Paths).