An architecture that depends on nobody
An architecture does not fail the day it goes down, but the day the person who understood it leaves. What makes a system outlive its author, and how to design for that.
ReadPublications
Articles
Working notes on cloud architecture, cost and governance. What we learn from running systems, written down to be useful.
Cloud Architecture
12 articles
View service line
Cloud architecture that depends on nobody
Twelve articles on how to design a cloud architecture that outlives whoever built it: written decisions and requirements, design by zones, data first, documentation that does not age, review against a standard, cost as a requirement and recovery tested before it is needed.
Fundamentals
Deciding in writing
An architecture decision record takes up one page and saves weeks. What it should contain, when to write it and how to stop it turning into bureaucracy.
ReadThe requirements nobody states
Nobody asks in writing for the system to recover within an hour or to lose no more than five minutes of data, yet everybody expects it. The quality attributes that decide an architecture, and how to make them explicit.
ReadDesigning
Designing by zones
Before choosing services you have to draw boundaries. Network, trust and environment zones: the method that makes an architecture readable at a glance and protectable in parts.
ReadMonolith, microservices or something in between
Microservices are not an improvement on the monolith: they are a different set of trade-offs. Which criteria tip the decision and what components each option demands.
ReadData first
Compute moves easily; data does not. Where each piece of data lives, how much it costs to move, how long it takes and what law forces it to stay decides the architecture more than any service.
ReadMulticloud and hybrid, with judgement
Using several clouds or combining cloud with your own infrastructure can be the right decision or a source of complexity with no return. When it pays off, when it does not and which pattern to choose.
ReadDocumenting and validating
Documentation that does not age
Architecture documentation dies the day it is separated from the system. Treating it as code, with a single source and generated outputs, is what keeps it alive.
ReadBefore fixing, know what is there
Every inherited system has a documented part and another that exists only in production. How to run a survey that uncovers what is really running before changing anything.
ReadReviewing without slowing down
Reviewing architectures against the organisation's standard does not have to be a bottleneck. With a written standard and a verdict classified by severity, the review helps instead of slowing things down.
ReadOperating
Cost is a design requirement
An architecture that meets everything but costs twice what was expected is not well designed. Estimating cost per component before deploying, and why correcting it late comes so expensive.
ReadDesigning for failure
Everything fails sooner or later. A mature architecture decides in advance how long it can be down and how much data it can lose, designs to meet that and tests it before needing it.
ReadFinOps Engineering
12 articles
View service line
FinOps, from concept to operation
Twelve articles to go from a bill nobody understands to a cloud cost that can be explained, allocated and decided on. It starts with what a cost record is, continues with how the pipeline that normalises and corrects it is built, and ends with how it is budgeted, optimised and operated, including for artificial intelligence.
Fundamentals
Cloud cost is not a bill
The cloud bill tells you how much you spent, not why. The questions it leaves unanswered, and how to start turning cost into information you can decide on.
ReadFinOps is not cost cutting
FinOps is not a savings programme. It is a way of working that turns cloud cost into a business decision, through a cycle that repeats.
ReadAnatomy of a cost record
A line on the cloud bill looks like a number. It actually combines usage, rate, discounts and commitments. Understanding those pieces is the first step to not drawing the wrong conclusions.
ReadBuilding
FOCUS explained
FOCUS is the open standard that gives every provider's billing the same columns and the same meaning. What it solves, what it does not, and why it is worth adopting from the start.
ReadArchitecture of a cost pipeline
From the provider's raw file to data you can decide on there are six layers, and each one exists for a reason. This is how you design a cost pipeline that can be audited and that depends on nobody.
ReadCorrect before you trust
Billing data does not arrive ready to use. Duplicates, badly spread commitments and misclassified charges distort any analysis. How to detect them and correct them with rules.
ReadAllocating what has no owner
Without allocation there are no owners, and without owners cost does not come down. Tags, accounts and rules for attributing every cost to a team, an application and a product, shared costs included.
ReadDecision
The unit metric
Total cost rises when the business grows, and that tells you nothing. Cost per unit of business does: it tells you whether each customer, transaction or product costs more or less than before.
ReadBudget and forecast
In the cloud, spend is decided every time somebody deploys. Budgeting means estimating before deploying, forecasting from the real trend, and finding out about the variance before the bill arrives.
ReadOptimising: rate versus usage
There are two levers for bringing cloud cost down, how much you consume and at what price. The order in which you pull them matters, and getting the order wrong locks the organisation into commitments it never needed.
ReadOperation
FinOps without a FinOps team
An SME does not need a FinOps function to practise it. It needs clear owners, a short monthly review and decisions on the record. A minimum operating model that works.
ReadFinOps for AI
Spend on artificial intelligence arrives by different routes from traditional cloud and grows without anyone seeing the whole of it. How to bring it into the same format, allocate it and measure it per feature.
ReadCybersecurity
13 articles
View service line
Security is demonstrated
Compliance verified, from infrastructure to code: knowing what an attacker sees, turning frameworks into your own controls with evidence that collects itself, protecting in layers (privileges, software, data and hybrid access), logging what matters, detecting with few good alerts, responding with a rehearsed playbook and making the secure way the easiest one.
Demonstrate, do not declare
Security is demonstrated
‘We are secure’ is not an answer. The only useful answer to ‘how do you know?’ is evidence: which control exists, who reviews it, when it was last checked and what the result was.
ReadWhat an attacker sees
You cannot protect what you do not know exists. The attack surface is everything somebody outside can reach: addresses, ports, domains, forgotten services. Inventorying it is the first control.
ReadFrom frameworks to controls
One control, several frameworks
ISO 27001, NIST CSF, CIS, customer and regulatory requirements: each framework asks for its own thing, and almost all of them ask for the same thing in different words. Your own catalogue of controls, each mapped to every framework, saves doing the same work five times.
ReadControls with evidence
A control with no evidence is an intention. Each control needs an owner, a way of checking it, a frequency and a record of the result. With that, an audit stops being a desperate hunt for proof.
ReadEvidence that collects itself
Annual compliance portrays one day; continuous compliance portrays them all. Once most controls check themselves and store their result, the state of security stops being a surprise at every audit.
ReadProtect in layers
Least privilege, for real
Everybody says they apply least privilege. Almost nobody measures the distance between the permissions each identity holds and the ones it actually uses. That distance is, in practice, the internal attack surface.
ReadCode is surface too
Most of the code you deploy was not written by your organisation: it is dependencies, base images and third-party tooling. Knowing what each artefact contains, checking it on every build and signing what you publish closes a door almost nobody watches.
ReadEncryption is not enough
Almost everything is encrypted by default today, and data still leaks. Real protection depends on who controls the keys, on knowing which data is sensitive and where it is, and on decrypted access being watched as closely as the encrypted kind.
ReadHybrid access without an open network
Between your own infrastructure and several clouds, traditional access opens an entire network to give access to a single system. Per-application access, verifying identity and device on every connection, gives each person only what they need.
ReadDetect and respond
Logging what matters
Logging everything is expensive and guarantees nothing; not logging what matters is blindness. Which events to keep, where, for how long and protected from whom is a design decision, not a default setting.
ReadFew alerts, good ones
A thousand alerts a day protect nobody: they get ignored. Useful detection means few rules, each tied to a specific risk, with an owner and a planned action, tuned until almost every alert means something.
ReadResponding with a playbook
A security incident is not the moment to decide who does what. Response works when there is a written playbook, with roles, steps and pre-agreed decisions, and when it has been rehearsed before it was needed.
ReadSecurity that does not slow you down
When security feels like an obstacle, teams go around it. When the secure way is also the easiest, because it comes included in the template, the platform and the rules, it gets followed without having to be asked for.
ReadMulticloud Governance
11 articles
View service line
Organisation first, automation second
How several clouds are governed without slowing teams down: named owners and decisions at the level where they belong, a standard you can comply with that evolves, exceptions with an expiry date, an account structure, a single identity, policies that are inherited and governance that is measured and versioned.
Organisation first
Organisation first, automation second
Automating a disorganised organisation does not organise it: it multiplies its disorder at machine speed. Before governance tools you need three much simpler things.
ReadDomains, roles and owners
An IT function is not organised by people or by tools, but by domains of responsibility. Each domain has roles, and each role has deliverables with an owner. Written down and versioned, that map puts an end to duplicated work and to what nobody does.
ReadWhat gets decided at each level
If everything is decided at the top, nothing moves. If everything is decided at the bottom, every team does its own thing. Separating the strategic, the tactical and the operational, each with its rhythm and its way of escalating, is what lets you decide quickly without losing direction.
ReadThe standard
A standard you can actually comply with
IT standards tend to fail through excess: too long, too vague, impossible to verify. A useful standard is short, neutral, says what is mandatory and what is not, and every rule can be checked.
ReadThe life of a standard
A standard that never changes ends up ignored; one that changes with no warning ends up broken. Treating it as a product with versions, proposals, review, a transition period and retirement is what keeps it alive and respected.
ReadExceptions with an expiry date
Every standard has legitimate exceptions. The problem is not that they exist, but that they get forgotten. A healthy exception has an owner, a reason, an accepted risk and an expiry date, and lives in a register somebody reviews.
ReadSeveral clouds, one governance
The account structure is the first policy
Before any automatic rule, the way accounts, subscriptions and projects are organised already decides who can do what, what is isolated from what and how cost is divided. It is the governance decision that is hardest to change later.
ReadOne identity for every cloud
With three clouds and dozens of accounts, managing users in each one is unworkable and dangerous. A single identity source, roles defined once and temporary access for anything sensitive solve most of the problem.
ReadPolicies that are inherited
A rule applied at the top of the account hierarchy reaches every account below on its own, including the ones created tomorrow. Combining rules that prevent with rules that detect lets you govern dozens of accounts without reviewing them one by one.
ReadMeasure and evolve
Measuring governance
Governance that is not measured gets judged on anecdotes: last week's blockage, last month's incident. Four simple indicators tell you whether the standard is met, whether exceptions are under control and whether governance helps or hinders.
ReadGovernance is versioned too
Governance is not a project you finish, but a system that evolves with the organisation. Versioning it, announcing its changes and measuring how they are adopted is what avoids both stagnation and chaos.
ReadAutomation and IaC
14 articles
View service line
Infrastructure you can rebuild
From the manual click in a console to an infrastructure you can rebuild from its code: declaring instead of ordering, looking after the state, reusing with modules, reading the plan and its cost before applying, keeping every server as it should be, changing without fear and automating operations with judgement, including knowing what not to automate.
From click to code
Infrastructure you can rebuild
If the whole environment disappeared tomorrow, how long would it take to have it exactly as it is today? That answer measures the maturity of an infrastructure better than any other.
ReadThe problem with clicks
Cloud providers' web consoles are convenient and dangerous at the same time. Every click changes the infrastructure without leaving a useful trace, and over time each environment becomes a unique artefact nobody knows how to reproduce.
ReadDeclare, do not order
A script says which steps to take; a declaration says how it should end up. The difference looks small and changes everything: what happens if it runs twice, if something already existed or if it fails halfway through.
ReadThe infrastructure's code
State: the infrastructure's memory
Between the code and the real infrastructure there is a third piece almost nobody sees until it fails: the state. Where it is kept, who can write to it and how it is protected decides whether infrastructure as code is safe or a risk.
ReadModules: pieces you reuse without copying
Copying one environment's code to create another works once. By the third copy each one is different and fixing an error means hunting for it in all of them. Modules solve that with a single definition and per-environment parameters.
ReadSee the plan before you apply
Before touching the infrastructure, the tool can say exactly what it is going to create, modify and destroy. Reading that plan, and requiring approval when it includes anything destructive, prevents most disasters.
ReadCost, inside the plan
If a change's plan says which resources get created, it can also say what they will cost per month. Showing that figure in the review changes conversations that used to happen once the bill had already arrived.
ReadEvery server as it should be
Baselines: the server it should be
Creating a server with code is half the job. The other half is that, months later, it is still configured as defined: packages, users, access, patches. That is written as a baseline and checked regularly.
ReadDetecting drift
Drift is the distance between what the code says and what actually exists. It always appears; what distinguishes a healthy infrastructure is that it detects it early and decides what to do with each difference.
ReadChanging without fear
Real rollback
Every change plan says how to move forward; few say how to go back. In infrastructure, rolling back is not always undoing: sometimes it is keeping the old version alive until you are sure of the new one.
ReadRules as code
‘No public storage’, ‘everything encrypted’, ‘nothing without cost tags’. If these rules exist only in a document, they get broken. If they exist in code, they are checked on every change, before it is applied.
ReadWhat you inherited comes in too
Almost nobody starts from scratch. There are years of hand-built infrastructure that also has to come into the code. It is not done in one go and nothing is rebuilt: it is brought in piece by piece, starting with whatever carries the most risk.
ReadAutomating operations
Procedures that run themselves
A procedure written in a document depends on somebody finding it, reading it properly and not skipping a step at three in the morning. The same procedure as code runs the same way every time, and calls a person only when judgement is needed.
ReadWhat is best not automated
Automating does not always pay off. Some tasks are so rare, so variable or so risky that the script costs more than it saves, or does more damage than it prevents. Telling them apart is part of the craft.
ReadPlatform Engineering
15 articles
View service line
Software you can audit
The life of an application inside a governed platform: why a platform is a product, how an application is born, where it gets its truth from, how it is built and deployed without surprises, how each failure is learned from and how AI works when the rules are written by people.
Why
Software you can audit six months later
Six months after deploying, somebody asks which version is running, who approved it and why it was built that way. If the answer depends on somebody's memory, the platform is not governed.
ReadA platform is an internal product
An internal platform fails when it is imposed and succeeds when it is chosen. Treating it as a product, with users, a recommended path and something to gain from using it, is what sets it apart from a list of prohibitions.
ReadBefore the code
Phases and approval gates
An application goes through recognisable phases, from idea to production. Between one phase and the next there is an approval gate with a name, a criterion and an owner. That way you always know where each thing stands and who said it could move on.
ReadThe specification rules
Writing down what is going to be built before building it looks slow. It is the fastest thing there is, because every ambiguity resolved in a paragraph is a week of rewritten code you do not lose.
ReadAlways start the same way
When every application is born with the same structure, anybody on the team knows where everything is in any repository. The application template is the most modest piece of a platform and one of the biggest time-savers.
ReadA single truth
A single registry for everything
Which applications exist, which port they listen on, what address they are published at and who owns them. If that information lives in five places, sooner or later two of them will say different things.
ReadSecrets by name, never by value
A password in a repository is a published password, even if the repository is private. The repository should know what secrets each application needs; only a secret manager should know their value.
ReadStatus and logbook: the project's memory
Two simple documents hold a project's continuity together. The status says where it is today; the logbook tells how it got there. One is overwritten, the other is never edited.
ReadBuild and deploy
Build once, deploy by digest
If what gets deployed to production is different from what was tested in acceptance, then acceptance was worth nothing. Building once and always moving the same artefact, identified by its digest, closes that door.
ReadEnvironments that genuinely resemble each other
Acceptance is only worth something if it resembles production. What can change between environments, what must never change and how to keep that difference written down and small.
ReadLet the build fail, not production
Everything that can be checked without human judgement should be checked before publishing, and if it fails, it should stop everything. Better a broken deployment with a clear message than an error in a user's hands.
ReadOperate and learn
What is running, where and why
From any service in production you should be able to walk the path backwards to the requirement that justifies it. That traceability chain is what turns an audit of weeks into a query of minutes.
ReadEvery failure leaves a rule
An incident resolved that changes nothing will happen again. The way to learn from failures is to turn each one into something permanent: a test, a validation, a rule or a written decision.
ReadAI in the platform
Agents that execute, people that decide
AI assistants already write code, deploy and document. Inside a governed platform they can do a great deal of work autonomously, as long as the gates that require judgement stay with people.
ReadPeople write the rules
AI should not decide how an organisation works. It should apply and check the rules the organisation writes. When the two interpretations do not match, that difference is exactly what you need to look at.
Read