Why this matters: Cloud-native is now the default architecture for most software products. Being precise about Kubernetes resource types, GitOps reconciliation concepts, serverless invocation patterns, and cloud cost optimization gives you fluency in architecture discussions, job interviews, and cross-team system design conversations.

Frequently Asked Questions

What does "cloud-native" mean in job descriptions and architecture documents?

Cloud-native refers to an approach to building and running applications that fully exploits the advantages of cloud computing — elasticity, on-demand provisioning, managed services, and automation. In job descriptions, "cloud-native experience" typically means familiarity with containers, Kubernetes, microservices, CI/CD pipelines, and infrastructure-as-code. In architecture documents, it signals that the system is designed for resilience, horizontal scalability, and automated deployment rather than manual operations.

How do microservices differ from a monolithic architecture in professional English?

A monolithic architecture packages all application functionality into a single deployable unit — a change to any component requires rebuilding and redeploying the entire application. Microservices decompose the application into independent services, each responsible for a bounded business capability, communicating over APIs or message queues. The vocabulary distinction matters in technical discussions: "we are decomposing the monolith" means migrating toward independent services, while "we are running a microservices architecture" implies that decomposition is already complete.

What are the 12 factors of the 12-Factor App methodology?

The 12-Factor App is a methodology for building software-as-a-service applications that are portable, scalable, and maintainable. The twelve factors address: codebase (one repo per app), dependencies (explicitly declared), config (stored in the environment), backing services (treated as attached resources), build/release/run (strictly separated), processes (stateless), port binding (self-contained), concurrency (horizontal scaling), disposability (fast startup/graceful shutdown), dev/prod parity (minimised gap), logs (treated as event streams), and admin processes (run as one-off tasks). These terms appear frequently in cloud-native architecture reviews and 12-factor compliance discussions.

What is GitOps and how is it different from traditional CI/CD?

GitOps is a practice where the desired state of infrastructure and application deployments is defined declaratively in Git, and an automated reconciliation loop continuously ensures the actual cluster state matches that declared state. Traditional CI/CD pipelines push changes imperatively; GitOps uses pull-based reconciliation through tools like Argo CD or Flux. Key vocabulary includes "desired state", "observed state", "drift detection", and "reconciliation loop".

What does "immutable infrastructure" mean in cloud-native contexts?

Immutable infrastructure is a pattern where servers or container instances are never modified after deployment — instead of updating a running instance, you build a new image with the change and replace the old instance. This eliminates configuration drift, simplifies rollbacks, and makes deployments reproducible. The pattern is closely associated with container-based deployments and infrastructure-as-code tooling such as Terraform and Packer.

What is a service mesh and when do cloud-native teams use it?

A service mesh is an infrastructure layer that handles service-to-service communication — providing traffic management, mutual TLS encryption, observability, and circuit breaking without requiring changes to application code. Istio and Linkerd are the most commonly referenced service mesh tools. Teams adopt a service mesh when they need consistent security policies, detailed inter-service telemetry, or advanced traffic routing (such as canary deployments) across a large microservices landscape.

What does "cold start" mean in a serverless architecture?

A cold start occurs when a serverless function is invoked after being idle and the platform must provision a new execution environment — loading the runtime, initialising dependencies, and executing the function handler. Cold start latency ranges from milliseconds to several seconds depending on the runtime and payload size. It is a critical trade-off discussed when evaluating serverless for latency-sensitive use cases, often mitigated by provisioned concurrency or scheduled warm-up invocations.

How do cloud-native teams discuss Kubernetes resource types in English?

Kubernetes resource vocabulary is precise and hierarchical. A Pod is the smallest deployable unit — one or more containers sharing a network and storage namespace. A Deployment manages a desired number of Pod replicas and handles rolling updates. A Service exposes Pods as a stable network endpoint. An Ingress routes external HTTP traffic to Services. A Namespace provides logical isolation within a cluster. Using these terms correctly in architecture discussions, pull request descriptions, and runbooks is a marker of cloud-native fluency.

What is the circuit breaker pattern in cloud-native architecture?

The circuit breaker pattern prevents cascading failures in a microservices system by monitoring calls to a downstream service and "tripping" — stopping calls — when failure rate exceeds a threshold. In the open state, the circuit returns an error immediately without attempting the call, allowing the downstream service to recover. After a timeout, the circuit enters half-open state and tests with a limited number of requests. This vocabulary appears in architecture decision records, incident post-mortems, and resilience engineering discussions.

What cloud-native English exercises are available on CoderLingo?

CoderLingo's Cloud-Native Language section includes six exercise sets: container orchestration language (Kubernetes vocabulary), cloud-native design patterns (circuit breaker, bulkhead, sidecar), GitOps vocabulary, serverless language, cloud FinOps vocabulary, and 12-Factor App vocabulary. Sets are available at Intermediate and Advanced levels for developers and DevOps engineers preparing for technical interviews or architecture discussions.