The four decisions that set everything else
Everything else in the cloud part of a digital transformation follows from these four. Together they are your cloud strategy, and everything after them is implementation. Each needs an owner and a date, not a working group.
Public, private, hybrid or multi-cloud
Public cloud is the default for most workloads and the cheapest to operate.
Private cloud earns its place where data residency, latency or a regulator requires it, and it costs more per unit of capacity.
Hybrid cloud is what most enterprises actually run: some workloads in a provider, some on their own hardware, connected. Hybrid cloud also shapes your network and identity design, so plan it rather than arriving at it by accident.
Multi-cloud means running on two or more providers deliberately.
What multi-cloud costs you in skills
Multi-cloud is usually sold as insurance against lock-in. The bill arrives in people.
Every provider has its own identity model, its own networking, its own managed services and its own failure modes. Running two well takes close to two sets of expertise, and running two badly is worse than running one well.
A more honest version for most enterprises: pick one primary provider, keep your architecture portable where it is cheap to do so, and use a second provider where there is a specific reason. Our comparison of public, private or hybrid works through the first choice, and our guide to choosing a provider covers the second.
This choice is the backbone of the cloud strategy. Owner: the architecture lead, signed off by the CIO. Test: can somebody name, in one sentence, why each provider is in the estate?
What moves first
In a cloud migration the instinct is to start with the biggest system, because that is where the cost is. The better first move is a workload that matters enough to be real and not enough to end a career.
Three good candidates: a system with a clear boundary and few integrations, a workload with spiky demand where elasticity shows up immediately, and a non-production environment that teaches the team the platform.
The data is usually the hard part rather than the application. Our guide to what moves first covers sequencing the data itself.
Owner: the programme lead. Test: if this migration fails on a Tuesday, who is affected and for how long?
What cloud-native means for your team
Cloud-native gets used as a slogan. Cloud-native means three specific things, and each changes how your team works.
Containers and Kubernetes
A container packages an application with everything it needs to run, so it behaves the same on a laptop and in production. Kubernetes runs a lot of containers across a lot of machines, restarting what fails and scaling what is busy.
Containers are the entry point to cloud-native. What it changes: deployment becomes repeatable. What it costs: Kubernetes is a platform your team now operates, and it needs people who understand it.
Microservices
One large application is split into smaller services that are deployed separately. Teams can then release their own part without a coordinated release.
What it changes: teams stop queueing behind each other. What it costs: you now have a distributed system, with network calls where function calls used to be, and debugging is harder. Our microservices on AWS walkthrough shows what one looks like in practice.
Serverless
You deploy a function and the provider runs it when something calls it. There is no server to size, and you pay per execution.
What it changes: it suits event-driven and spiky work, and it removes a whole class of operations. What it costs: it ties you closely to one provider's platform, which is the cloud-native trade-off nobody mentions, and it is a poor fit for long-running or steady workloads.
Owner: the engineering lead. Test: for each of the three, can the team say what it would run in production next quarter?
Who owns the bill
Name a person, not a function. That person sees the spend weekly, understands what drives it, and has the authority to switch things off.
Four habits cover most of the waste: tag everything so cost maps to a team, review the top ten line items every week, rightsize before you commit to anything, and set a rule for non-production environments outside working hours.
This is the FinOps role, and a cost engineer usually pays for themselves in the first quarter. If you do not have one, the engineers who do this work can be brought in for the phase that needs them.
Owner: named individual, finance and engineering jointly. Test: can they tell you what changed on the bill last month, and why?
