A platform can have containers, infrastructure code and a green pipeline while still depending on one engineer to recover a failed service. Installing an orchestrator does not decide who may deploy, how a database is restored or what a critical alert means. Platform readiness is the ability to make, observe and recover a change under the organization’s real constraints.
Assess the operating boundary
Begin with one service and follow a change from reviewed source to the running environment. Identify who approves the change, which artifact is deployed, where configuration comes from and how the team knows that the intended behaviour is working. Include dependencies outside the application: identity, network, certificates, secrets, storage, database migrations and the people authorized to act.
| Question | Evidence to request | A misleading substitute |
|---|---|---|
| What is running? | Source revision, artifact identifier and environment record | “Latest” image tag |
| Who may change it? | Scoped deployment access and approval responsibility | A shared administrator password |
| Can we recover? | Timed restore and compatibility verification | A backup job marked successful |
| How will we notice harm? | User journey signal and an actionable response | A dashboard with only host CPU |
| Who operates it? | Named owner, runbook and support expectations | The developer’s phone number alone |
Make releases traceable before making them numerous
A release record should connect source, checks, artifact, configuration and migration decisions. The required verification follows the risk: a permission change needs a forbidden-path test; a database migration needs compatibility checks; a workflow change needs a representative business journey. A failed required check is information to investigate, not an obstacle to hide.
For small teams, a deliberately simple deployment process may be easier to reason about than many automation stages. The minimum is not a particular tool count. It is a repeatable path with identified inputs, meaningful verification and an accountable decision to proceed or stop.
A rollback plan is also a data plan
Restoring yesterday’s application image may fail against today’s schema. Reversing a destructive database migration may be impossible without restoring data, and restoring data can discard legitimate recent work. Classify the change before release: backward-compatible expansion, behaviour switch, destructive cleanup or a change requiring a maintenance window. Decide whether recovery means rollback, forward repair or restoration.
Test restoration in an isolated environment with controlled access. Record the backup used, restoration duration, last recoverable transaction and reconciliation results. Recovery point and recovery time objectives are business commitments to agree and test, not numbers copied from a product brochure. Backups also need protection against accidental deletion and unauthorized access.
Observe the user outcome and the internal cause
An operational signal should connect to a user journey: request acceptance, approval completion or report freshness. Internal signals help explain why that journey fails. Google’s monitoring guidance distinguishes externally observed behaviour from internal instrumentation; the practical task is to choose a small set that supports an action. A queued job count without age or ownership may hide work that is never progressing.
For the fictional approval platform, candidate signals include failed authenticated submissions, oldest unprocessed notification, age of the last complete report and errors during a representative transaction. Thresholds depend on agreed service objectives. Each interrupting alert needs a responsible person, a likely first action and a way to determine whether the incident is resolved.
Introduce orchestration when a specific constraint demands it
Consider more sophisticated orchestration when there is evidence of placement, isolation, scaling or independent delivery needs that the existing process cannot meet economically. Include its operating costs: upgrades, access policy, networking, persistent storage, observability and incident skills. “We plan to grow” is insufficient to choose the entire future infrastructure today.
- Establish one repeatable release and one demonstrated restore.
- Document service ownership, access and response expectations.
- Measure the current constraint and the cost of working around it.
- Compare a simpler improvement with the proposed platform investment.
- Pilot the new approach with explicit acceptance and exit criteria.
The first consulting deliverable can be a readiness assessment and a prioritized operating plan rather than a cluster installation. The result should explain what the team can safely deliver now, where the risk sits and which evidence would justify the next platform capability.