Cloud & Infrastructure
AI deployed across Microsoft Azure, AWS, Google Cloud or your own private cloud, with the estate written as code - so everything running is something someone decided, and everything it costs is something you can see.
Where the money goes
An instance sized for a launch that never got the traffic. A test environment nobody switched off. Logs kept forever because nobody said otherwise, and GPUs billed by the hour for a model that runs once a day. None of it was a decision - each was a default that nobody went back to. The estate that costs too much is usually the one nobody can fully describe, which is also what makes it hard to secure.
Every account, network, cluster and permission defined as code and changed through review. If it exists, somebody decided it, and the decision is in the history.
Resources created in a console on a busy afternoon, known to one person and to the invoice. It works until that person leaves, or until the bill arrives.
Capability
Five areas. Most engagements start with whichever one is costing you the most right now, in money or in sleep.
AI workloads on Microsoft Azure, AWS or Google Cloud - or across more than one when there is a reason, such as where your data is allowed to live or which models a provider offers. Multi-cloud as a decision, not as the accident most estates arrive at.
Terraform for the estate and Helm for what runs on it, kept in your repository and applied through the same review as your application code. An environment that can be rebuilt from the repository is the only real proof that it is understood.
Docker and Kubernetes when the number of services and the pace of change justify them, and something plainer when they do not. Kubernetes solves real problems and brings some of its own; it should be chosen for the first reason.
For data that is not allowed to leave your walls, or models you would rather run on hardware you own. The same practices apply - code, review, monitoring - on infrastructure that happens to be yours.
Every resource tagged to an owner and a workload, budgets and alerts set before the spend rather than after it, and a regular look at what is running and why. The aim is not the lowest bill; it is a bill in which every line has a reason.
How we work
Every account, resource and line on the bill, and who owns each. It is often the first time the estate and the invoice have been read side by side, and the gaps between them are where the work starts.
Where each workload runs and why, what it has to survive, and what that costs. Availability is chosen workload by workload, against what an hour of downtime actually costs you.
The estate expressed in Terraform and Helm and reviewed like application code, so the next change is a pull request rather than an afternoon in a console.
Three stages in, the estate is described and every change is reviewed. The last two keep it that way - and keep the bill honest.
Alerts on what your users would notice, and cost reports that say which workload and which team each line belongs to. A surprise should be found by a dashboard, not by the finance team.
The code, the runbooks and the access in your hands, and a team that can make the next change without us. An estate only one outside firm can operate is a more expensive version of the one you started with.
Straight answer
Each extra nine of availability is paid for in redundancy, in more regions and in someone awake to answer the alert - and each one costs more than the last. So the honest target depends on what an hour of downtime costs you, workload by workload. We would rather work that out with you than print a figure on this page that neither of us has priced.
Before you ask
Microsoft Azure, AWS and Google Cloud, and private cloud or on-premise environments, with Terraform, Docker, Kubernetes and Helm to build and run on them. Usually the right platform is the one your data and your team are already on; moving clouds to save money rarely survives the cost of the move. The labels in the illustration at the top of the page describe kinds of work - the compliance standards drawn there are not certifications we hold, and the monitoring is not a service we staff around the clock.
Probably not. Most estates that span several clouds got there by acquisition or by accident, and pay for it in duplicated skills and tooling. It is worth doing on purpose when a regulation, a customer or a model you need requires it - and then the work is making the second cloud as boringly well run as the first.
Where the data or the economics call for it. A model that runs constantly on data that must stay inside your walls can be cheaper and simpler on hardware you own; one that runs occasionally usually is not. We will do that arithmetic with you before anyone orders a server.
By finding out what each line is for before touching it. Most savings come from the unglamorous end - resources nobody uses, sizes chosen for a launch, retention nobody set - and they are removed through the same reviewed code as everything else, so every change can be undone.
Enterprise AI Solutions is the programme: which use cases, which models, governance and MLOps. This is the ground it runs on - the accounts, networks, clusters and the bill. Most AI programmes need both, and they are separate pages because a team may only need one. Enterprise AI Solutions.
Next
Send us the invoice and whatever description of the estate exists. We will come back with what is running, what it is for, what could be switched off - and what it would take for every line on the next bill to have an owner.
Related white papers and articles for Cloud & Infrastructure will appear here as they're published.
View MoreGet in touch and we'll help you find the right approach.
Talk to Us