Cloud Native Application Design
Cloud native application design structures software to exploit cloud platform capabilities: containers for packaging, orchestration for scheduling, microservices for independent deployment, and managed services for infrastructure concerns, producing systems that scale, heal, and deploy continuously.
itCloud native tools and technologies | OpenSkills.info
Intro
Cloud Native Application Design
Cloud native application design is a way to build software for change. You assume that traffic varies, components fail, and releases continue after launch. You shape the application so a platform can automate deployment, recovery, scaling, and observation.
The Cloud Native Computing Foundation describes cloud native systems as loosely coupled, secure, resilient, manageable, sustainable, and observable. Containers and microservices can support those qualities. They do not create them by themselves.
Start with outcomes
Begin with the user flow and its required outcome. Define acceptable latency, failure behavior, recovery time, security constraints, and cost. These requirements determine where you need redundancy or isolation. They also stop you from adding distributed-system complexity without a reason.
A cloud native design usually aims for four outcomes:
- Changeability: You can release one component without rebuilding the whole system.
- Resilience: A component failure has a limited effect, and recovery is planned.
- Elasticity: Capacity can follow demand by adding or removing instances.
- Operability: You can understand and control the running system through telemetry and automation.
These outcomes involve tradeoffs. More components create more network calls, deployment units, and failure modes. A modular monolith can be the right starting point when one team owns a young product. Split a service only when an independent business boundary, scaling need, reliability requirement, or ownership boundary justifies the operational cost.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://github.com/cncf/toc/blob/main/DEFINITION.md
Supports
- Canonical cloud native definition and target system qualities
- Typical technologies and the role of automation
- Cloud native practice across public, private, and hybrid environments
- https://12factor.net/
Supports
- Configuration outside application code
- Backing services as attached resources
- Separation of build, release, and run
- Stateless processes, horizontal process concurrency, disposability, and event-stream logs
- https://12factor.net/processes
Supports
- Stateless and share-nothing application processes
- Durable state stored in a backing service
- https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/
Supports
- Self-healing, redundancy, minimal coordination, scale-out, and partitioning
- Operational telemetry, automation, design evolution, and business requirements
- Failure-mode analysis and explicit architecture tradeoffs
- https://learn.microsoft.com/en-us/azure/well-architected/reliability/principles
Supports
- Reliability outcomes for critical user flows
- Resilience, recovery, graceful degradation, fault isolation, and blast radius
- Cost, complexity, security, and operational constraints
- https://learn.microsoft.com/en-us/azure/architecture/patterns/retry
Supports
- Bounded retry handling for transient faults
- Idempotency concerns when operations can be repeated
- Delay and randomized backoff between attempts
- https://kubernetes.io/docs/concepts/workloads/pods/probes/
Supports
- Different meanings and effects of startup, liveness, and readiness probes
- Traffic removal for failed readiness and restart for failed liveness
- Cascading-failure risk from incorrect liveness checks
- https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
Supports
- CPU and memory resource requests used in scheduling
- CPU and memory resource limit enforcement
- https://kubernetes.io/docs/concepts/workloads/autoscaling/
Supports
- Horizontal scaling by replica count and vertical scaling by assigned resources
- Automatic scaling from observed demand
- https://kubernetes.io/docs/concepts/configuration/secret/
Supports
- Separating confidential values from application code
- Need for encryption at rest and least-privilege access
- https://kubernetes.io/docs/concepts/security/
Supports
- Workload identity and access controls
- Encryption in transit and at rest
- Workload isolation, network policy, and admission policy
- https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/storage-data
Supports
- Backward compatibility with a previous database schema version
- Sequencing destructive schema changes across multiple versions
- Automated pipelines for database schema changes
- https://sre.google/workbook/canarying-releases/
Supports
- Repeatable artifacts, automated builds, tests, and deployments
- Small releases and progressive exposure through a canary
- Evaluation and rollback during release automation
- https://opentelemetry.io/docs/concepts/observability-primer/
Supports
- Observability through emitted telemetry
- Roles of metrics, logs, traces, and context across distributed requests
- User-centered service level indicators and reliability