Application Environments and Infrastructure Concepts

CNPA Domain: Platform Engineering Core Fundamentals (36%) Topic: Application Environments and Infrastructure Concepts

Overview

Modern software delivery relies on well-defined application environments — isolated slices of infrastructure that progress code from development to production. Understanding how environments are structured, managed, and isolated is foundational to platform engineering: the platform team's job is to make environment provisioning self-service, consistent, and safe.

---

What Is an Application Environment?

An application environment is a configuration of infrastructure, services, and configuration values where a specific version of an application runs. Environments serve as promotion gates between code change and user impact.

Developer → [dev] → [staging] → [production]
                ↑
          Platform team manages
          environment parity and
          self-service provisioning

Typical Environment Types

Environment	Purpose	Audience	Stability
Local / Dev	Fast iteration, debugging	Individual developer	Low — ephemeral
Shared Dev / Integration	Early integration testing	Dev team	Medium
Staging / Pre-prod	Production-like validation	QA, stakeholders	High
Production	Live user traffic	End users	Critical
Preview / Feature	PR-level isolated testing	Dev, reviewers	Ephemeral

---

Environment Parity

Environment parity means staging behaves as close as possible to production. Differences introduce risk — bugs found only in production after clean staging runs are often caused by configuration drift.

Common Parity Anti-Patterns

• Using SQLite in dev but PostgreSQL in production

• Different OS or container base images between environments

• Hardcoded environment-specific logic in application code

• Secrets managed differently per environment

Platform Engineering Solution

The platform team enforces parity by:

1. Providing environment templates (Helm charts, Terraform modules, Crossplane compositions) that render identically across environments with different input values

2. Using GitOps so all environments are declared in version control

3. Abstracting environment-specific config into external secrets and config maps

---

Kubernetes as the Environment Foundation

Kubernetes provides the primitives platform teams use to model application environments.

Namespaces as Environment Boundaries

# Each environment gets its own namespace
apiVersion: v1
kind: Namespace
metadata:
  name: myapp-staging
  labels:
    environment: staging
    team: payments

Namespaces provide:

• Resource isolation with ResourceQuota and LimitRange

• RBAC scoping (teams only access their namespace)

• Network policy boundaries

• Separate ConfigMap and Secret objects per environment

Cluster vs Namespace Isolation

Approach	Use Case	Pros	Cons
Namespace-per-env	Same cluster, logical separation	Cost-efficient, fast	Blast radius risk
Cluster-per-env	Hard isolation per environment	Strong security boundary	Higher cost, more management
Cluster-per-tenant	Multi-tenant platforms	Full autonomy per team	Operational complexity

Platform teams typically use namespace-per-env for dev/staging and dedicated cluster for production.

---

Infrastructure Concepts for Platform Engineers

Infrastructure as Code (IaC)

Platform engineers treat infrastructure configurations the same way developers treat application code: version-controlled, peer-reviewed, tested, and automatically applied.

Key IaC tools:

Tool	Scope	Approach
Terraform / OpenTofu	Cloud resources (VMs, networks, databases)	Declarative HCL
Pulumi	Cloud resources	Imperative (TypeScript, Python, Go)
Crossplane	Cloud resources via Kubernetes CRDs	Kubernetes-native declarative
Ansible	Configuration management, VM provisioning	Procedural YAML

Immutable Infrastructure

"If it works, don't patch it — replace it."

Immutable infrastructure means infrastructure components are never modified after deployment. Changes are applied by provisioning a new instance and terminating the old one. This:

• Eliminates configuration drift

• Makes rollbacks predictable

• Aligns with container-based workloads

Pets vs Cattle

Concept	Description
Pets	Named servers maintained over time (traditional VM ops)
Cattle	Numbered, interchangeable instances replaced not fixed (cloud-native)

Platform engineering drives organizations from pets toward cattle.

---

Environment Configuration Management

The 12-Factor App Approach

The 12-Factor App mandates that config (anything that varies between deployments) is stored in environment variables, never in code.

Platform teams enforce this by:

• Injecting environment-specific values through Kubernetes ConfigMaps and Secrets

• Using external secrets operators (External Secrets Operator, Vault Agent) to pull from secrets managers

# ConfigMap for environment-specific config
apiVersion: v1
kind: ConfigMap
metadata:
  name: myapp-config
  namespace: myapp-staging
data:
  DATABASE_HOST: "db.staging.internal"
  LOG_LEVEL: "debug"
  FEATURE_FLAGS: "new-checkout=true"

Secrets Management

Secrets must never be committed to Git. Platform teams integrate a secrets manager:

[Vault / AWS Secrets Manager / Azure Key Vault]
          ↓  (External Secrets Operator)
    Kubernetes Secret (in namespace)
          ↓
    Application Pod

---

Preview Environments

Preview environments are ephemeral environments created automatically per pull request, giving reviewers and QA an isolated instance of the change.

PR #42 opened
    → Platform creates namespace: preview-pr-42
    → Deploys application with PR's image tag
    → Posts URL to PR comment
PR #42 merged/closed
    → Platform deletes namespace: preview-pr-42

This is a key capability of mature Internal Developer Platforms and dramatically shortens review feedback cycles.

---

Infrastructure Concepts Summary

┌──────────────────────────────────────────────────────────┐
│              Infrastructure Abstraction Layers           │
├──────────────────────────────────────────────────────────┤
│  Developer Experience (Backstage, CLI, self-service)     │
├──────────────────────────────────────────────────────────┤
│  Platform APIs (CRDs, Crossplane Compositions)           │
├──────────────────────────────────────────────────────────┤
│  Orchestration (Kubernetes, Namespaces, GitOps)          │
├──────────────────────────────────────────────────────────┤
│  Infrastructure (VMs, Networks, Storage, Cloud Services) │
└──────────────────────────────────────────────────────────┘

---

Key Takeaways

• Application environments provide isolated promotion stages from development to production

• Environment parity reduces production surprises; platform teams enforce it through templating and GitOps

• Kubernetes namespaces are the foundational primitive for environment isolation

• Immutable infrastructure and IaC eliminate drift and enable reliable rollbacks

• Preview environments enable rapid, isolated PR testing and are a hallmark of mature IDPs

• Secrets must always be externalized from code and injected at runtime

---

Further Reading

• 12-Factor App — Config

• Kubernetes Namespaces Documentation

• External Secrets Operator

• Crossplane Documentation

• → Next: Declarative Resource Management