Topic

Cloud

Cloud platforms, container orchestration, and the cost and capacity questions that decide whether a migration paid for itself.

How we approach Cloud

Migration savings are usually a modelling artefact

Business cases compare a depreciated on-premise estate against list-price cloud, or forecast a utilisation nobody ever achieves. The saving arrives on the slide and not on the invoice. The number worth having compares steady-state run cost after twelve months, including the engineering time the migration consumed, against the cost of doing nothing. It is a less exciting figure and it is the one that survives.

The bill is an architecture diagram

Cloud spend is not a procurement problem with a technical footnote. Egress charges, cross-zone traffic, idle provisioned capacity and storage tiering are all consequences of design decisions taken months earlier, usually by people who never saw the invoice. Cost work that stops at rightsizing and reserved instances collects the easy third and leaves the structural two thirds untouched.

Portability is a running cost paid for an option you may never use

Avoiding managed services to stay portable means rebuilding what the platform gives you and maintaining it forever. Sometimes that is correct, when regulation, exit risk or a real second region demands it. Often it is a hedge nobody has priced. Decide deliberately, write down what the option is worth, and revisit it, rather than treating portability as a default virtue.

Every page above is written to be used rather than skimmed, and each links back here and across to the others. Nothing on this page exists only to hold a keyword.

Other topics: Artificial Intelligence, Cybersecurity, Enterprise Infrastructure, Oracle, Data and Analytics.