DEV Community: Benjamin Marsteau

Architecting "Agentic" systems at the edge: an analysis of the Cloudflare platform

Benjamin Marsteau — Tue, 09 Dec 2025 10:55:02 +0000

Introduction: The End of Lonely Inference, Eh?

2025 marks a massive breakaway in distributed architecture. We are witnessing the slow death of the classic "Request-Response" model for AI, making way for autonomous, persistent, and asynchronous agentic systems.

Let's be honest: the old "Stateless Serverless" paradigm—looking at you, AWS Lambda and ephemeral containers—is about as useful for modern AI agents as a screen door on a submarine. Modern agents need long-term contextual memory, real-time state coordination, and execution that lives close to the user, not in some datacenter five provinces away.¹

This report isn't just a fluff piece; it's a comprehensive technical teardown of Cloudflare's answer to this mess. Far from being a random bag of tools, their "Developer Platform" is a coherent attempt to rebuild the AI execution stack by moving compute, state, and memory to the Edge. We're gonna look under the hood at Durable Objects, the Infire engine, and see if this stack can actually go toe-to-toe with the big hyperscalers (AWS, GCP) and the inference keeners (Groq, Pinecone).

Grab a double-double, let's dig in. ☕

Inference Infrastructure: Deconstructing "Infire" and Latency

Running AI at the Edge isn't just about scattering GPUs across the map like Timbits. It requires a complete re-engineering of the software stack to maximize constrained resources and minimize Time to First Token (TTFT).

Infire: Rust and the CUDA "Hat Trick"

Cloudflare pulled a power move by dumping generic Python/C++ inference servers for Infire, their proprietary engine written in Rust.² This was a necessary play to serve massive models (like Llama 3.1) on the Edge without burning through cash.

Here's the "secret sauce" that makes Infire faster than a slapshot:

Granular CUDA Graphs & JIT: Instead of launching GPU kernels sequentially (which drags), Infire creates a dedicated "CUDA graph" for every possible batch size on the fly. Conceptually, this lets the driver replace a series of kernel launches with a single monolith structure. It cuts down the CPU overhead drastically—a huge deal on powerful cards like the H100.³

Paged KV Caching: Managing Key-Value (KV) cache memory is the bottleneck for LLM throughput. Infire breaks the memory needed for each request into non-contiguous blocks (pages). This eliminates fragmentation and allows for aggressive "continuous batching" without messing up individual latency.

The Rust Advantage: By ditching Python's GIL (Global Interpreter Lock) and avoiding garbage collector pauses, Infire guarantees stable tail latency. Internal benchmarks show Infire finishes inference tasks up to 7% faster than vLLM 0.10.0 on unloaded H100s, with ~82% lower CPU usage (Infire uses 25% CPU compared to vLLM's >140%).³ That's pure efficiency, bud.

Fighting the "Cold Start" (The Block Heater Approach)

We all know the pain of serverless "cold starts." Waiting for a container to wake up is like trying to start your car at -40°C without a block heater.

Cloudflare deployed a routing strategy called "Shard and Conquer" to fix this.⁴

The Mechanism: Instead of random load balancing, they use a consistent hash ring to route traffic for a specific Worker to a specific subset of machines ("shards").
Architectural Impact: This maximizes the chance that a V8 Isolate is already "warm" (memory loaded, DB connection open).
The Result: Cloudflare claims a sustained 99.99% warm request rate, reducing cold starts by a factor of 10.⁵ Basically, the engine is always running and the cabin is toasty.

The Tale of the Tape: Workers AI vs. The Big Guys

Critical Metric	Cloudflare Workers AI	AWS Bedrock	Groq (LPU)	The "Tech-Savvy" Verdict
Time To First Token (TTFT)	Decent. Optimized by the Edge network, but limited by general-purpose GPUs.	Variable. Depends on the service tier and region. Intrinsic network latency due to centralization.	Insane. Their LPU architecture (SRAM-based) delivers unbeatable speeds (e.g., 0.14s on Llama 70B).⁶	For pure speed (voice agents), Groq wins. For text/multimodal, Cloudflare is solid.
Cost Model	Neurons/Usage. Granular billing based on compute. Ideal for sporadic workloads.	Complex. On-Demand (pricey) vs Provisioned Throughput (expensive commitment).	Token-based. Aggressive pricing to gain market share, but long-term viability is TBD.	Cloudflare offers predictability. AWS is for when you have corporate budget to burn.⁷
Data Locality	Edge. Inference runs physically near the user. Huge plus for GDPR/Sovereignty.	Regional. Data has to travel to us-east-1 or eu-central-1.	Centralized. Proprietary hardware in centralized hubs.	Cloudflare has a unique advantage for sovereignty-sensitive apps.

"Stateful Serverless": Durable Objects as Agent Primitives

The biggest innovation for AI agents here isn't the AI—it's the memory. Durable Objects (DO) reintroduce the Actor Model to infrastructure, solving the "agent memory" problem without the headache of managing a Redis cluster.¹

Anatomy of a Durable Object for AI

Think of a DO as a tiny, persistent micro-server that's globally addressable.

Zero-Latency SQLite: This is a game-changer. A DO has a built-in SQLite database. No expensive TCP/SSL handshake to a remote RDS. It executes SQL queries in local memory or on local SSD.⁸ This means insane read/write speeds for your agent's state (conversation history, plans, context).
WebSocket Coordination: A single DO can handle thousands of concurrent WebSocket connections. For a collaborative agent (e.g., multiple users talking to the same assistant), the DO acts as the quarterback, syncing everything without complex distributed locking.¹
The "Alarm" Pattern: Agents need to wake up on their own. DOs have setAlarm, allowing an agent to schedule its own future execution ("Wake me up in 10 mins to check that API"). This is essential for autonomous agents running long-term tasks.¹

The "Gotchas" (Don't be a Hoser)

Even the best tools have limits. Here's how not to mess it up:

Single-Threaded: Like Node.js, a DO is single-threaded. If you run heavy CPU tasks (like parsing a massive JSON or heavy encryption), you'll block every request to that object. Workaround: Offload the heavy lifting to a standard stateless Worker.

Storage Limits: You get 10GB per object.¹⁰ It's not a Data Lake, eh? Don't treat it like one. Store references (pointers) to R2 (Object Storage) or Vectorize, not the raw data.

Fixed Locality: Once created, a DO lives in a specific datacenter. If your user flies to the other side of the world, latency increases.

Semantic Memory & RAG: Analyzing Vectorize

Your agent needs to remember context (RAG). That's where Vectorize comes in.

Architecture of Vectorize

Vectorize isn't just another vector DB; it's designed for the Edge. It lets Workers query embeddings without the network latency of calling a third-party service like Pinecone (usually stuck in us-east-1).¹¹

Comparative Matrix: Vectorize vs. The Rest

Feature	Cloudflare Vectorize	Pinecone	pgvector (PostgreSQL)	Expert Verdict
Network Latency	Minimal. Internal RPC call from the Worker.	Medium. HTTP/gRPC latency to the cloud provider.	Variable. Depends on hosting (Supabase, Neon).	Vectorize wins on pure latency for Edge apps.
Indexing Speed	Asynchronous indexing. Optimized for fast reads.	High performance, proprietary algos.	Depends on extension (HNSW, IVFFlat). pgvectorscale beats Pinecone on some benchmarks.¹²	Pinecone leads on brute force performance at scale, but pgvector is catching up.
Features	Limited. Basic semantic search. Simple metadata filtering.	Rich. Hybrid search, Reranking, Unlimited namespaces.	Exhaustive. Full SQL, complex JOINS, ACID compliance.	Vectorize is still a "young buck". If you need complex hybrid queries, stick with pgvector.¹³
Cost	Predictable. Based on stored/queried dimensions. Included in Workers plans.¹¹	High. Billed by Pod or Read/Write units.	Variable. Instance + Storage costs.	Vectorize often has a lower TCO for mid-sized projects (no egress fees).

Insight: The word on the street (Reddit) is that Vectorize is still a bit green on metadata filtering compared to Weaviate or Qdrant.¹⁴ For enterprise RAG needing granular RBAC filtering, pgvector on D1 might be the safer bet for now.

Agent Frameworks & Standardization: MCP

Cloudflare isn't just building the rink; they're defining the rules of the game.

Cloudflare Agents SDK

The cloudflare/agents SDK gives you a structured way to deploy agents on Durable Objects. It abstracts away the WebSocket and SQL complexity, giving you "ready-to-use" primitives for memory and tool calling.¹⁵

Model Context Protocol (MCP): Playing Nice with Others

Cloudflare is going all-in on MCP, an open standard for connecting AI assistants to data systems.

Workers as MCP Servers: You can deploy a Worker as an MCP server, exposing APIs and data as "tools" for MCP clients (like Claude Desktop).
Security Architecture: They solved the biggest MCP headache: auth. Via workers-oauth-provider, a Cloudflare-hosted MCP server handles OAuth natively. This positions Cloudflare as the secure "broker" between LLMs and your private data (SaaS, internal APIs).¹⁶

Security & Governance: The Bouncer at the Door

Deploying agents without security is like leaving your front door unlocked in bear country.

AI-SPM: Shining a Light on "Shadow AI"

Companies are losing control over AI usage. Cloudflare uses its network position (Gateway/WARP) to offer AI Security Posture Management (AI-SPM).

Passive Detection: It sniffs out traffic to known and unknown AI services.
Governance: It applies policies like "Block uploading PII to public chatbots." It's basically a radar for your network.¹⁸

Firewall for AI: WAF for LLMs

This sits in front of your models.

Prompt Analysis: It scans JSON payloads for prompt injection attacks ("Ignore all previous instructions...") and toxic content.
Mechanism: It uses lightweight models (like Llama Guard) to score requests in real-time before they hit the expensive model. It saves you money by rejecting bad requests early.¹⁹

Economic Analysis: The Baselime Case Study

Let's talk loonies and toonies. The acquisition of Baselime by Cloudflare gives us hard data on the savings.²⁰

Cost Breakdown (Annualized)

They slashed their bill from $708,100 (AWS) to $118,625 (Cloudflare). That's an 83% reduction.

Component	AWS Cost (Old)	Cloudflare Cost (New)	Reduction	Root Cause Analysis
Compute	$237,250 (Lambda)	$9,125 (Workers)	~96%	Billing Model. Lambda charges for "Wall-clock time" (including waiting for DBs). Workers charges for active CPU time. For I/O-heavy agents, this is massive.
CDN	$51,100 (CloudFront)	$0 (Included)	100%	CDN is native and included. No extra line item.
Data	$419,750 (Kinesis/EC2)	$109,500 (Analytics Engine)	~74%	Replacing a self-managed ClickHouse cluster on EC2 with a serverless managed service.

Strategic Insight: This proves that for I/O-bound workloads (like AI orchestration), Cloudflare's economic model is structurally superior to AWS Lambda.

Pay-per-Crawl: New Rules for the Web (x402)

Bots are scraping the web to train AI, often for free. Cloudflare introduced a protocol innovation: Pay-per-crawl based on HTTP 402.²¹

The Problem: Sites block AI bots to save bandwidth/IP, creating a "dark web" for LLMs.
The Solution (x402): A Worker returns HTTP 402 Payment Required. The bot can replay the request with a payment token.
Impact: Cloudflare acts as the "Merchant of Record." It turns a fight into a marketplace, letting agents buy high-quality real-time data.

Synthesis and Final Recommendations

Architectural Decision Matrix

Scenario	Recommended Architecture	Technical Justification
Conversational Agent (SaaS)	Full Cloudflare (DO + Workers AI)	Durable Objects are mandatory for WebSocket coordination and session state. Infire is good enough for standard inference.
Complex Enterprise RAG	Workers + Pinecone/Supabase	Vectorize is too limited for complex metadata filtering (RBAC). Use Workers for orchestration, but a mature vector DB for storage.
Real-Time Voice AI	Workers + Groq	Cloudflare's inference latency might be too high for voice. Use Workers for logic, Groq for speed.
Heavy Batch Processing	AWS (Fargate) or Modal	Worker limits (CPU time/RAM) make heavy batch jobs (ingesting thousands of PDFs) risky.

Conclusion: The "Cloud of Agents"

Cloudflare has successfully built the first true "Serverless Cloud" for the AI Agent era. By vertically integrating Compute (Workers), State (Durable Objects), Memory (Vectorize), and Inference (Infire), they've removed the "integration tax" that makes AWS/GCP a headache.

For the seasoned pro, it's not perfect: the ecosystem is closed (Vendor Lock-in on DOs is real), and some tools like Vectorize are still maturing. But if you want to build distributed, performant, and economically viable agentic systems in 2025, Cloudflare offers the best bang for your buck. You just have to shift your mindset: stop thinking "servers" and "databases," and start thinking "distributed objects" and "event streams."

So, give'r. Start coding, and keep your stick on the ice. 🏒

Works Cited

A list of reasons why you should be using Cloudflare Workers for building your AI agent infrastructure/product/personal assistant - Sunil Pai, accessed December 7, 2025, https://sunilpai.dev/posts/cloudflare-workers-for-ai-agents/
AI Week 2025 - Updates and announcements - Cloudflare, accessed December 7, 2025, https://www.cloudflare.com/innovation-week/ai-week-2025/updates/
How we built the most efficient inference engine for Cloudflare's ..., accessed December 7, 2025, https://blog.cloudflare.com/cloudflares-most-efficient-ai-inference-engine/
Eliminating Cold Starts 2: shard and conquer - The Cloudflare Blog, accessed December 7, 2025, https://blog.cloudflare.com/eliminating-cold-starts-2-shard-and-conquer/
Cloudflare Achieves 99.99% Warm Start Rate for Workers with 'Shard and Conquer' Consistent Hashing - InfoQ, accessed December 7, 2025, https://www.infoq.com/news/2025/10/workers-shard-conquer-cold-start/
AWS Bedrock vs Groq: Picking the Right AI Inference Engine for Your Workloads - Medium, accessed December 7, 2025, https://medium.com/@cloudshim/aws-bedrock-vs-groq-picking-the-right-ai-inference-engine-for-your-workloads-f1eb2a795856
New Amazon Bedrock service tiers help you match AI workload performance with cost, accessed December 7, 2025, https://aws.amazon.com/blogs/aws/new-amazon-bedrock-service-tiers-help-you-match-ai-workload-performance-with-cost/
Durable Objects on Workers Free plan · Changelog - Cloudflare Docs, accessed December 7, 2025, https://developers.cloudflare.com/changelog/2025-04-07-durable-objects-freetier/
Overview · Cloudflare Durable Objects docs, accessed December 7, 2025, https://developers.cloudflare.com/durable-objects/
Limits · Cloudflare Durable Objects docs, accessed December 7, 2025, https://developers.cloudflare.com/durable-objects/platform/limits/
Vectorize: a vector database for shipping AI-powered applications to ..., accessed December 7, 2025, https://blog.cloudflare.com/vectorize-vector-database-open-beta/
Pgvector vs. Pinecone: Vector Database Performance and Cost Comparison - Tiger Data, accessed December 7, 2025, https://www.tigerdata.com/learn/pgvector-vs-pinecone
CloudFlare is the cheapest + fastest option for Cloud Computing... yet the slowest and most expensive option for Artificial Intelligence - Reddit, accessed December 7, 2025, https://www.reddit.com/r/CloudFlare/comments/1olswdi/cloudflare_is_the_cheapest_fastest_option_for/
cloudflare Vectorize comparison (eg w PgVector) : r/vectordatabase - Reddit, accessed December 7, 2025, https://www.reddit.com/r/vectordatabase/comments/1h51nel/cloudflare_vectorize_comparison_eg_w_pgvector/
cloudflare/agents: Build and deploy AI Agents on Cloudflare - GitHub, accessed December 7, 2025, https://github.com/cloudflare/agents
Build a Remote MCP server · Cloudflare Agents docs, accessed December 7, 2025, https://developers.cloudflare.com/agents/guides/remote-mcp-server/
Build and deploy Remote Model Context Protocol (MCP) servers to Cloudflare, accessed December 7, 2025, https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/
AI Security Suite | Securely scale AI adoption - Cloudflare, accessed December 7, 2025, https://www.cloudflare.com/ai-security/
Firewall for AI - Cloudflare, accessed December 7, 2025, https://www.cloudflare.com/application-services/products/firewall-for-ai/
Moving Baselime from AWS to Cloudflare: simpler architecture, improved performance, over 80% lower cloud costs, accessed December 7, 2025, https://blog.cloudflare.com/80-percent-lower-cloud-cost-how-baselime-moved-from-aws-to-cloudflare/
Launching the x402 Foundation with Coinbase, and support for x402 transactions, accessed December 7, 2025, https://blog.cloudflare.com/x402/

Advent of Tech @ Onepoint x Wepoint 2025

Benjamin Marsteau — Mon, 01 Dec 2025 05:30:00 +0000

Bienvenue à l'Advent of Tech @ Onepoint x Wepoint 2025!

Retrouvez ci-dessous la liste des articles publiés durant tout ce mois de décembre :

Platform Engineering : découvrez la puissance de Backstage.io

Benjamin Marsteau — Thu, 19 Dec 2024 08:15:00 +0000

Les environnements techniques modernes s’apparentent souvent à des labyrinthes : une multitude de microservices, des pipelines CI/CD dispersés, des outils divers et une documentation souvent inaccessible ou obsolète.
Pour les développeurs, cela signifie des interruptions constantes, des recherches interminables et une perte de productivité.

Face à ce chaos, le Platform Engineering s’impose comme une solution clé : créer des plateformes internes qui simplifient l’accès aux outils, standardisent les processus et libèrent les développeurs de la complexité technique inutile.
Au cœur de cette transformation se trouve Backstage.io, une plateforme open-source conçue par Spotify, devenue l’un des piliers de cette discipline.

Cet article vous propose une explication sur ce qu'est le Platform Engineering et explorera les rouages de Backstage.io, ses fonctionnalités, ses cas d’utilisation réels et les bénéfices qu’il apporte à des entreprises de toutes tailles.

Qu'est-ce que le Platform Engineering ?

Le Platform Engineering représente l'art de construire et de maintenir des plateformes self-service pour les développeurs. Imaginez une "méta-plateforme" qui unifie tous vos outils, workflows et bonnes pratiques en une expérience cohérente et automatisée.
C'est comme avoir un concierge numérique qui s'occupe de toute la plomberie technique, permettant aux développeurs de se concentrer sur ce qui compte vraiment : créer de la valeur métier.

Dans un environnement technologique en constante évolution, les entreprises font face à plusieurs défis majeurs :

Fragmentation des outils : La multiplication des outils et services peut créer des silos d’information, rendant difficile la collaboration et la gestion efficace des projets.
Incohérences dans les processus : Sans standardisation, les équipes peuvent adopter des pratiques divergentes, entraînant des erreurs et une diminution de la qualité du produit final.
L'explosion de la complexité technique : Kubernetes, microservices, cloud-native... Les architectures modernes sont devenues si complexes que même les développeurs expérimentés peinent à tout maîtriser.
La quête d'agilité à l'échelle : Les entreprises cherchent à accélérer leur développement tout en maintenant qualité et sécurité. Sans plateforme unifiée, c'est mission impossible.
Le coût de la friction technique : Chaque heure passée à lutter contre les outils ou à chercher de la documentation est une heure non consacrée à l'innovation.

Le Platform Engineering promet un changement radical dans la manière dont les équipes travaillent en visant à résoudre ces problèmes par la création de plateformes internes qui unifient les outils, standardisent les processus et simplifient la gestion de l’infrastructure.

Fini les semaines d'onboarding pour comprendre l'infrastructure. Exit les documentations obsolètes éparpillées dans différents systèmes. Terminé les configurations manuelles sources d'erreurs.

À la place, une expérience fluide où tout est accessible, documenté et automatisé.

Backstage.io : La promesse d'une solution

En 2016, Spotify fait face à une explosion de services : microservices, pipelines CI/CD, monitoring, alertes… Les développeurs passent plus de temps à naviguer dans cet écosystème qu’à écrire du code. Pour centraliser ces outils et simplifier l’expérience développeur, Spotify développe Backstage, un portail interne qui devient rapidement le cœur de son infrastructure technique.

Plus qu'un simple outil, il incarne la philosophie même du Platform Engineering : centraliser, standardiser et automatiser pour libérer la créativité des développeurs.
Comme l'explique un ingénieur de Spotify : "Nous avons créé Backstage parce que nous avions besoin d'une plateforme qui unifie tous nos outils et standardise la manière dont nous construisons nos logiciels. Ce qui était initialement un projet interne est devenu une solution open-source que toute entreprise peut adopter."

En 2020, le projet devient open source sous l'égide de la Cloud Native Computing Foundation (CNCF), rejoignant ainsi la famille de projets prestigieux comme Kubernetes et Prometheus.

Les piliers de Backstage

Le Software Catalog

Le software catalog agit comme le point névralgique de votre écosystème technique, ce n'est pas un simple inventaire. C'est une source de vérité vivante qui modélise l'intégralité de votre architecture technique.

Il répond à des questions essentielles : Quels services sont en production ? Qui est responsable de ce composant ? Quelles sont les dépendances de cette API ?

Le software catalog permet de centraliser tous les services, applications, outils et composants logiciels d’une organisation.
Cela inclut les microservices, les bibliothèques internes, les pipelines CI/CD et bien plus encore.

Sous le capot :
• Modèle basé sur YAML : Chaque service est décrit par un fichier YAML contenant des métadonnées comme le propriétaire, le type de service, son environnement (production, staging) et ses dépendances.
• Backend extensible : Le catalogue est propulsé par un backend qui interagit avec les API des outils tiers (par ex., Kubernetes, GitHub, Jenkins) pour collecter des informations dynamiques.
• Recherche et filtrage : Les services peuvent être recherchés et filtrés en fonction de critères spécifiques, grâce à une API GraphQL intégrée.

Exemple d’intégration :
Un microservice hébergé sur Kubernetes peut être enregistré dans Backstage avec un fichier YAML semblable à ceci :

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: orders-service
  description: Microservice de gestion des commandes
  tags:
    - ecommerce
    - orders
spec:
  type: service
  owner: team-ecommerce
  lifecycle: production

Ce fichier est ensuite chargé dans le catalogue via des pipelines CI/CD ou manuellement, rendant le service immédiatement visible et accessible aux développeurs.

Scaffolding : Générer des projets standardisés en un clic

Le scaffolding de Backstage utilise des templates prédéfinis pour créer des projets avec une structure, des pipelines et une configuration cohérente.

Détails techniques :
• Templates en Markdown : Les templates sont définis dans des fichiers .yaml et contiennent des variables dynamiques pour personnaliser chaque projet.
• Commandes personnalisées : Les actions de scaffolding peuvent inclure des commandes shell, des scripts Node.js ou des workflows spécifiques, comme la création de dépôts Git ou le déploiement initial.
• Hooks d’intégration : Une fois le projet généré, le scaffolding peut déclencher des actions comme l’enregistrement automatique dans le catalogue ou le provisionnement d’environnements dans Kubernetes.

Exemple de template :

Un template pour un microservice Node.js pourrait ressembler à ceci :

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: nodejs-service-template
  title: Node.js Service
  description: Crée un nouveau microservice Node.js avec une structure standardisée
spec:
  owner: team-devops
  type: service
  steps:
    - id: fetch-repository
      name: Clone un template Git
      action: git:clone
      input:
        repoUrl: https://github.com/company/templates/node-service
        targetPath: ./project
    - id: update-metadata
      name: Mise à jour des métadonnées
      action: run:script
      input:
        script: ./scripts/update-metadata.sh

Les templates offrent de nombreuses capacités :

Actions Préconfigurées
- Création de repositories
- Configuration des pipelines CI/CD
- Mise en place du monitoring
- Initialisation des secrets
Personnalisation
- Formulaires dynamiques
- Validations personnalisées
- Actions custom pour besoins spécifiques
Intégrations
- GitHub/GitLab
- Jenkins/CircleCI
- Kubernetes
- AWS/GCP/Azure

TechDocs : La documentation vivante de Backstage.io

La documentation technique est souvent le talon d’Achille des environnements complexes : elle est difficile à maintenir à jour, éparpillée dans plusieurs outils, et rarement consultée par les développeurs.
Backstage.io adresse ce problème avec TechDocs, une fonctionnalité native qui transforme la documentation en une ressource vivante, directement intégrée à la plateforme.

TechDocs est un système de documentation basé sur le moteur MkDocs, qui convertit du contenu en Markdown en une documentation web. Il s’intègre parfaitement avec le catalogue de services de Backstage pour fournir une documentation contextuelle, directement liée aux services, composants et outils qu’elle décrit.

Comment TechDocs fonctionne-t-il ?

1. Format Markdown standardisé

Les documents TechDocs sont écrits en Markdown, un format léger et universel, ce qui facilite la contribution des développeurs. Chaque projet peut inclure un répertoire dédié à la documentation technique, généralement nommé docs/.

Exemple de structure de documentation pour un microservice :

project-root/
  ├── docs/
  │    ├── index.md
  │    ├── architecture.md
  │    ├── api-reference.md
  ├── src/
  ├── package.json
  ├── Dockerfile

2. Génération automatique de documentation

TechDocs s’appuie sur MkDocs, qui génère un site web statique à partir des fichiers Markdown. Ce site est automatiquement hébergé et consultable via l’interface de Backstage.

Pipeline typique :

Les fichiers Markdown sont créés ou mis à jour dans le dépôt Git du service.
Une étape du pipeline CI/CD exécute MkDocs pour générer les fichiers HTML.
Les fichiers sont publiés dans un backend (comme S3 ou GCS) et accessibles depuis Backstage.

3. Intégration contextuelle

Chaque service du catalogue peut inclure un lien direct vers sa documentation TechDocs. Cela signifie que lorsqu’un développeur consulte un service dans Backstage, il a immédiatement accès à sa documentation technique.

Exemple d’intégration YAML :

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: orders-service
  annotations:
    backstage.io/techdocs-ref: url:https://github.com/company/orders-service/blob/main/docs/

4. Fonctionnalités avancées de TechDocs :

Prévisualisation en temps réel

Grâce à l’intégration avec le dépôt Git, TechDocs permet de prévisualiser la documentation avant sa publication, ce qui réduit les erreurs et garantit la qualité.
Support multi-langues

Pour les organisations internationales, TechDocs supporte le multi-langues en utilisant des fichiers Markdown séparés pour chaque langue.
Recherche intégrée

TechDocs inclut un moteur de recherche basé sur Elasticsearch, permettant aux utilisateurs de rechercher des termes clés dans toutes les documentations disponibles.

L'écosystème des plugins

Si Backstage brille par ses fonctionnalités de base, ce sont ses plugins qui en font une plateforme véritablement transformative. Imaginez Backstage comme un système d'exploitation : puissant dans sa version de base, mais c'est la capacité à installer des "applications" supplémentaires qui en révèle tout le potentiel.

La philosophie des plugins chez Backstage

L'approche de Spotify avec les plugins Backstage reflète une profonde compréhension des besoins des équipes de développement modernes. Au lieu de créer une plateforme monolithique qui tenterait de tout faire, ils ont opté pour un système modulaire où chaque entreprise peut construire son propre "app store" interne, adapté à ses besoins spécifiques.

Cette flexibilité n'est pas un accident. Elle découle directement de l'expérience de Spotify qui, confronté à la diversité des besoins de ses équipes, a compris qu'aucune solution unique ne pourrait satisfaire tout le monde. La beauté du système de plugins réside dans sa capacité à évoluer organiquement avec votre organisation.

Les plugins essentiels : un écosystème riche et mature

Parmi les dizaines de plugins disponibles, certains se distinguent par leur capacité à transformer radicalement l'expérience développeur.

Prenons l'exemple du plugin GitHub Actions. Son intégration va bien au-delà d'un simple tableau de bord de CI/CD. Il crée un lien direct entre votre code et vos déploiements, permettant aux développeurs de suivre le parcours complet d'une fonctionnalité, de l'idée à la production.

Le plugin Kubernetes illustre parfaitement cette approche. Plutôt que de simplement afficher l'état de vos clusters, il contextualise ces informations. Un développeur peut voir non seulement si son service est en bonne santé, mais aussi comprendre immédiatement l'impact sur les services dépendants. Cette contextualisation transforme des données brutes en insights actionnables.

La surveillance applicative prend une nouvelle dimension avec des plugins comme Grafana ou New Relic. Ces intégrations ne se contentent pas d'afficher des graphiques : elles créent des ponts entre les différentes perspectives de votre application. Un développeur peut passer seamlessly d'un problème de performance détecté dans New Relic aux logs correspondants, puis au code source concerné, le tout sans quitter l'interface Backstage.

L'art de la personnalisation : créer ses propres plugins

La vraie magie opère lorsque les organisations commencent à développer leurs propres plugins. Prenons l'exemple d'une grande banque européenne qui a créé un plugin de conformité réglementaire. Ce plugin analyse automatiquement les services répertoriés dans le catalogue pour vérifier leur conformité avec les normes bancaires, transformant un processus autrefois manuel et fastidieux en une vérification continue et automatisée.

La création d'un plugin n'est pas réservée aux géants de la tech. Une startup de la foodtech a par exemple développé un plugin qui intègre leur système de gestion des recettes directement dans Backstage. Les développeurs peuvent maintenant voir l'impact de leurs changements techniques sur le catalogue de recettes en temps réel, créant un pont précieux entre l'équipe technique et l'équipe produit.

L'avenir des plugins : Une communauté en croissance

La communauté Backstage continue d'innover. Les dernières tendances montrent un intérêt croissant pour les plugins axés sur la sécurité et la gouvernance des données. Des entreprises développent des plugins qui automatisent les revues de sécurité, surveillent la conformité RGPD, ou encore analysent l'empreinte carbone des services déployés.

Cette évolution reflète une tendance plus large dans l'industrie : la nécessité de gérer non seulement la complexité technique, mais aussi les implications éthiques et sociétales du développement logiciel.

Retours d'expérience : Backstage en action

Expérience Spotify : Le berceau de Backstage

Tout a commencé chez Spotify face à un défi majeur : gérer plus de 200 équipes d'ingénierie travaillant sur des milliers de composants. Avant Backstage, les développeurs passaient en moyenne un jour par semaine à chercher des informations ou à configurer des outils. Après son implémentation, ce temps a été réduit à quelques heures, permettant aux équipes de se concentrer sur l'innovation plutôt que sur la maintenance.

"Avant Backstage, chaque équipe avait sa propre façon de faire les choses", explique Stefan Ålund, responsable du projet chez Spotify. "Maintenant, un nouveau développeur peut commencer à coder dès le premier jour, avec tous les outils et la documentation nécessaires à portée de main."

DAZN : transformation d'une plateforme de streaming

Le cas de DAZN, plateforme de streaming sportif, est particulièrement instructif.
Confrontée à une croissance rapide et à des pics de trafic imprévisibles lors d'événements sportifs majeurs, l'entreprise a déployé Backstage pour unifier sa plateforme technique.

Leur approche s'est faite en trois phases :

Centralisation du catalogue En six mois, ils ont répertorié plus de 300 microservices dans le Software Catalog. "La simple visualisation de notre architecture a révélé des redondances que nous n'avions jamais remarquées auparavant", témoigne leur Lead Architect.
Standardisation des Déploiements Les Templates ont permis de réduire le temps de création d'un nouveau microservice de 2 jours à 45 minutes. Plus important encore, chaque service suit maintenant automatiquement les meilleures pratiques en matière de monitoring et de sécurité.
Documentation Vivante "La documentation n'est plus un fardeau mais une partie intégrante de notre workflow", explique leur Tech Lead. Grâce à TechDocs, les équipes maintiennent naturellement leur documentation à jour, car elle vit directement avec le code.

Monzo Bank : Sécurité et conformité

L'exemple de Monzo Bank illustre comment Backstage peut s'adapter aux exigences strictes du secteur financier. La banque digitale britannique a développé des plugins personnalisés pour :

Automatiser les revues de sécurité des nouveaux services
Tracer les accès aux données sensibles
Générer des rapports de conformité réglementaire

"Ce qui nous a surpris", raconte leur Head of Platform, "c'est comment Backstage a transformé notre culture de la sécurité. Les développeurs ne voient plus la sécurité comme un obstacle mais comme une fonctionnalité intégrée."

Les limites et challenges : Un regard lucide sur Backstage

La mise en place de Backstage, comme tout projet d'envergure, ne se fait pas sans obstacles. Si la promesse est séduisante, il est crucial d'aborder avec lucidité les défis qu'une organisation devra surmonter pour réussir son implémentation.

Le défi de l'adoption

L'un des premiers obstacles est souvent culturel. Comme l'explique Marie Durand, Platform Engineer chez une grande entreprise française du CAC 40 : "Nous avions une superbe plateforme, mais les développeurs continuaient d'utiliser leurs anciens outils. Le plus dur n'est pas la technique, c'est de changer les habitudes."

Cette résistance au changement peut se manifester de plusieurs manières :

Des équipes qui maintiennent leurs propres solutions parallèles
Une documentation qui reste éparpillée malgré la présence de TechDocs
Des développeurs qui contournent les templates standardisés

La clé du succès réside souvent dans une approche progressive et dans la démonstration rapide de valeur ajoutée. Une équipe ayant réussi son adoption témoigne : "Nous avons commencé par migrer un seul projet, mais en le faisant parfaitement. Le bouche-à-oreille a fait le reste."

La complexité de la maintenance

Backstage est un projet open source en constante évolution. Cette dynamique, si elle apporte régulièrement de nouvelles fonctionnalités, présente aussi des défis :

"Au début, nous pensions qu'il suffisait d'installer Backstage et que tout fonctionnerait comme par magie", raconte Thomas Chen, Tech Lead. "La réalité, c'est qu'il faut une équipe dédiée pour maintenir la plateforme, gérer les mises à jour, et développer les plugins spécifiques à nos besoins."

Les points d'attention incluent :

La gestion des versions et des dépendances
La maintenance des plugins personnalisés
La formation continue des équipes
La surveillance des performances

L'enjeu de la scalabilité

Si Backstage excelle dans la gestion de la complexité, il peut lui-même devenir complexe à grande échelle. Une multinationale du secteur automobile a rencontré des défis inattendus :

"Avec plus de 5000 services dans notre catalogue, nous avons dû repenser notre approche de la performance", explique leur architecte principal. "Les temps de chargement se dégradaient, et la recherche devenait moins efficace."

La solution a nécessité :

L'optimisation de la base de données
La mise en place de systèmes de cache sophistiqués
La révision de l'architecture de certains plugins
L'implémentation d'une stratégie de pagination avancée

La question de la sécurité

Dans un contexte où la sécurité est primordiale, Backstage soulève des questions importantes :

"En centralisant toutes nos informations techniques dans une seule plateforme, nous créons potentiellement un point de vulnérabilité unique", note Sarah Martinez, RSSI. "Il faut une stratégie de sécurité robuste."

Les aspects à considérer incluent :

La gestion fine des permissions
La protection des données sensibles
L'audit des accès
La conformité réglementaire

Le coût caché de la personnalisation

Si Backstage brille par sa flexibilité, cette adaptabilité a un prix. "Chaque plugin personnalisé que nous développons devient une dette technique potentielle", observe un Lead Developer. "Il faut maintenir ces développements, les faire évoluer avec Backstage, former les équipes..."

Le risque est de créer une "usine à gaz" difficile à maintenir. Une entreprise témoigne avoir dû abandonner certains plugins personnalisés car leur maintenance devenait trop coûteuse.

Les pistes de solution

Face à ces défis, plusieurs stratégies émergent :

L'approche progressive
Commencer petit, mais penser grand. Établir une feuille de route claire qui prend en compte les différents challenges.
L'investissement dans l'équipe
Constituer une équipe dédiée avec les compétences nécessaires pour maintenir et faire évoluer la plateforme.
La gouvernance claire
Établir des processus de décision pour l'ajout de nouvelles fonctionnalités et la maintenance des plugins.
La mesure du succès
Mettre en place des métriques claires pour évaluer l'adoption et l'impact de la plateforme.

Ces limites ne remettent pas en cause la valeur de Backstage, mais soulignent l'importance d'une approche réfléchie et structurée dans son adoption. Comme le résume un CTO : "Backstage n'est pas une baguette magique. C'est un outil puissant qui demande un investissement conséquent, mais qui peut transformer radicalement votre organisation si vous l'abordez avec les bons prérequis."

Le coût et le ROI de Backstage : Une analyse pragmatique

Dans le monde du Platform Engineering, la question du retour sur investissement de Backstage ne peut être ignorée. Au-delà de ses atouts techniques, qu'en est-il de son impact financier réel sur les organisations ?

L'investissement : une vue d'ensemble

L'implémentation de Backstage représente un investissement significatif, tant en termes financiers qu'humains. "Beaucoup d'entreprises sous-estiment l'investissement initial", explique Marie Chen, CTO d'une scale-up européenne. "Ce n'est pas tant le coût de l'infrastructure qui pèse, mais plutôt les ressources humaines nécessaires pour faire vivre la plateforme."

Les coûts directs comprennent :

L'infrastructure cloud
Une équipe Platform Engineering dédiée
La formation initiale des équipes

La période de transition : un passage obligé

Les premiers mois suivant l'implémentation peuvent être déstabilisants. "Nous avons observé un ralentissement initial de la productivité", témoigne Thomas Durand, Platform Engineer chez une grande banque française. "C'est normal : les équipes doivent s'adapter à de nouvelles façons de travailler. Mais une fois cette période passée, les gains sont spectaculaires."

Les gains : une triple vague de bénéfices

1. L'onboarding accéléré

La première vague de bénéfices concerne l'intégration des nouveaux développeurs. Une entreprise technologique majeure rapporte une réduction spectaculaire du temps d'onboarding, passant de trois semaines à trois jours. Cette amélioration génère des économies substantielles, estimées à 50 000€ annuels pour une équipe de 50 développeurs.

2. L'efficacité opérationnelle

La deuxième vague touche les opérations quotidiennes :

Réduction de 60% du temps de création de nouveaux services
Diminution de 40% des incidents de configuration
Baisse de 30% des tickets de support technique

3. La qualité globale

"Nous avons observé une amélioration marquée de la qualité du code et de la documentation", rapporte Sarah Martinez, Lead Developer. Les équipes réutilisent davantage de composants existants, et les bonnes pratiques se diffusent naturellement.

Le point d'équilibre : une question de contexte

Le ROI varie considérablement selon la taille et la maturité des organisations :

Grandes équipes (>50 développeurs) : 6-9 mois
Petites équipes (<20 développeurs) : 12-18 mois

Comme le souligne un CTO expérimenté : "Le véritable ROI de Backstage ne se mesure pas uniquement en euros. Comment quantifier la valeur d'une meilleure collaboration entre équipes ? D'une documentation toujours à jour ?"

Stratégies d'optimisation

La clé d'un ROI optimisé réside dans une approche progressive et mesurée :

Démarrer petit, penser grand
Commencer avec les fonctionnalités essentielles, puis étendre progressivement en fonction des retours concrets.
Investir dans la formation
Former des champions internes qui pourront à leur tour former leurs collègues.
Mesurer et adapter
Suivre des métriques clés comme le temps d'onboarding, le nombre d'incidents, et la satisfaction des développeurs.

"Backstage est un marathon, pas un sprint", résume un Platform Engineer chevronné. "L'important n'est pas d'aller vite, mais d'aller loin."

Cette approche équilibrée entre investissement initial et gains progressifs permet aux organisations de maximiser leur retour sur investissement tout en construisant une base solide pour leur future croissance technique.

Conclusion : Backstage, catalyseur de la transformation digitale

Au terme de cette exploration approfondie de Backstage et du Platform Engineering, une chose devient claire : nous assistons à une évolution majeure dans la façon dont les organisations abordent le développement logiciel. Backstage n'est pas simplement un outil de plus dans l'arsenal technologique ; c'est le reflet d'une nouvelle philosophie où l'expérience développeur devient centrale dans la stratégie technique des entreprises.

Une réponse à des enjeux contemporains

La complexité croissante des architectures modernes, la multiplication des outils, et l'accélération des cycles de développement ont créé un besoin urgent de rationalisation. Backstage répond à ces défis en proposant une approche unifiée, où la standardisation n'est pas synonyme de rigidité, mais de liberté encadrée. Comme l'a si bien exprimé un architecte chevronné : "Backstage ne nous dit pas quoi faire, il nous aide à mieux le faire."

Au-delà de l'outil, une transformation culturelle

L'impact le plus profond de Backstage ne réside peut-être pas dans ses fonctionnalités techniques, mais dans sa capacité à transformer la culture organisationnelle. En rendant visible l'invisible, en facilitant la collaboration, et en démocratisant les bonnes pratiques, il crée un environnement où l'innovation peut prospérer de manière durable.

Vers un futur "Developer-Centric"

Le succès de Backstage préfigure peut-être une nouvelle ère dans le développement logiciel, où la productivité des développeurs n'est plus entravée par la friction technique, mais amplifiée par des plateformes intelligentes et intuitives. Comme l'observe un CTO : "Quand vos développeurs passent plus de temps à innover qu'à configurer des outils, vous savez que vous avez fait le bon choix."

Les clés du succès

Pour les organisations qui envisagent d'adopter Backstage, quelques recommandations essentielles émergent de notre analyse :

Commencer avec une vision claire
Ne pas voir Backstage comme une solution miracle, mais comme un enabler de transformation.
Investir dans l'humain
La réussite technique passe par l'accompagnement des équipes et la construction d'une communauté interne.
Rester agile
Adopter une approche itérative, en restant à l'écoute des besoins réels des utilisateurs.

Le mot de la fin

Backstage représente plus qu'une évolution technologique ; c'est une réponse concrète aux défis de la complexité moderne. Son succès grandissant témoigne d'un besoin profond dans l'industrie du logiciel : celui de retrouver de la simplicité dans la complexité, de l'efficacité dans la diversité, et de l'humain dans la technique.

Comme l'a si justement résumé un développeur : "Backstage ne résout pas tous nos problèmes, mais il nous permet de mieux les aborder. Et parfois, c'est exactement ce dont nous avons besoin."

Le voyage vers une plateforme développeur mature est long et semé d'embûches, mais avec des outils comme Backstage et une approche réfléchie du Platform Engineering, il devient non seulement possible mais enrichissant.

Dans un monde où la technologie ne cesse de se complexifier, simplifier l'expérience développeur n'est plus un luxe, c'est une nécessité stratégique.

Pour Aller Plus Loin

Documentation Officielle

Ressources d'Apprentissage

Vidéos et Présentations
- Chaîne YouTube CNCF
- Playlist Backstage Community Sessions
Tutoriels et Guides Pratiques

Communauté et Support

Articles de Référence

Blogs et Publications

Newsletters

Cas d'Usages Officiels

Ressources Techniques

Ces liens sont régulièrement mis à jour par la communauté et constituent une base solide pour approfondir vos connaissances sur Backstage et le Platform Engineering.

Pour rester à jour, je recommande particulièrement de :

Rejoindre le Discord officiel
Suivre le blog Backstage
S'abonner à la newsletter Platform Weekly

Note : Certains liens peuvent nécessiter une mise à jour, la communauté Backstage étant très active.

Cet article fait partie du « Advent of Tech 2024 @ Onepoint », une série d’articles tech publiés par Onepoint pour patienter jusqu’à Noël.
Voir tous les articles du Advent of Tech 2024.

Advent of Tech 2024 @ Onepoint

Benjamin Marsteau — Sun, 01 Dec 2024 15:44:17 +0000

Bienvenue à l'Advent of Tech 2024 de Onepoint!

Retrouvez ci-dessous la liste des articles publiés durant tout ce mois de décembre :

Retour sur le Salon de la Data 2024 de Nantes

Benjamin Marsteau — Wed, 06 Nov 2024 08:36:23 +0000

Le Salon de la Data 2024 à Nantes a rassemblé une multitude de passionnés de la donnée, offrant une richesse d’échanges et de découvertes pour les experts et praticiens du domaine. Cette journée a été rythmée par des conférences variées, où astuces, défis et succès liés à la gestion des données ont été partagés.

Au fil des interventions, l’importance cruciale de la data est apparue comme la pierre angulaire des stratégies de transformation numérique, quels que soient les secteurs. Que ce soit pour optimiser la gestion du trafic maritime sur le Saint-Laurent, automatiser des processus chez Generali ou démocratiser l’accès aux jeux de données en entreprise, la donnée s’impose aujourd’hui comme un levier essentiel.

Cet article propose un tour d’horizon des conférences les plus marquantes et des enseignements à en tirer. Derrière des termes techniques tels que datasets, cloud, ou FinOps, se dessinent des solutions concrètes pour améliorer la performance des organisations. Certaines présentations ont même su ajouter une touche d’humour, prouvant que l’univers de la data peut être à la fois technique et ludique. Place maintenant à une rétrospective de cette journée riche en innovations !

Les 24 Heures du Mans carburent à la Data

La conférence “Les 24 Heures du Mans carburent à la Data”, animée par Jean-Jacques Foignet, met en lumière l’impact de FluxVision, un outil développé par Orange, sur l’analyse de la fréquentation lors de la célèbre course. Plutôt que de s’appuyer exclusivement sur les ventes de billets, FluxVision utilise les données des cartes SIM connectées au réseau mobile d’Orange pour suivre les mouvements des spectateurs pendant l’événement. Contrairement aux méthodes traditionnelles basées sur les applications ou les fonctionnalités des smartphones, cet outil capte uniquement les informations des utilisateurs transitant sur le réseau d’Orange, offrant ainsi une analyse des flux sans nécessiter de paramétrage particulier sur les appareils des visiteurs.

L’intérêt majeur de FluxVision réside dans sa capacité à cartographier en temps réel la provenance des spectateurs, en identifiant notamment les départements d’origine. Cette précision géographique permet de mieux comprendre le profil des participants en comparant les données recueillies aux prévisions basées sur les billets vendus. Par exemple, il devient possible de vérifier si les prévisions de fréquentation concordent avec les données effectives ou de repérer les départements ou régions sous-représentés.

Jean-Jacques Foignet a également souligné le rôle de cet outil dans l’optimisation des dispositifs de sécurité : les autorités locales peuvent ajuster leurs actions en temps réel grâce à la détection des zones de forte densité, permettant ainsi une gestion plus efficace des foules et une réactivité accrue en cas d’imprévu.

Cette présentation a démontré de manière concrète comment les données, souvent perçues comme abstraites, peuvent se révéler utiles dans le cadre de grands événements. Toutefois, certaines limites ont été relevées : les visiteurs non connectés au réseau d’Orange et ceux utilisant une carte eSIM ne sont pas pris en compte, ce qui limite la couverture de l’analyse.

IA-404 : Explication not found

La seconde conférence de la journée, “IA-404 : Explication not found”, présentée par Cécile Hannotte de Onepoint, explore les limites actuelles de l’intelligence artificielle. Elle démarre avec une anecdote percutante : demander à une IA de dessiner un chat ne pose aucun problème. En revanche, exiger d’elle une explication sur ce qui fait de son dessin un chat donne lieu à des réponses floues, souvent limitées à des définitions générales sans véritable justification. Cette incapacité à fournir des explications solides souligne le problème d’explicabilité des IA.

Cécile met en avant la vitesse fulgurante à laquelle progresse l’intelligence artificielle, au point que même les spécialistes peinent aujourd’hui à saisir certains processus décisionnels. Ce manque de transparence suscite des préoccupations, surtout dans des secteurs sensibles comme la médecine, où comprendre les recommandations est crucial. Elle cite l’exemple de Watson, l’IA développée par IBM pour assister les médecins dans leurs diagnostics : l’absence de justifications claires sur ses conseils a entravé son adoption. Une IA, si performante soit-elle, devient difficilement utilisable sans explications compréhensibles de ses choix.

Cette présentation met en lumière la rapidité impressionnante de l’évolution des IA, qui dépasse parfois la capacité humaine à en suivre les logiques internes. Cette réalité soulève des questions essentielles : comment accorder sa confiance à une technologie dont le fonctionnement reste en partie opaque ?

Grâce à un savant mélange de technique, de vulgarisation et d’humour, cette conférence a brillamment mis en exergue les défis posés par l’essor rapide de l’intelligence artificielle.

L’Implémentation Réussie d’une Data Factory chez Generali France

La conférence “L’Implémentation Réussie d’une Data Factory chez Generali France”, animée par Brahim Abdesslam et Richard Parent, a offert un éclairage sur les défis et les succès d’une transformation digitale de grande envergure. La gestion et la visualisation des données y ont joué un rôle central. Avec l’aide de Keyrus, Generali a instauré une Data Factory capable de démocratiser l’usage de l’intelligence artificielle et des outils de datavisualisation dans toute l’organisation.

Un point clé de cette mise en œuvre est l’importance de la préparation des données (data prep) et des outils de visualisation pour faciliter l’accès et l’efficacité de l’analyse. L’intégration de technologies avancées, telles que Snowflake pour la gestion du datalake et Hadoop pour le stockage, a permis à Generali d’augmenter significativement la vitesse de traitement. Le passage au cloud a même multiplié cette rapidité de traitement jusqu’à vingt fois, améliorant la capacité de l’entreprise à traiter des volumes importants de données en temps réel.

Trois projets majeurs ont illustré les effets de cette transformation. Outre les gains techniques, la Data Factory a permis de redéfinir le fonctionnement global de l’organisation. Une équipe dédiée a été formée pour faciliter l’adoption des nouvelles technologies au sein de Generali, tandis qu’un socle d’outils et de solutions uniformisé a simplifié les pratiques et les collaborations interservices.

Cette initiative illustre parfaitement comment une approche stratégique axée sur les données peut transformer une entreprise. Cependant, un discours moins axé sur le marketing et plus détaillé sur les choix et les implémentations techniques aurait été apprécié.

Regards croisés : comment le groupe IMA a mis en place une stratégie data gagnante ?

La conférence “Regards croisés : comment le groupe IMA a mis en place une stratégie data gagnante ?”, animée par Brice Guillermic, a mis en avant le concept de self-service des données. IMA a développé un système permettant aux équipes métiers d’accéder et d’utiliser les données de manière autonome, sans dépendance systématique vis-à-vis du service IT. Cette autonomie transforme la dynamique interne, les équipes métiers devenant maîtres de leurs données, ce qui accélère la prise de décision et renforce l’agilité.

L’introduction des jeux de données sous forme de modèles sémantiques constitue un autre point marquant. Cette structuration facilite l’accès aux données de manière uniforme et simplifiée pour l’ensemble des utilisateurs. En offrant des informations claires et standardisées, ce modèle garantit une cohérence et une fiabilité des données, essentielles pour des analyses précises.

La présentation a également souligné l’importance de l’implication des équipes métiers et de la maîtrise d’ouvrage (MOA) dès le début du processus. Cette collaboration favorise non seulement une adoption rapide des outils, mais assure aussi une meilleure pertinence des données pour l’utilisation quotidienne.

Cette conférence démontre la valeur d’une approche qui combine autonomie des équipes métiers avec des outils et des jeux de données bien structurés. Une telle stratégie pourrait être appliquée à d’autres organisations, en donnant aux utilisateurs finaux un contrôle accru sur leurs données, tout en préservant cohérence et qualité.

Vers un écosystème data unifié : Exemple de la navigation sur le Saint-Laurent (Québec)

La conférence “Vers un écosystème data unifié : Exemple de la navigation sur le Saint-Laurent (Québec)”, présentée par Alexandre Langlois, offre une perspective captivante sur la transformation digitale du secteur maritime. Ce projet d’envergure, mené sur plus de trois ans, a impliqué une vingtaine d’entreprises collaborant pour moderniser et unifier leur architecture de données. Le passage d’un système basé sur SSIS à une infrastructure entièrement cloud utilisant Azure et Databricks a été une étape clé de cette transformation.

L’utilisation de capteurs IoT, environ 14 à 15 par navire, permet de collecter des données en temps réel, couvrant divers aspects comme les conditions de navigation et la performance des moteurs. Ces informations enrichissent la gestion des opérations sur le Saint-Laurent en permettant aux acteurs d’anticiper les défis et d’optimiser les opérations maritimes. La qualité des données devient ici un facteur crucial dans un environnement aussi complexe.

Un autre aspect essentiel de ce projet est l’intégration des pratiques FinOps. Avec une infrastructure cloud de grande envergure et la participation de nombreuses entreprises, la maîtrise des coûts est un enjeu majeur. Alexandre Langlois a souligné que le succès du projet repose également sur une gestion rigoureuse des dépenses cloud tout en maintenant des performances optimales. Ce point montre l’importance de trouver un équilibre entre innovation technologique et maîtrise budgétaire dans des projets de cette ampleur.

Ce projet a aussi favorisé une meilleure collaboration entre les différents membres du consortium, en renforçant leur maturité analytique et en ouvrant la voie à de nouvelles initiatives d’innovation basées sur les données. Un exemple notable est la collaboration avec Viasat, qui a permis d’améliorer la connectivité des navires et, par conséquent, de renforcer la gestion du trafic maritime.

Cette conférence illustre comment une architecture de données bien pensée, associée à une gestion rigoureuse des coûts et des ressources, peut transformer un secteur entier. Ces principes pourraient inspirer d’autres industries à mieux exploiter leurs données et à stimuler l’innovation.

Conclusion

La journée au Salon de la Data 2024 a démontré que la donnée est bien plus qu’un simple buzzword. Derrière les outils sophistiqués et les architectures cloud complexes, de réelles transformations prennent forme, rendant les entreprises plus agiles, efficaces et innovantes. Que ce soit à travers l’amélioration des processus internes, l’optimisation des ressources ou l’automatisation par l’intelligence artificielle, les retours d’expérience présentés au cours des conférences ont illustré à quel point la data est devenue une boussole stratégique essentielle pour les organisations.

Un enseignement clé est que la maîtrise de la donnée ne se limite pas aux aspects technologiques. Elle repose aussi sur la capacité à rendre ces données accessibles et exploitables pour tous les utilisateurs, qu’ils soient experts ou métiers.

L’univers de la data continue d’évoluer et de surprendre, ouvrant la voie à de nouvelles perspectives et à une innovation toujours plus poussée.

Dagger.io : La nouvelle ère du CI/CD dans le monde DevOps

Benjamin Marsteau — Tue, 14 May 2024 14:39:00 +0000

Encore un nouvel outil ?

Les pratiques de développement logiciel ne cessent d'évoluer.
Même si l'IA se taille une grosse part de l'attention, au cœur des évolutions les plus marquantes se trouve le CI/CD, une méthodologie devenue incontournable.

Quand j'étais petit, ma maman me disait ...
Non !
Blague à part, je ne vais pas vous raconter ma vie au complet, mais une toute petite partie.
Au début de ma carrière, je rêvais d'être ... Genius dans un Apple Store ! 😁 J'étais "légèrement" fanboy.
Puis, mon métier d'administrateur système des années 2000 a évolué, avec l'essor d'outils tels que Nagios, Puppet puis Bitbucket et Bamboo!
À ce moment j'ai compris, en commençant à utiliser Jenkins, que ce "métier" d'administrateur système, mon métier, était voué a changer radicalement.

Depuis, les outils CI/CD sont resté au cœur de mon quotidien.
Sans avoir la prétention de les avoir tous utilisé, j'ai pu en croiser de nombreux.
De Jenkins à Azure DevOps, en passant par GitLab CI, AWS CodeCommit ou encore GitHub Actions, ce paysage a énormément évolué.

Mais récemment, un petit nouveau semble vouloir secouer le paysage du CI/CD : Dagger.io

Décrit comme la "superglue de DevOps", cette solution se présente comme une réponse innovante à la complexité croissante rencontrée par les développeurs.
Dans cet article je vous propose d'approfondir Dagger.io, en explorant son histoire, ses avantages, ses défis, et en fournissant un exemple concret d'utilisation, le tout afin d'éclairer les développeurs et les entreprises sur son potentiel transformateur.

Histoire de Dagger.io

À l'ínstar de Hugging Face ou Datadog, pour la plupart des français évoluant dans l'univers tech et startup, l'histoire de Docker et son équipe fondatrice représentait une "petite" fierté du fait de leurs origines hexagonales.

Initié par Solomon Hykes, co-fondateur de Docker, Dagger.io est né d'une vision : offrir une solution de CI/CD universelle qui transcende les limitations des outils existants.
En proposant un système qui n'est pas restreint par le langage ou la configuration, Dagger.io vise à unifier les processus de développement, test, et déploiement au sein d'une interface cohérente et flexible.

Avantages

Universalité et Flexibilité

L'un des atouts les plus significatifs de Dagger.io est son universalité.

Dagger.io veut être à la CI/CD ce que Docker a été pour le développement et déploiement logiciel.

En permettant l'utilisation de multiples langages de programmation et en s'affranchissant des contraintes de plateformes spécifiques, Dagger.io offre une liberté sans précédent dans la conception des pipelines de CI/CD. Cette flexibilité se traduit par une capacité accrue à personnaliser les processus de développement, répondant ainsi aux besoins spécifiques de chaque projet.

Cette flexibilité se manifeste également dans la personnalisation des workflows. Considérons une entreprise qui a besoin de déployer ses applications sur plusieurs plateformes cloud. Avec Dagger.io, elle peut créer un pipeline unique qui s'adapte à AWS, Azure, et Google Cloud, utilisant des conteneurs pour garantir que chaque déploiement est optimisé pour la plateforme cible.

Portabilité et Consistance

Avez vous déjà pu tester vos jobs Gitlab CI, vos Actions Github, ou n'importe quel autre outils de pipeline ?
Non mais je veux dire vraiment testé ! En local, sur votre poste, avant de les envoyer dans le dit outil ?
Vous en reviez, Dagger.io le permet.

L'un des aspects les plus remarquables de Dagger.io est sa capacité à permettre l'utilisation locale des pipelines CI/CD, ce qui est particulièrement avantageux pour les développeurs cherchant à maintenir une cohérence entre les environnements de développement et de production. En utilisant Dagger.io, les développeurs peuvent exécuter et tester leurs pipelines directement sur leurs propres machines, comme s'ils étaient dans un environnement de production, sans nécessiter de modifications ou d'ajustements spécifiques. Cela est rendu possible grâce à l'encapsulation des tâches dans des conteneurs, qui assurent que toutes les dépendances et configurations sont uniformes, peu importe où le pipeline est exécuté.

Cette possibilité d'exécution locale simplifie grandement le processus de test et apporte une consistance particulièrement bénéfique lors du débogage.

Si une application se comporte différemment en production, les développeurs peuvent reproduire l'environnement exact en utilisant Dagger.io localement, éliminant les incertitudes liées aux différences d'environnement.

Intégration et Collaboration

Dagger.io favorise une intégration étroite entre les différents outils et services utilisés dans le cycle de développement logiciel. Cette interopérabilité facilite une collaboration plus étroite entre les équipes de développement, d'opération et de qualité, renforçant ainsi l'efficacité globale et la qualité des produits logiciels.

Une équipe peut utiliser Dagger.io pour orchestrer un workflow où le code est d'abord vérifié avec SonarQube, puis empaqueté avec Docker, et finalement déployé avec Kubernetes, le tout au sein d'un pipeline unique et cohérent.

Cette intégration étroite encourage la collaboration entre les équipes. Les développeurs, les ingénieurs DevOps, et les testeurs peuvent travailler ensemble sur le même pipeline, partageant des retours en temps réel et améliorant la qualité du code et la rapidité des livraisons. Un développeur peut ajouter un test unitaire au pipeline, et le testeur peut immédiatement l'utiliser pour valider les nouvelles fonctionnalités, tout en s'assurant que l'infrastructure est correctement configurée par l'équipe DevOps.

Inconvénients

Courbe d'Apprentissage

La richesse de Dagger.io entraîne en contrepartie une courbe d'apprentissage abrupte pour les équipes non habituées aux technologies qui l'emploient.

Une transition vers Dagger.io risque d'impliquer l'écriture de scripts en Python ou en Go pour définir les pipelines.
Ceci nécessiterait ainsi une montée en compétence significative.
De plus, la compréhension du fonctionnement interne des conteneurs Docker, essentielle pour utiliser pleinement Dagger.io, constitue une barrière supplémentaire pour celles et ceux n'ayant pas d'expérience préalable avec la conteneurisation.

Complexité Potentielle

La flexibilité et la polyvalence de Dagger.io, bien que bénéfiques, peuvent introduire une complexité supplémentaire dans la configuration et la maintenance des pipelines CI/CD.

L'introduction de Dagger.io pourrait transformer des tâches de CI/CD auparavant simples, gérées par quelques lignes de YAML, en processus plus complexes nécessitant une configuration étendue et des scripts multi-langages. Cette complexité pourrait non seulement ralentir le processus de développement mais aussi augmenter le risque d'erreurs dans la configuration des pipelines.

De plus, l'intégration poussée de divers outils et services dans un pipeline Dagger.io peut augmenter la charge cognitive pour les équipes.
Par exemple, si un pipeline implique l'intégration de tests automatisés, de déploiements sur plusieurs environnements, et de notifications via divers canaux de communication, la configuration et le débogage de ce pipeline pourraient devenir significativement plus complexes comparés à un outil spécialisé ou à une solution plus simple.

Exemple d'Utilisation : Un Pipeline CI/CD avec Dagger.io

Pour illustrer l'application pratique de Dagger.io, envisageons un scénario où une équipe souhaite automatiser la vérification de la qualité du code dans son projet. L'exemple suivant en Python montre comment Dagger.io peut être utilisé pour créer un pipeline de CI qui vérifie le style et les erreurs dans le code Python, en utilisant des outils comme flake8 et mypy.

import sys
import anyio
import dagger

async def code_quality_check():
    async with dagger.Connection(dagger.Config(log_output=sys.stderr)) as client:
        src = client.host().directory("./src")
        quality_checker = (
            client.container().from_("python:3.10-slim-buster")
            .with_exec(["pip", "install", "flake8", "mypy"])
            .with_mounted_directory("/code", src)
            .with_workdir("/code")
            .with_exec(["flake8", "."])
            .with_exec(["

mypy", "."])
        )
        await quality_checker.stdout()

if __name__ == "__main__":
    anyio.run(code_quality_check)

Ce script crée un conteneur, installe flake8 et mypy, monte le répertoire du code source, et exécute les vérifications de style et de type. Dagger.io facilite ce processus, rendant le pipeline de CI/CD plus fiable.

Dagger.io est-il la fine lame espérée ?

Dagger.io représente une avancée significative dans le domaine du CI/CD, offrant une plateforme robuste et adaptable pour les processus de développement logiciel. Alors que le monde de la technologie continue d'évoluer, des outils comme Dagger.io joueront un rôle crucial en permettant aux équipes de rester agiles, cohérentes et efficaces dans leurs pratiques de développement. Bien que l'adoption de Dagger.io puisse présenter des défis initiaux, les avantages à long terme en termes de flexibilité, de portabilité et d'intégration en font une option attrayante pour les entreprises soucieuses d'optimiser leurs opérations de développement logiciel.

À mesure que Dagger.io continue de se développer et de s'enrichir en fonctionnalités, sa communauté d'utilisateurs est susceptible de croître, offrant encore plus de ressources, de partages d'expériences, et de soutien pour les équipes adoptant cette plateforme. Les possibilités offertes par Dagger.io sont vastes, et son exploration peut ouvrir de nouvelles voies d'innovation et d'efficacité dans le développement logiciel.