Define cloud-native development through service boundaries and named operational responsibilities before choosing infrastructure. Each service needs an owner, a data boundary, a release path and a way to detect failure. Use a representative business transaction to test that design; moving an application into containers does not answer those operational questions.
For a new system, start with the work the business needs completed. Trace one request from entry to its durable result and any follow-up action. Mark where different teams, data or failure conditions meet. This gives architecture discussions a concrete reference and helps the team decide whether a proposed service separation earns its additional operating work.
Where should a service boundary be drawn?
Use a boundary when it gives a clear responsibility that the team can explain and support. For an order workflow, receiving an order, maintaining its status and sending a notification are useful responsibilities to discuss. They need not automatically become separate deployments. Ask what changes independently and which outcome must remain consistent when one part is unavailable.
Propose a service card with purpose, owner, incoming request, outgoing result, stored data and dependent systems. Record the meaning of success and the result of a repeated request. Treat these as design questions, not features that a platform will infer. A short card that exposes an unanswered decision is more useful than an elaborate diagram that hides it.
Kubernetes can expose a container through a DNS name or IP address. The Kubernetes overview describes a platform mechanism for exposing workloads. The application team still needs to decide who may call the service and what a valid request means. A reachable endpoint and a valid business operation are separate acceptance checks.
Which responsibilities belong to the application and platform teams?
A Kubernetes cluster contains a control plane and at least one worker node. The Kubernetes API server exposes the Kubernetes HTTP API. The component overview helps distinguish cluster management from business behaviour. Assign a named owner for cluster configuration and a named owner for each application service. Where one team holds both responsibilities, retain the distinction in the runbook so the right evidence is collected during a failure.
The Kubernetes scheduler assigns unbound Pods to suitable nodes. The kubelet helps ensure that Pods and their containers are running. A container runtime is responsible for running containers. These mechanisms concern placing and running workloads. Ask the application owner what the business sees while a workload starts, restarts or cannot reach a dependency. Do not translate a running container into a claim that the complete transaction has succeeded.
| Responsibility | Decision to record | Demonstration evidence |
|---|---|---|
| Business operation | What counts as accepted and completed | Request and resulting business record |
| Service interface | Inputs, outputs and repeated-request behaviour | Controlled request examples |
| Application release | Which tested version may run | Build reference and release approval |
| Platform operation | Who maintains cluster configuration | Named owner and relevant configuration |
| Data recovery | What must survive and how recovery is checked | Rehearsed restore result |
| Monitoring | Who receives a meaningful failure signal | Alert, owner and response record |
A managed platform can change who performs a particular task, but the project still needs an explicit responsibility assignment. Request the actual division in the proposed service arrangement. An empty ownership row is an unresolved requirement even when the underlying product has a strong feature list.
What does Kubernetes leave for the delivery design?
Kubernetes can change deployed containers towards a declared desired state. That documented capability makes desired configuration part of the operational record. Ask who can change it, how a reviewed application version is selected and which prior configuration will be retained. A rollout procedure should identify application and configuration changes together.
Kubernetes does not build an application or deploy its source code. The platform overview leaves the build and delivery workflow to the organisation. Record how source becomes a tested artefact, where its identity is retained and who permits promotion. Use local scripts or your chosen controlled infrastructure where appropriate; the architecture does not require a particular hosted automation service.
Kubernetes does not dictate the logging, monitoring or alerting solution. Select the signals that answer operational questions: can a request be accepted, can its durable result be found and can the next owner investigate a failure? Assign someone to maintain those signals. Collecting logs without a clear enquiry path can leave a team with data and no usable explanation.
Kubernetes does not supply databases as built-in application services. Distinguish running a database workload from operating its data lifecycle. Ask who owns backup, recovery testing, schema changes and access. A platform restart is not a database recovery plan. Preserve this distinction when comparing a managed data service with a database hosted alongside the application.
Original transaction map: acceptance, persistence and notification
This hypothetical design exercise uses an online order enquiry with three proposed responsibilities: intake, order records and notifications. It deliberately leaves the number of deployments undecided. The purpose is to expose ownership and failure behaviour before committing to a distributed arrangement.
Transaction card. Write one successful example: an enquiry is received, an order reference is stored and a notification is requested. Define what the customer sees after each stage. Keep “received” distinct from “fully processed” if the proposed workflow makes that distinction. Have the business owner approve the wording used for the visible states.
Data card. Name the record that proves acceptance and the owner allowed to update its status. Identify whether notification status belongs on that record or in a linked record. Ask how an investigator would connect the request, stored result and notification attempt. Use fictional identifiers and retain only the data necessary for the exercise.
Failure card. In an isolated test environment, simulate an unavailable notification component. Record the intended order result and the evidence that follow-up remains necessary. Ask who receives the exception and how they distinguish an unsent message from a missing order. The desired behaviour must come from the design, then be checked against the observed result.
Repetition card. Submit the same fictional business request again according to the agreed test procedure. Inspect the resulting records and ask whether they match the intended repeated-request behaviour. Do not assume a platform restart or a retry mechanism understands business duplication. Record the application’s rule and the demonstrated outcome side by side.
Release card. Select a small application change and identify the artefact, configuration and responsible approver. Rehearse its deployment and recovery route without production data. Ask whether the application and stored records remain compatible with the proposed recovery step. Returning to an earlier image does not automatically reverse a data change.
Handover card. Give the resulting evidence to someone who did not configure the demonstration. Ask them to locate the transaction, recognise its current state and name the next responsible person. Difficulty reconstructing the result is an operational design finding, even if every container appears healthy.
How should the architecture decision be recorded?
Compare the proposed boundaries against the worksheet. Keep a service separate when the team can explain its responsibility and support the resulting interface. Combine responsibilities when separation adds unexplained coordination and no clear value. Record the trade-off in business and operational terms, with an owner for any unresolved concern.
Take the transaction map into your software development brief and connect it to the wider business systems requirements. To discuss the design, get started with the service cards, ownership table and failure example. Those artefacts give the architecture conversation a testable foundation.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.