DEV Community: Karkael

Arrêtez de choisir une méthode Agile. Choisissez une taille de promesse.

Karkael — Mon, 31 Aug 2026 14:05:51 +0000

Version originale en anglais : https://dev.to/karkael/stop-picking-a-method-pick-a-promise-size-3956

Commençons par le débat auquel je ne crois plus : Scrum contre Kanban.

C'est un débat de vitrine, qui vend des certifications, remplit des conférences, permet de mettre une tribu dans sa bio. Et il masque quelque chose de bien plus utile : ces méthodes sont sœurs. Sur notre projet, nous en avons pratiqué trois en dix mois, et voici ce qui a réellement changé entre elles...

Rien ! Ni les cérémonies, ni l'outillage, ni la forme du projet, ni son périmètre fonctionnel, ni sa méthodologie au sens sérieux du terme. Nous avons tenu un daily, un weekly, un refinement et une rétro de la première semaine au dernier jour, dans les trois phases. (Scrum n'a ajouté que deux événements à cette liste : le planning et la démo — Guide Scrum 2020.)

Une variable a bougé. Une seule. La taille de la promesse — l'engagement d'une personne.

Phase	La question d'estimation posée	Unité de responsabilité
Kanban	« Combien de jours pour ce composant ? »	une micro-tâche
Strong ownership	« Combien de semaines pour cette page ? »	une tâche longue
Scrum	« Combien de storypoints ? »	un découpage prévisible

C'est tout. C'est tout l'article. Ce qui suit explique pourquoi ce curseur a bougé, et ce qui a fixé sa position : notre niveau de certitude à cet instant. Pas notre maturité, pas le conseil d'un coach, pas la promesse d'un framework.

Le décor

Anonymisé, mais la configuration est banale :

4 personnes, dont le lead-architecte — qui codait aussi
Next.js / React, bibliothèque de composants dans Storybook, CI/CD conteneurisée
Une équipe UX en parallèle dès le premier jour, encore en maquettage Figma quand nous livrions déjà

Dix mois jusqu'à la fin des évolutions, et notez que les phases ci-dessous se chevauchent. Ça compte plus que la séquence.

flowchart LR
    subgraph P1["Mois 1-3 · certitude = les composants"]
        direction TB
        K["KANBAN<br/>3 développeurs<br/>unité : un composant<br/>« combien de jours ? »"]
    end
    subgraph P2["Mois 4-6 · certitude = les pages"]
        direction TB
        S2["STRONG OWNERSHIP<br/>1 dev = 1 page<br/>unité : une page<br/>« combien de semaines ? »"]
    end
    subgraph P3["Mois 7-10 · certitude = tout le périmètre"]
        direction TB
        SC1["SCRUM · sprints de 2 semaines<br/>avant la MEP<br/>fonctionnel + qualité + sécurité<br/>« combien de storypoints ? »"]
        SC2["SCRUM · même cadence<br/>après la MEP<br/>évolutions post-lancement<br/>« combien de storypoints ? »"]
    end
    subgraph P4["Mois 11+ · plus d'évolution majeure"]
        direction TB
        K2["KANBAN À NOUVEAU<br/>TMA<br/>unité : un ticket<br/>« combien de jours ? »"]
    end
    K --> S2
    S1 --> S2
    S2 --> SC1
    SC2 --> K2

Relisez ce diagramme : pendant les trois premiers mois, nous faisions tourner deux méthodes en même temps. Les trois développeurs tiraient des composants sur un board Kanban tandis que l'architecte était déjà en strong ownership sur le socle et le pipeline de déploiement. Personne n'a trouvé ça bizarre, parce que personne ne « respectait un framework strict ». Chacun répondait à la question d'estimation qui correspondait à ce qu'il savait.

Mois 1 à 3 : Kanban, parce que nous avons copié Figma

« Nous avons construit la codebase dans l'ordre où l'UX la dessinait. »

Pas par hasard — par décision. Un design system ne se dessine pas page d'abord. Il commence par Typography, puis les couleurs et les espacements, puis les atomes, puis les Inputs, les Cards, la Table. Les pages viennent en dernier, parce qu'une page est un assemblage. Le front a donc suivi la même montée : Typography, les atomes, la Table, puis — seulement là — l'assemblage.

Le gain était calendaire, pas esthétique. Design et développement ont cessé de faire la queue l'un derrière l'autre pour avancer côte à côte : le Gantt s'est compressé au lieu de s'étirer. Attendre des maquettes de pages finies avant la première ligne de code nous aurait coûté ces trois mois, simplement.

Kanban convient à ce moment pour une raison précise : il demande de rendre le flux explicite et de limiter le travail en cours (The Kanban Guide) — il ne demande jamais de s'engager sur un périmètre. Nous n'avions aucun périmètre à engager. Nous avions une certitude sur les composants et rien d'autre : nous promettions donc en jours, et uniquement sur des composants.

Effet de bord qui justifie à lui seul le billet d'entrée : ces composants sont devenus un vocabulaire commun. Quand une spec a dit plus tard « un tableau filtrable à en-tête collant », personne n'a eu à deviner et personne n'a eu à le construire.

Mois 4 à 6 : un dev, une page. Et non, ce n'est pas de l'Extreme Programming.

Puis les maquettes sont devenues des pages entières, puis des parcours. Un ticket a cessé d'être « développer Pagination » pour devenir « développer la page de résultats » : des jours de travail sur une douzaine de fichiers. Quatre personnes dans un dépôt Next.js, et le curseur devait bouger : promettre en jours ne correspondait plus au travail.

Chaque développeur a donc possédé une page, de bout en bout. Route, récupération des données, composition, tests. L'architecte a continué de posséder le socle, et relisait tout. Même board, mêmes dailies, même rétro — promesse plus grande.

J'ai entendu appeler ça de l'Extreme Programming. C'est l'inverse.

XP prescrit explicitement la propriété collective du code : « la convention explicite que chaque membre de l'équipe est non seulement autorisé, mais a le devoir positif, de modifier n'importe quel fichier si nécessaire » (Agile Alliance) — pratique renommée « Shared Code » dans la seconde édition du livre de Beck. Ce que nous faisions se range dans une autre case de la taxonomie de Martin Fowler sur la propriété du code : le strong ownership (seul le propriétaire modifie le module), adouci en weak ownership (les autres peuvent, mais consultent). Fowler dit ouvertement son aversion pour le strong ownership, et sa raison est solide : un changement trivial qui traverse une frontière devient une négociation.

Deux choses ont rendu le nôtre bon marché :

La couche partagée est restée collective. Composants, tokens, utilitaires — n'importe qui, n'importe quand. La propriété portait sur les pages, qui partageaient des composants mais pas de logique.
La phase 1 a payé la phase 2. Les pages étaient indépendantes parce que trois mois de Kanban avaient déjà extrait tout le partageable. Tentez le strong ownership sur des pages qui partagent de la logique métier, et ça vous fera mal.

Si vous y allez, rendez la propriété exécutable plutôt que sociale : un fichier CODEOWNERS fait demander automatiquement par GitHub la relecture du propriétaire des chemins touchés (GitHub Docs). Et traitez-la comme une rotation, pas comme un titre.

Mois 7 à 10 : Scrum, parce que « terminé » voulait enfin dire quelque chose

Deux mois avant la MEP, le travail restant a changé de nature, pas de taille : trous fonctionnels transverses, accessibilité, états d'erreur, performance, revue de sécurité. Les 20 % ennuyeux qui font 80 % de la qualité perçue.

Ce travail a une propriété que le précédent n'avait pas : il est finissable. Un Sprint est un conteneur de durée fixe avec un Sprint Goal et une Definition of Done (Guide Scrum) : un dispositif d'écoulement de stock, pas un dispositif de productivité. En Kanban, nous aurions tiré des améliorations indéfiniment, parce qu'il y en a toujours une de plus.

Nous avons fait des Sprints de 2 semaines. Volontairement plus longs que les deux habituelles : les sujets de sécurité et de qualité se découpent mal en quinzaines sans produire des fonctionnalités à moitié durcies, et à quatre, la charge de cérémonie d'une cadence bimensuelle était disproportionnée. C'est là que notre Definition of Done a pris des dents — les items de sécurité sont devenus des critères de sortie explicites plutôt que de bonnes intentions, ce qui est la version pratique de ce que l'OWASP appelle intégrer la sécurité dans le pipeline au lieu de la greffer à la fin (OWASP DevSecOps Guideline).

Un ajustement au passage : nous avons commencé à répondre en storypoints, même si les storypoints n'apparaissent nulle part dans le Guide Scrum. Le framework demande que les éléments soient dimensionnés ; nous avons ajouté ce concept pour se mesurer. Ce qui confirme plutôt le propos — ce que nous avons adopté est une unité de promesse, pas une religion.

Puis nous sommes passés en production — et nous avons continué à sprinter deux mois de plus. Le backlog post-lancement était fait de vraies évolutions : des fonctionnalités repoussées pour tenir la date, et la première salve de demandes venues des utilisateurs réels. Même cadence, même Definition of Done, mêmes promesses de trois semaines.

Les objections honnêtes

« Le strong ownership crée des silos de connaissance. » C'est la critique standard et c'est la bonne à soulever — mais sur notre projet, elle n'a pas mordu. Les congés sont arrivés, les uns ont couvert les autres, rien ne s'est bloqué. La raison : la codebase était correctement déclarée et documentée, le code était lisible, et tout passait en relecture par les pairs. Les silos sont un symptôme de code illisible plus merges non relus. Corrigez ces deux-là et la propriété cesse d'être un fief.

« Changer trois fois de méthode a dû vous coûter cher. » Moins qu'on ne croit, et voici le mécanisme : la catégorisation en épiques JIRA et un rituel de refinement pour les storypoints existaient très tôt dans le projet — bien avant Scrum, et à la lettre ils n'appartiennent ni au Kanban ni au strong ownership. Le travail était déjà catégorisé et déjà discuté collectivement. Chaque transition a donc changé un nombre, pas un système. C'est l'argument pratique en faveur de cérémonies stables dont on ne laisse bouger que la promesse.

Là où les tenants de XP gardent raison : le pair programming, le trunk-based development et l'intégration continue attaquent les collisions de merge de face, sans tracer aucune frontière organisationnelle, et distribuent la connaissance comme effet de bord plutôt que comme discipline à entretenir. Si votre équipe binôme déjà bien, essayez cette voie d'abord — vous n'aurez peut-être jamais besoin de faire quitter « les jours » au curseur.

Une dernière chose : la MEP n'est pas un événement méthodologique

Regardez à nouveau la chronologie. La date la plus scrutée de tout le projet — le lancement — est le seul moment où rien n'a changé dans notre façon de travailler. Même Scrum, mêmes Sprints de trois semaines, même board, tout droit à travers. Nous étions en production, et la taille de la promesse est restée exactement où elle était.

Le curseur est redescendu deux mois plus tard, et pour une raison complètement différente : les évolutions se sont épuisées. Ce qui restait était petit, indépendant, imprévisible et sans aucun périmètre à engager — un bug, une correction de contenu, une montée de version. Dimensionner ça en storypoints et l'enfermer dans des promesses de trois semaines ajoute de la cérémonie à un travail qui n'a aucun stock à écouler. La TMA est donc redevenue un Kanban, et nous avons recommencé à répondre en jours.

C'est le signe que c'est la certitude qui commande, et pas le calendrier. Les deadlines, les lancements et les comités de pilotage donnent l'impression qu'ils devraient déplacer votre méthode. Ils ne le font pas. Ce qui la déplace, c'est ce que vous savez — et après le lancement, sur un produit stable, vous en savez moins sur la semaine prochaine que pendant le Sprint. Le curseur est un potentiomètre, pas une échelle. Le nôtre est monté dix mois puis redescendu, et ce n'est pas une régression.

Ce que je dirais à mon moi passé

Arrêtez de demander « quelle méthode Agile convient à ce projet ». Demandez « quelle taille de promesse pouvons-nous honnêtement tenir ce mois-ci » — le nom du framework découle de la réponse, et ce sera le débat de quelqu'un d'autre.

Avez-vous déjà déplacé ce curseur en cours de projet ? Qu'est-ce qui vous a dit qu'il était temps ?

Sources : Manifeste Agile · Open Guide to Kanban · Agile Alliance — Collective Code Ownership · Martin Fowler — Code Ownership · GitHub Docs — About code owners · Guide Scrum 2020 · OWASP DevSecOps Guideline

Stop picking an Agile method. Pick a promise size.

Karkael — Mon, 31 Aug 2026 14:00:47 +0000

Let me start with the argument I no longer believe in: Scrum vs Kanban.

It is a shop-front argument. It sells certifications, it fills conference tracks, it lets people put a tribe in their bio. And it hides something much more useful: these methods are neighbours. On our project we ran three of them across ten months, and here is what actually changed between them —

Nothing. Not the ceremonies. Not the tooling. Not the shape of the project, not its functional scope, not its methodology in any meaningful sense. We ran a daily, a weekly, refinement and a retro from week one to the last day, in all three phases. (Scrum only added two events to that list: planning and the demo — 2020 Scrum Guide.)

One variable moved. One. The size of the promise — how big a thing a single person put their name on.

Phase	The estimation question we asked	Unit of responsibility
Kanban	"How many days for this component?"	a micro-task
Strong ownership	"How many weeks for this page?"	a long task
Scrum	"How many story points?"	a predictable slice

That's it. That's the whole article. Everything below is why that cursor moved, and what set its position: our level of certainty at that moment. Not our maturity, not a coach's advice, not a framework's promise.

The setup

Anonymised, but the shape is banal:

4 people, including the lead architect — who was also writing code
Next.js / React, component library in Storybook, containerised CI/CD
A UX team working in parallel from day one, still designing in Figma while we were already shipping

Ten months to the end of the evolution phase, and note that the phases below overlap. That matters more than the sequence.

flowchart LR
    subgraph P1["Months 1-3 · certainty = the components"]
        direction TB
        K["KANBAN<br/>3 developers<br/>unit: a component<br/>“how many days?”"]
        S1["STRONG OWNERSHIP<br/>lead architect<br/>unit: the foundations<br/>“how many weeks?”"]
    end
    subgraph P2["Months 4-6 · certainty = the pages"]
        direction TB
        S2["STRONG OWNERSHIP<br/>1 dev = 1 page<br/>unit: a page<br/>“how many weeks?”"]
    end
    subgraph P3["Months 7-10 · certainty = the whole scope"]
        direction TB
        SC1["SCRUM · 3-week sprints<br/>before go-live<br/>functional + quality + security<br/>“how many story points?”"]
        SC2["SCRUM · same cadence<br/>after go-live<br/>post-launch evolutions<br/>“how many story points?”"]
        SC1 --> SC2
    end
    subgraph P4["Month 11+ · no major evolution left"]
        direction TB
        K2["KANBAN AGAIN<br/>maintenance<br/>unit: a ticket<br/>“how many days?”"]
    end
    K --> S2
    S1 --> S2
    S2 --> SC1
    SC2 --> K2

Read that chart again: for the first three months we were running two methods at once. The three developers were pulling components through a Kanban board while the architect was already in strong ownership on the foundations and the deployment pipeline. Nobody found that strange, because nobody was doing "a framework". Each of them was answering the estimation question that fit what they knew.

Months 1–3: Kanban, because we copied Figma

Here is the part I would tattoo on a project charter: we built the code base in the same order UX designed it.

Not by coincidence — by decision. A design system is not drawn page-first. It starts at Typography, then colour and spacing, then the atoms, then Inputs, then Cards, then Table. Pages come last, because a page is an assembly. So the front end followed the same climb: Typography, then the atoms, then Table, then — only then — assembly.

The payoff was scheduling, not elegance. Design and development stopped queuing behind each other and started running side by side; the Gantt compressed instead of stretching. Waiting for finished page designs before writing the first line would have cost us those three months outright.

Kanban fits this moment for a precise reason: it asks you to make your workflow explicit and to limit work in progress (The Kanban Guide) — it never asks you to commit to a scope. We had no scope to commit to. We had certainty about components and nothing else, so we promised in days, and only about components.

Side effect worth the price of admission: those components became a shared vocabulary. When a spec later said "a filterable table with a sticky header", nobody had to guess and nobody had to build it.

Months 4–6: one dev, one page. And no, this is not Extreme Programming.

Then the designs grew into full pages and flows. A ticket stopped being "build Pagination" and became "build the search results page" — days of work across a dozen files. Four people in one Next.js repo, and the cursor had to move: promises in days no longer matched the work.

So each developer owned a page, end to end. Route, data fetching, composition, tests. The architect kept owning the foundations, and reviewed everything. Same board, same dailies, same retro — bigger promise.

I have heard this called Extreme Programming. It is the opposite.

XP explicitly prescribes collective code ownership: "the explicit convention that every team member is not only allowed, but in fact has a positive duty, to make changes to any code file as necessary" (Agile Alliance) — renamed "Shared Code" in the second edition of Beck's book. What we did sits in a different box in Martin Fowler's taxonomy of code ownership: strong ownership (only the owner changes the module), softened into weak ownership (others may, but consult the owner). Fowler openly dislikes strong ownership, and his reason is sound: a trivial change crossing a boundary becomes a negotiation.

Two things made ours cheap:

The shared layer stayed collective. Components, tokens, utilities — anyone, anytime. Ownership applied to pages, which shared components but not logic.
Phase 1 paid for phase 2. Pages were independent because three months of Kanban had already extracted everything shareable. Try strong ownership over pages that share business logic and it will hurt you.

If you go there, make ownership executable rather than social: a CODEOWNERS file has GitHub auto-request review from the owner of the touched paths (GitHub Docs). And treat it as a rotation, not a title.

Months 7–10: Scrum, because "done" finally meant something

Two months before go-live, the remaining work changed nature, not size: cross-page functional gaps, accessibility, error states, performance, security review. The boring 20% that is 80% of perceived quality.

That work has a property the earlier work lacked: it is finishable. A Sprint is a fixed-length container with a Sprint Goal and a Definition of Done (Scrum Guide) — an inventory-clearing device, not a productivity device. In Kanban we would have kept pulling improvements forever, because there is always one more.

We ran 3-week Sprints. Deliberately longer than the usual two: security and quality items slice badly into fortnights without producing half-hardened features, and at four people the ceremony overhead of a 2-week cadence was disproportionate. Our Definition of Done grew teeth here — security items became explicit exit criteria rather than good intentions, which is the practical version of what OWASP means by embedding security in the pipeline instead of bolting it on (OWASP DevSecOps Guideline).

One provocation while we are here: we started answering in story points, and story points appear nowhere in the Scrum Guide. The framework asks that items be sized; the currency is our invention. Which rather makes the point — what we adopted was a unit of promise, not a religion.

Then we went live — and kept Sprinting for two more months. The post-launch backlog was made of real evolutions: features deferred to get the launch out, and the first round of changes asked for by actual users. Same cadence, same Definition of Done, same three-week promises.

The honest objections

"Strong ownership created knowledge silos." It is the standard critique and it is the right one to raise — but on our project it did not bite. Holidays came, people covered for each other, and nothing stalled. The reason is unglamorous: the code base was properly declared and documented, the code was readable, and everything went through peer review. Silos are a symptom of unreadable code plus unreviewed merges. Fix those and ownership stops being a fiefdom.

"Switching methods three times must have cost you." Less than you would think, and here is the mechanism: JIRA epics and a refinement ritual for story points existed very early in the project — long before Scrum, and strictly speaking they belong to neither Kanban nor strong ownership. The work was already categorised and already discussed collectively. So each transition changed one number, not a system. That is the practical argument for keeping ceremonies stable and letting only the promise move.

Where the XP crowd still has a point: pair programming, trunk-based development and continuous integration attack merge collisions head-on without drawing organisational boundaries at all, and they distribute knowledge as a side effect rather than as a discipline you must maintain. If your team already pairs well, try that first — you may never need the cursor to leave "days".

One last thing: go-live is not a methodological event

Look at the timeline again. The most-watched date of the whole project — the launch — is the one moment where nothing about our way of working changed. Same Scrum, same three-week Sprints, same board, straight through it. We had shipped to production, and the promise size stayed exactly where it was.

The cursor came back down two months later, and for a completely different reason: the evolutions ran out. What was left was small, independent, unpredictable and free of any scope to commit to — a bug, a content fix, a dependency bump. Sizing that in story points and boxing it into three-week promises adds ceremony to work that has no batch to clear. So maintenance went back to Kanban, and answering in days again.

That is the tell that the certainty rules and the calendar does not. Deadlines, launches and steering committees feel like they should move your method. They don't. What moves it is how much you know — and after launch, on a stable product, you know less about what next week holds than you did during the Sprint. The cursor is a dial, not a ladder. Ours went up for ten months and came back down, and that is not a regression.

What I would tell my past self

Stop asking "which Agile method is right for this project". Ask "how big a promise can we honestly make this month" — the framework name falls out of the answer, and it will be someone else's argument.

Have you moved that cursor mid-project? What told you it was time?

Sources: Agile Manifesto · Open Guide to Kanban · Agile Alliance — Collective Code Ownership · Martin Fowler — Code Ownership · GitHub Docs — About code owners · 2020 Scrum Guide · OWASP DevSecOps Guideline

When the cloud isn't enough (triple modular redundancy)

Karkael — Mon, 28 Oct 2024 18:42:27 +0000

You're using a single source for your applications, and you're wrong.

Dear administrator, I'm humbled to make this appeal to you, after yet another failure by our team to ensure the availability of our application. I'm going back to my engineering classes, taking the opportunity to optimize, cut costs and harmonize.

This article is aimed at all applications that require a high level of availability or whose data is sensitive.

Triple modular redundancy, engineering curriculum

https://en.wikipedia.org/wiki/Triple_modular_redundancy

During your engineering courses, you must have studied processes for reinforcing your product: emergency stops, mistake-proofing, monitoring tools. Today, remember triple modular redundancy: a critical service must be available from at least 3 sources.

For your application, this means you need to think about:

provide a service from 3 sources,
duplicate the data in 3 sources,
allow a balance from one to the other.

Standards, ISO-27001

https://en.wikipedia.org/wiki/ISO/IEC_27001

When you're working with large entities or internationally, you need to ensure your customers' your ability to follow standards such as ISO-27001, which will enable you to work with industries in particular. These standards were introduced in 2005 and are regularly revised.

ISO-27001 is based on 3 pillars:

Confidentiality of information,
Information integrity,
Information availability.

To obtain this certification, having a single data source and a single application source won't be enough: you'll have to apply triple modular redundancy. You can't depend solely on the server running on your premises, nor can you depend solely on a cloud.

The benefits of Clouds and internal servers

The advantages of a cloud:

✅ faster start-up,
✅ no hardware management,
✅ outsourced hardware technical skills (fewer employees),
✅ standards already applied (e.g. redundancy),
✅ flexibility and on-demand dimensions,
✅ service close to the customer.

The advantages of an in-house server:

✅ complete, self-supervised management,
✅ fixed costs,
✅ information security assured,
✅ easy migrations,
✅ self-managed breakdowns,
✅ controlled liability,
✅ evolutions as needed,
✅ servers developed to suit the customer, with no superfluous extras.

In this tangle of benefits, it's important to understand:

that a cloud will help you get started and take good practices early in your application development ⭐,
that it's in your interest to favor an in-house application and data service (as soon as possible) ⭐⭐,
that you will need to switch to cloud in case of in-house problems and program a balance ⭐⭐⭐,
that you'll need to enable service redundancy on the cloud ⭐⭐⭐⭐.

By choosing a triple redundancy of your service (by having at least 3 internal servers and clouds), you'll even be able to determine the qualitative data in case of conflict between two services: the two servers that give the same answer are right, the server that answers differently must correct its corrupted data ⭐⭐⭐⭐⭐.

Successfully balancing

Encourage in-house use of the application: its fixed cost means you can budget correctly, while the cloud can take over in the event of overload or breakdown. Cloud costs are harder to predict. When only your in-house server is running, you save a lot of money on the cloud.

Once you've decided how to disperse your services (how many internal servers and cloud servers) and once you've defined the type of service you need (FaaS, SaaS, PaaS, IaaS, On-Premise), then you can determine the cloud closest to your needs, start development with it, try to get the same level of service internally, and finally look for another cloud with the same level of service to get triple redundancy.

Consider working with at least one cloud that can provide services as close to the customer as possible, particularly to avoid additional download costs.

Available tools

Containers and management

For simple development, I'd recommend pairs like Kubernetes and Docker, which can easily export a similar configuration between the local work environment, the internal server and all the clouds that enable this kind of IaaS.

Developing with Kubernetes ensures that all servers are the same, and reduces the risk of getting different results (such as corruption).

Software-as-a-Service

For a simple, inexpensive web application, you'll need a domain name, HTTP server, file server and database, take your pick:

A registrar that allows balancing on its CNAME (OVH, Gandi, ...).
AWS: lambda, S3, RDS
Azure: Functions, Blob Storage, Database
Google: Cloud Run, Cloud CDN, Cloud SQL
A multitude of equivalents for in-house services.

Developing compatible SaaS is more difficult, but it does help to reduce runtime costs.

Cleaning, synchronization and security

This redundancy calls for exceptional rigor and costly management. You'll also need to ensure that the perimeters are secure from one another, and that synchronization does not propagate attacks. You'll need to ensure 4 mandatory services:

determine the server closest to the client, to favor nearby downloads,
always copy all data to other cloud and internal servers,
check integrity regularly (e.g. daily at midnight UTC with hash keys) and deal with data corruption,
produce synchronization reports.

Block-chain

In the spirit of redundancy and data integrity, block-chain proposes a systemic approach to determining a secure, decentralized source. In reality, we're not far from a block-chain.

Depending on your data format, you can use blockchain. My guess is that most applications will need services that handle data in very different formats (user, file, checkout, auth), and your CDN or PostgreSQL servers deserve synchronization services at their scale.

Conclusion

Make sure you're not dependent on a single data source. An in-house server and a cloud can work in a complementary way. You'll get a secure, robust application that's ready to work with global companies.

Quand le Cloud n'est pas suffisant (triple redondance modulaire)

Karkael — Mon, 28 Oct 2024 18:30:54 +0000

Vous utilisez une seule source pour vos applications, et vous avez tort.

Très cher administrateur, c'est avec humilité que je te fais cet appel, après un nouvel échec de notre équipe à assurer la disponibilité de notre application. Je reviens vers mes cours d'ingénieur, j'en profite pour optimiser, diminuer les coûts et harmoniser.

Cet article s'adresse à toutes les applications qui ont besoin d'un fort taux de disponibilité ou dont les données sont sensibles.

Triple redondance modulaire, cursus ingénieur

https://en.wikipedia.org/wiki/Triple_modular_redundancy

Durant vos cours d'ingénieur, vous avez forcément étudié des procédés pour renforcer votre produit: arrêts d'urgence, détrompeurs, outils surveillance. Aujourd'hui, rappelez-vous de la triple redondance modulaire: un service critique doit être disponible par au moins 3 sources.

Pour votre application, cela signifie que vous devez penser à:

fournir un service par 3 sources,
dupliquer la données en 3 sources,
permettre une balance de l'un à l'autre.

Normes, ISO-27001

https://en.wikipedia.org/wiki/ISO/IEC_27001

Lorsque vous travaillez avec de grandes entités ou à l'international, vous devez assurer à vos clients la capacité à suivre des normes comme l'ISO-27001, qui vous permettra notamment de travailler avec les industries. Ce sont des normes qui sont apparues en 2005 et révisées régulièrement.

L'ISO-27001 repose sur 3 pilliers:

La confidentialité de l'information,
L'intégrité de l'information,
La disponibilité de l'information.

Pour obtenir cette certification, avoir une seule source de donnée et une seule source applicative ne sera pas suffisante, vous allez devoir appliquer la triple redondance modulaire. Vous ne pouvez pas dépendre que du serveur qui tourne dans vos locaux, vous ne pouvez pas non plus dépendre que d'un cloud.

Les apports des Clouds et des Serveurs internes

Les avantages d'un cloud:

✅ démarrage plus rapide,
✅ pas de gestion matérielle,
✅ compétences techniques matérielles sous-traitées (moins de salariés),
✅ des normes déjà appliquées (ex: redondance),
✅ flexibilité et dimensions à la demande,
✅ service au plus près du client.

Les avantages d'un serveur interne:

✅ gestion entière supervisée soi-même,
✅ coûts fixes,
✅ sécurité de l'information assurée,
✅ migrations faciles,
✅ pannes gérées soi-même,
✅ responsabilité maîtrisée,
✅ évolutions au besoin,
✅ serveurs développé pour correspondre au client, sans superflus.

Dans cet enchevêtrement d'avantages, il faut comprendre:

qu'un cloud vous aidera à démarrer et prendre des bonnes pratiques tôt dans le développement de votre application ⭐,
que (dès que possible) vous avez intérêt à favoriser un service interne de l'application et des données ⭐⭐,
que vous aurez besoin de cloud en cas de problème en interne et programmer une balance ⭐⭐⭐,
que vous devrez permettre une redondance du service sur le cloud ⭐⭐⭐⭐.

En choisissant une triple redondance de votre service (en ayant au moins 3 serveurs internes et clouds), vous allez même pouvoir déterminer la donnée qualitative en cas de conflit entre deux services: les deux serveurs qui donnent la même réponse ont raison, le serveur qui répond différemment doit corriger sa donnée corrompue ⭐⭐⭐⭐⭐.

Réussir la balance

Favorisez l'utilisation de l'application en interne: son coût fixe vous permet de prévoir un budget correctement, tandis que le cloud peut prendre le relais en cas de surcharge ou de panne. Le coût d'un cloud est plus difficile à prévoir. Lorsque seul votre serveur interne tourne, vous faites de grosses économies sur le cloud.

Quand vous aurez choisi comment disperser vos services (combien de serveurs internes et serveurs clouds) et quand vous aurez défini le type de service nécessaire (FaaS, SaaS, PaaS, IaaS, On-Premise), alors vous pourrez déterminer le cloud le plus proche de vos besoins, démarrer le développement avec lui, tenter d'obtenir le même niveau de service en interne, et enfin chercher un autre cloud avec le même niveau de service pour obtenir la triple redondance.

Pensez à travailler avec au moins un cloud qui peut mettre à disposition des services au plus proche du client, notamment pour éviter les surcoûts liés au téléchargement.

Les outils disponibles

Conteneur et gestion

Dans le cadre d'un développement simple, je recommande plutôt des couples comme Kubernetes et Docker, qui peuvent facilement exporter une configuration similaire entre l'environnement de travail local, le serveur interne et tous les clouds qui permettent ce genre de IaaS.

Développer avec Kubernetes permet d'assurer que tous les serveurs sont les mêmes, et diminue les risques d'obtenir des résultats différents (comme une corruption).

Software-as-a-Service

Dans le cadre d'une application web simple et peu coûteuse, vous avez besoin d'un nom de domaine, d'un serveur HTTP, d'un serveur de fichiers et d'une base de donnée, choisissez:

Un registar qui permet la balance sur ses CNAME (OVH, Gandi, ...).
AWS: lambda, S3, RDS
Azure: Functions, Blob Storage, Database
Google: Cloud Run, Cloud CDN, Cloud SQL
Une multitude d'équivalents pour les services internes.

Développer des SaaS compatibles est plus difficile, mais ça permet de diminuer les coûts sur l'exécution.

Nettoyage, synchronisation et sécurité

Cette redondance impose une rigueur exceptionnelle et avec un management coûteux. Vous allez aussi vous assurer que les périmètres sont sécurisés les uns par rapport aux autres et que les synchronisations ne propagent pas d'attaque. Vous devrez vous assurer de 4 services obligatoires:

déterminer le serveur le plus proche du client pour favoriser les téléchargements proches,
toujours copier toutes les données dans les autres serveurs cloud et internes,
s'assurer de l'intégrité régulièrement (ex: tous les jours à minuit UTC avec des clefs de hash) et régler les corruptions de données,
produire des rapports de synchronisation.

Block-chain

Dans l'esprit de la redondance et de l'intégrité des données, la block-chain propose une approche systémique pour déterminer une source sûre et décentralisée. En réalité, on n'est pas loin d'une block-chain.

Selon votre format de donnée, vous pouvez faire appel à la block-chain. J'estime que la plupart des applications auront besoin de services qui gèrent des données dont les formats seront très différents les uns des autres (user, file, checkout, auth), et vos serveurs CDN ou PostgreSQL méritent des services de synchronisation à leur échelle.

Conclusion

Assurez-vous rapidement que vous n'êtes pas dépendant d'une seule source de données. Un serveur interne et un cloud peuvent travailler de façon complémentaire. Vous obtiendrez une application sécurisée, robuste et prête pour travailler avec les entreprises internationales.

When the cost of quality (COQ) overwhelms the project

Karkael — Mon, 23 Sep 2024 14:16:24 +0000

As I'm looking for a new job as a web developer, I'm looking at my reasons for leaving a wonderful company with a senior position to join another project. Let me tell you how the extra cost of quality made me lose my footing.

Companies naturally evolves from feature-oriented to quality-oriented

Software development is successful when the customer is satisfied and the company has sufficient revenue. There is a break in the life of the project: it's when there are enough customers to provide support services. In this case, the company chooses to focus on the quality of the most lucrative functions, and to redistribute expenses towards building customer loyalty. Congratulations, you're part of a sustainable company!

Here is an exhaustive list of practices to focus on quality:

The basics: hire skilled employees, use ticketing & versionning flow, follow standard practices of your choosen tools.
Contribute for continuous improvment (plan, try, measure, standardize).
Add or switch for some better tools (read benchmarks).
Add automated tests (unit tests, end-to-end tests, non-regression testing).
Add automated workers (linters, code-analysers, automated code-reviewers).
Delegate checks to machines (CI/CD).
Forcing more manual tests or hire manual-testers.
Dedicated teams (release, cybersecurity, compliance), audits, formations.
Run AI in your project.

There's a big difference in quality rules between a business-to-business software with 150 users and thousands of functions, and a retail application for 100k simultaneous customers and only one purchase function.

Your company will add more quality rules, sometimes after a critical problem, sometimes in anticipation of problems. The more rules you add, the more expensive quality becomes. You can then calculate the cost to obtain quality (COQ):

Cost of bad code =
  Human time for resolving issues + Bad reputation

Cost of good code =
  Human time for quality + Cost of dedicated machines

Cost to obtain quality =
  Cost of bad code + Cost of good code

Why the hell any company would choose bad-quality?

They don't! No company would allow crappy code with security issues. No, they wouldn't. But you have to recognize that quality is clearly not the priority when you have no customer, no budget and the concept is still evolving.

You then need to hire people who are quick to develop a saleable product, you need to focus on highly anticipated features that will set you apart from the competition or improve your public image.

Force developer have good practices

A company that is making progress and maintaining good relations with its customers will evolve its profile to match those customers. The company will also evolve the profile of its developers in this direction, by imposing rules that are of interest. Developers take on board the new rules, change their habits and acquire reflexes for their working day.

Customers expectations -> developers new reflexes

But don't lock the development

However, companies can become over-costly on quality and forget to develop new products. As a result, marketing-commercial-product plans dilate and new products are delayed.

A company with quality overruns can be identified by a decrease in technical work time, a lengthening plan, rules that prevent novelty, difficulty with change, long processes, interminable meetings with little added value.

A good practice is following continuous improvement.

To get started, define your actual status:

by listing what matter for current customers,
by listing opportunities,
by measuring time to market,
by measuring quality.

The next steps are to plan numerous improvements, select and implement a few at a time, then check that they're working for you. An improvement could be adding good-practices or reducing processus.

Example of quality surcharge on web-development

It's time to share my personal experience with you. Several companies have followed this path and ended up, in spite of myself, being unable to develop new functions in their applications, as a result of an accumulation of rules, which often took them out of Agile good practice, in order to have over-control, or to protect themselves from a non-existent risk, or finally because the company was no more expecting new features.

The company I work for started with a CI/CD and unit tests on main features. Now we changed for a custom CI/CD with AWS, running unit tests for 75% coverage, running non-regression tests for 40% user journeys, with 20% employees dedicated for QA, 1/3 week for release production with 90% employees of the company (product, quality, developers, infra). The cost of quality is actually 80% of the budget (employees and AWS CI/CD) and there is no more time for new feature here. Actually, the customers are satisfied by product, but are awaiting for some expected features, and quality issues are from product (no more technical issues).

It's time to change company mind and find a better fit for customer expectations.

Conclusion

In order to control the cost of obtaining quality, we need to ensure customer loyalty and develop our customer base, and adapt quality, costs and time to market. It's not uncommon to fall into the trap of over-quality. In IT, however, you have to keep inventing new things to ensure the longevity of your business, and controlled risk-taking remains the best strategy.