At a glance
What you need to know.
Cloud-native development designs an application's behavior for the environment in which it will run. The useful choices concern state, dependency access, scaling, deployment and recovery. Select the smallest platform that can meet the workload's constraints and that the team can operate reliably.
Choose compute from the workload's constraints
Describe request duration, concurrency, scheduled work, network dependencies and state requirements before selecting functions, managed containers or virtual machines. Check the chosen platform's current limits and deployment model against those requirements. A short stateless API may fit a managed request platform, while a specialized long-running process may need a different operating model. Include startup behavior, connection management and provider identity in the evaluation. Using containers does not itself make an application resilient or portable. The architecture should explain how a real user journey reaches its dependencies, handles interruption and returns a meaningful result within the agreed response budget.
Put authoritative state in a deliberate persistence model
Identify data that must survive a restart, release or host replacement. Keep durable records in the agreed storage service and decide whether local caches can be rebuilt. Model the consistency required for important operations such as reservations or account changes. Shared persistence must have capacity, access controls and a recovery procedure compatible with the application. A stateless request layer still depends on stateful systems; show those dependencies in the operating design. Separate object storage, queues and database responsibilities rather than putting every kind of state into the nearest available service. Verify restoration using the records the application actually needs to serve its primary journey.
Bound calls, retries and background execution
Set timeouts that fit the user journey and retry only failures the destination can safely repeat. Use a stable operation reference or the provider's documented idempotency behavior for writes. Move work to a durable queue when it can finish after the request, and expose the difference between accepted and completed states. Limit worker concurrency according to database and provider capacity rather than scaling every component independently. Test connection exhaustion and a slow dependency so horizontal scaling does not amplify an outage. Decide which optional features can degrade and which operations must stop when their authoritative dependency is unavailable.
Make deployment and configuration reproducible
Describe infrastructure, bindings, environment variables and deployment steps in a form the team can review and reproduce. Keep secret values in the intended runtime mechanism, with ownership for rotation and access review. Separate development and production identities and data. Version configuration changes with application compatibility requirements, especially when a queue, database or API contract changes. Test a fresh environment to reveal undocumented manual setup. Plan releases that can tolerate old and new application versions during overlap. A successful artifact upload is useful evidence of publication, but application readiness requires the deployed identity, dependencies and actual route behavior to work together.
Observe the user journey and rehearse recovery
Instrument request correlation, dependency timing, failed jobs and readiness in a way that helps an operator locate incomplete work. Keep private content and credentials out of routine logs. Define recovery targets with the business owner and rehearse a database restore, queue replay and failed release. A fixed success health endpoint cannot establish that the critical journey is usable; choose checks that reflect the intended operating state without creating excessive load. Monitor queue age and error categories alongside infrastructure usage. Record the action needed when a threshold is crossed so telemetry supports a response rather than merely creating another dashboard.
Validate capacity, cost assumptions and controlled cutover
Run representative workload tests with stated concurrency, data volume and dependency behavior. Confirm that resource limits and connection budgets hold under the intended scaling conditions. Include storage, data transfer, requests and managed dependencies in the operating estimate, then compare that estimate with measured use. Before cutover, verify the deployed version, domain routing, database compatibility and rollback procedure. If a change cannot be reversed, design a forward repair or staged migration explicitly. Acceptance should demonstrate the primary journey, recovery and operational ownership. No particular provider, topology or availability level is implied without requirements and evidence for the scoped environment.
Before you start.
- Match compute to request, background and dependency constraints.
- Name durable state, consistency requirements and restore procedures.
- Bound retries, worker concurrency and dependency connection use.
- Reproduce environments with controlled identity and configuration.
- Observe primary journeys and rehearse failed releases and restores.
- Verify measured capacity, operating assumptions, routes and rollback.
Common questions.
Does cloud-native development require Kubernetes?
No. Managed functions or application platforms may meet the workload with less operating effort. A cluster can be useful when its control and scheduling capabilities are required and the team can support them. Choose from concrete workload constraints instead of a label or reference diagram.
Can a stateless application lose important work?
Yes, if pending work or authoritative data is kept only in memory or ephemeral storage. A stateless request layer should rely on deliberate persistence and durable job handling where needed. Test interruption, duplicate delivery and restoration to establish the actual recovery behavior.