Cloud Native Architecture
Cloud native architecture designs systems around containers, microservices, service meshes, declarative APIs, and immutable infrastructure. It optimizes for automation, resilience, and rapid change by treating the platform's orchestration and observability capabilities as first-class design inputs.
itCloud native tools and technologies | OpenSkills.info
Intro
Cloud Native Architecture
Cloud native architecture helps you build systems that can change often without turning every change into an outage. It is an approach to design and operations, not a product checklist.
The Cloud Native Computing Foundation defines the approach through outcomes. Cloud native systems are loosely coupled, secure, resilient, manageable, sustainable, and observable. Teams use repeatable automation to build and deploy them across public, private, and hybrid environments.
Containers, microservices, serverless platforms, service meshes, immutable infrastructure, and declarative APIs can support those outcomes. None is mandatory by itself. A containerized monolith can be cloud native. A collection of fragile microservices can fail to be cloud native.
Start with the change you need
Architecture sets boundaries. A useful boundary contains change and gives one team a clear responsibility. A poor boundary adds a network call, a deployment, and another failure mode without creating useful independence.
Ask four questions before splitting a system:
- What must change independently?
- What must scale independently?
- What must fail independently?
- Who owns the behavior and its data?
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
- Cloud native practices apply to public, private, and hybrid computing environments
- Target qualities include loose coupling, security, resilience, manageability, sustainability, and observability
- Containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs are examples rather than mandatory ingredients
- Repeatable automation supports frequent and predictable change with separation of concerns
- https://12factor.net/
Supports
- One codebase can have many deploys
- Dependencies should be declared and isolated
- Configuration is separate from code
- Build, release, and run are distinct stages
- Application processes should be stateless and disposable
- Logs are treated as event streams
- https://kubernetes.io/docs/concepts/architecture/
Supports
- Kubernetes separates control-plane components from worker-node components
- Controllers implement control loops over declared and observed state
- https://kubernetes.io/docs/concepts/architecture/controller/
Supports
- A controller tracks Kubernetes resources and works to move current state toward desired state
- Reconciliation is a continuing loop rather than a one-time script
- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
Supports
- A Deployment provides declarative updates for Pods and ReplicaSets
- The Deployment controller changes actual state toward desired state at a controlled rate
- https://kubernetes.io/docs/concepts/architecture/self-healing/
Supports
- Kubernetes can restart containers and replace workload replicas
- Services stop routing to failed Pods
- Application errors and some storage failures can require action outside platform self-healing
- https://opengitops.dev/
Supports
- GitOps desired state is declarative
- Desired state is versioned and immutable with retained history
- Software agents pull desired state automatically
- Agents continuously reconcile actual state toward desired state
- https://opentelemetry.io/docs/concepts/signals/
Supports
- OpenTelemetry signals include traces, metrics, logs, and baggage
- Signals provide complementary views of system behavior
- https://opentelemetry.io/docs/concepts/signals/traces/
Supports
- A distributed trace records the path of a request through an application
- Spans represent units of work and form the trace
- https://csrc.nist.gov/pubs/sp/800/204/final
Supports
- Microservices can support independent development, deployment, platform optimization, and component scaling
- Microservices communicate through APIs and require supporting security and communication capabilities
- Supporting concerns include authentication, access management, discovery, secure communication, monitoring, resilience, load balancing, throttling, and session handling
- API gateways and service meshes can package some supporting capabilities