What Cloud Computing Services Should Include

We signed our first cloud computing services arrangement on the strength of a price per server. Eighteen months later the bill was three times the forecast and most of the increase came from things the proposal had not mentioned.

The price of compute is the least informative number in this decision. Here is what I look at now.

A provider can supply servers, storage, and networking. So can every other provider, at broadly similar prices.

What differs is everything around that. Who patches the operating systems? Who notices when a backup fails? Who answers at 3am? Who tells you that a third of your spend is on resources nobody is using?

Our first arrangement covered infrastructure and nothing else. We discovered the rest as it went wrong.

Operations: Patching, monitoring, backup verification, and incident response on a defined schedule. The routine work that slips when your own team is busy.

Cost management: Somebody whose job is finding idle resources, right sizing, and managing commitments. Ours paid for itself in the first quarter.

Security baseline: Identity, network segmentation, encryption, and logging configured properly from day one, and kept that way.

Architecture guidance: Somebody who will tell you that the design you are about to build will be expensive to run.

A named contact: One person who knows your estate, rather than a queue.

A provider offering those five is worth considerably more than a lower compute price without them.

Every proposal has a scope that reads well and an exclusions list that determines what you pay.

Ours now checks the same items each time. Out of hours support. Onboarding new workloads. Incidents above a threshold. Anything described as a project. Third party licences.

Our second contract had an attractive headline and excluded new workload onboarding. We onboarded eleven that year, each quoted separately.

Infrastructure only matters because of what runs on it.

Our cloud computing services provider runs the platform. Our software development services partner builds the applications. For the first year, those two never spoke.

The result was predictable. Applications designed without knowing how the platform was configured, and platform decisions made without knowing what the applications needed.

We now bring both into the same quarterly review. Platform and application delivery depend on each other. The gap between them caused most of our cost surprises.

A structural point that changed our results.

If a provider is paid a percentage of your cloud bill, their revenue rises when your spend does. Some optimise anyway, out of professionalism. It is a strange thing to rely on.

Ours is a fixed fee for a defined scope, with a quarterly cost review as a deliverable. Our spend fell by about a third in the first year and nobody's revenue was harmed by it.

Most organisations adopt cloud computing services while moving something, and that period carries the most risk.

Old and new run in parallel. Access is granted temporarily and forgotten. Monitoring covers one environment and not the other.

We classified every application before moving anything, using the 6 Rs of cloud migration. Eleven were retired rather than moved, which was the largest single saving in the programme and removed them from every later phase.

A provider who proposes moving everything without that classification is proposing the most expensive version of the work.

Not because you plan to leave. Because an arrangement you can leave is one you can negotiate.

Infrastructure defined in code, held in your repository. Accounts in your name. Documentation written as the work happens. A defined handover period in the contract.

All four cost nothing to agree at the start and a great deal to arrange later.

A small point with large consequences.

Our first arrangement promised a dedicated account manager. In practice it was a shared inbox and a different person each month.

We now meet the named contact before signing, ask how long they have been with the firm, and write their name into the contract with a notice period.

Two of our three providers since have honoured that. The one that did not was replaced at renewal.

●      What does operations cover, specifically, and at what hours?

●      How is cost management structured, and what incentive does it carry?

●      What is excluded, on the same page as what is included?

●      Who is our named contact, and how long have they been with you?

●      What do we own if we leave?

The second question separates providers faster than any other. The good ones have thought about the incentive problem and designed around it.

Should the application partner and the cloud provider be the same firm?

It can work. What matters is that they share a review. Software development services and cloud computing services planned separately produce two roadmaps that quietly depend on each other.

Should we use one provider or several?

One for most organisations. Multiple clouds double the expertise needed and the saving rarely justifies it below significant scale.

Is a managed arrangement always better than doing it ourselves?

Not at larger scale with a strong internal team. For most mid sized organisations, the operational discipline is what is being bought, and it is hard to build.

How long should a contract run?

Three years with annual reviews that have real consequences. Long enough for the provider to learn your estate, short enough to stay competitive.

What is the clearest warning sign?

A proposal that leads with compute price and says little about operations. Cloud computing services priced that way will surface their real cost later.

Stop comparing the price per server. Every provider is roughly the same there.

Compare what happens after the servers exist. Who runs them, who watches the cost, who secures them, and who will tell you when you are about to make an expensive mistake.

Our third arrangement costs more per month than our first and less per year, because it includes the parts that were previously arriving as surprises.