# 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

```yaml
# 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](https://12factor.net/config) 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

```yaml
# 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](https://12factor.net/config)
* [Kubernetes Namespaces Documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
* [External Secrets Operator](https://external-secrets.io/)
* [Crossplane Documentation](https://docs.crossplane.io/)
* → Next: [Declarative Resource Management](https://blog.htunnthuthu.com/getting-started/fundamentals/platform-engineering-101/platform-engineering-101-declarative-resource-management)